We automated our own enquiry handling. Payback in six weeks
Before we offered this service to anyone, we built it for ourselves. Five hours of work, two days of testing, twelve enquiries in the first fortnight. Below: what exactly we built, how long it took, what went wrong and an honest payback calculation.
The short answer
We automated our own enquiry handling process before offering that service to anyone. Five hours of work plus two days of testing. Handling one enquiry by hand took 6–10 minutes.
In the first fortnight twelve enquiries went through the system. At that rate the effort pays back in about six weeks, and in the first two weeks we had already recovered roughly a third of the time invested.
Over a year, at the same volume, that is more than forty hours — a full working week, recovered from work that develops nobody.
How it worked before
The website form sent a message to an inbox. Everything after that was done by a person:
- Sifting out spam. Bots find a form faster than clients do. A significant share of the messages were not enquiries.
- Retyping the contact into a spreadsheet. Name, email, company, message — by hand, from the inbox to the sheet.
- Replying to the client. Written from scratch every time.
- Adding a task. A reminder to follow up, so the enquiry would not get stuck.
Six to ten minutes per enquiry, not counting the time spent deleting spam.
None of these steps is difficult. The problem is not difficulty — it is that every one of them depends on somebody happening to look at the inbox. This is exactly the kind of process we describe to clients: repetitive, with clear rules, on digital data, where a mistake can be undone.
What we built
The whole process connects tools we were already using. Nothing was bought.
The form sends the enquiry to a webhook. Not to an inbox — to a scenario that decides what happens next.
A spam filter rejects bots. Three conditions at once: a hidden form field must be empty, the email address must be properly formed, and the message must contain something other than random characters. The hidden field is a honeypot — a person never sees it, a bot fills in everything it finds.
The enquiry goes into the spreadsheet. Automatically, in the same columns as always, with nothing retyped by hand.
A notification lands in the inbox. With the full message, so the enquiry can be judged without opening the spreadsheet.
A router identifies the language version. The form passes on which version of the site the enquiry came from, and the scenario directs it to the matching branch. The site has three language versions, so there are three branches.
The client gets a confirmation in their own language. Not "thank you for your message", but information about when we will reply and what happens next.
A task lands on the list. Automatically, with a due date.
There is also a separate path: anyone who would rather pick a time straight away clicks the calendar and books thirty minutes without any emails.
How long it took
| Stage | Time |
|---|---|
| Design, including choosing the tools | approx. 2 hours |
| Building the scenario | 2–3 hours |
| Testing and fixes | 2 days |
Testing took several times longer than building. That is not an anomaly and does not mean something went wrong. Every honest implementation looks like this.
Building the scenario is arranging blocks that do what they are meant to do under ideal conditions. Testing is checking what happens when somebody types an address without an at sign, submits an empty form, clicks twice, or fills it in on a different language version.
When a supplier quotes a timeline, it is worth asking how much of it is testing. If the answer is "we will test it live", it means the client will be doing the testing.
The maths: payback in six weeks
Concrete numbers, with no rounding in our own favour.
| Item | Value |
|---|---|
| Effort | approx. 5 hours |
| Enquiries in the first 2 weeks | 12 |
| Per month | approx. 26 |
| Manual handling time | 6–10 min per enquiry |
| Saved per month | approx. 3.5 hours |
| Payback | approx. 6 weeks |
| Over a year | more than 40 hours |
After two weeks we have recovered about a third of the time invested. At the lower end of the estimate, if handling took only six minutes, payback would fall at eight weeks. At the upper end — five. In every variant it comes in under two months.
On top of that come two things that are harder to count and just as real.
Spam stopped being a problem. It takes no time, because it never reaches the inbox. That is not in the table, and before the automation it was a noticeable part of the work.
The reply goes out immediately, at any hour. An enquiry sent on Saturday evening gets its confirmation on Saturday evening, not on Monday morning. When choosing a supplier, the time of the first reply is often decisive — and that is a difference manual handling cannot make up for with any amount of effort.
We put in five hours once. The process runs the same every month, regardless of holidays, workload or whether anybody looked at the inbox. After a year the balance is more than forty hours, after two — twice that, from the same one-off effort.
When it does not pay off
Not every process pays back in six weeks. The condition is simple and worth checking before the implementation, not after.
Below a dozen or so repetitions a month the maths falls apart. The same process at three enquiries a month would take over a year to pay back. That is when we tell the client plainly that it is not worth it yet.
A process without settled rules has to be described first. If three people handle enquiries three different ways, automation will cement one of them — not necessarily the best one.
Our case met both conditions from the start, and that is why the result is what it is. Not luck — a selection criterion.
What went wrong
Three things. All of them surfaced in testing, none reached a client, and all were fixed within a quarter of an hour.
The honeypot filter compared text instead of length
The hidden field was supposed to be empty. The condition checked whether its value equalled an empty string — and it did not work, because an empty form field does not always arrive as an empty string. The correct solution is to check the length of the value and compare it numerically to zero. The difference looks cosmetic and decides whether the filter works at all.
A rule assumed a checkbox that was no longer there
The form had a mandatory consent checkbox. We replaced it with an information clause, because when answering an enquiry, consent is not the legal basis for processing — taking steps at the request of the person before entering into a contract is.
The change was right, but the scenario still checked whether the consent field had the value "on". Once the checkbox was gone, that condition could never be met and would have rejected every enquiry.
This is the most interesting of the three, because it shows something easy to forget: a change on the website can break an automation that merely reads the website. If somebody changes the form, somebody has to check the scenario. That is why our implementations come with process documentation — so it is clear what depends on what.
The submission format was blocking the request
The form sent data in a format where the browser first makes an additional request to check whether the server agrees to accept data from another domain — and it can stall at that stage. Switching to a simpler format removed the step entirely.
All three surfaced during testing. Had they surfaced in production, each would have meant enquiries we would never have known about. That is precisely why testing took two days.
What we deliberately left to people
The substantive reply. The client gets an automatic confirmation, but the actual answer is written by a person. The automation does not pretend to be a salesperson.
Qualifying the enquiry. Whether the process described in the form is suitable for automation calls for judgement. We send questions, not verdicts.
Personalising content with a language model. That is the next step and it is deliberately postponed: the rule-based version has to process real enquiries first, so it is clear what the model would improve. Automating something you have not yet measured is guesswork.
When that step comes, it brings an obligation worth knowing about in advance: the recipient must be told that the content was prepared by artificial intelligence. This follows from Article 50 of the EU AI Act and has applied since 2 August 2026. We wrote about it separately in the piece on the new AI disclosure obligation.
Frequently asked questions
No. We started with a spreadsheet. A CRM makes life easier at higher volumes, but it is not a condition. You can start without one and add it later.
Automating a single process step is PLN 3,600 and five working days. A full enquiry handling process, with integrations and documentation — PLN 6,900 and ten days. Full pricing is on the pricing page.
Because we did not have to ask anyone how the process should work. With a client, the largest part of the work is settling the rules and testing them on real data, not the building itself.
It depends on the number of repetitions. At twenty-odd enquiries a month and eight minutes each — a few weeks. At a handful a month — over a year, and then we advise against it. We do the maths in the consultation, before we build anything.
It can, which is why the filter checks conditions a person does not normally breach: the hidden field stays empty, the email address is properly formed. When in doubt it is better to let spam through than to reject a client, and we set the thresholds accordingly.
Enquiries are not lost — the scenario can be resumed, and form data reaches the spreadsheet. For client implementations we also design a fallback path, so an enquiry always has somewhere to land.
You can. The difficulty is not in the tools but in the exceptions: what to do with an empty field, with an enquiry from a different language version, with a client who submits the form three times. That is where most of the time goes, and that is what the two days of testing are about.
He spent five years building operations at WebWave: from creating a support department from scratch to the role of Head of Operations and leading the integration after the company was acquired. While putting those processes in order he noticed how much time is taken up by work that develops nobody — and that the tools capable of taking it over already exist. A graduate in corporate finance from the SGH Warsaw School of Economics.
LinkedIn profile →