Every first call about AI automation reaches the same question, usually about forty minutes in and usually phrased apologetically: so what does something like this actually cost?
It's a fair question and it deserves a real answer rather than "it depends on scope." Scope does decide it — but the ranges are knowable, and more importantly, whether a project is worth doing at all comes down to three numbers you can work out yourself before you ever talk to anyone.
Here's how we think about both.
What a pilot actually costs
A pilot is not a proof of concept. A proof of concept demonstrates that something is technically possible and then gets thrown away. A pilot runs on real data, with real users, doing real work, and it either earns its place in your operations or it gets switched off. Only the second kind is worth paying for.
Realistic ranges for a single, well-scoped automation:
Small — a few thousand euros. One process, one system, no new interface. Inbound forms routed into your CRM with enrichment and notification. Invoice data extracted from PDFs into your accounting tool. A weekly report that assembles itself. Two to four weeks. This is where most companies should start, and most don't, because it feels too modest to be exciting.
Medium — five figures. Several systems talking to each other, a human approval step, a simple interface for the people who run it. Order intake that reads emails and attachments, drafts the order, and waits for a person to confirm. A support triage layer that answers the repetitive half and escalates the rest. Six to twelve weeks.
Large — well into five or six figures. A system with its own data model, permissions, an audit trail, and multiple user roles. A client portal. An internal agent with access to your own tools. Three months and up, and it should almost never be the first thing you build.
Two costs get forgotten in every single budget we've reviewed:
Running costs. Model usage, hosting, third-party APIs. Usually small — tens to low hundreds of euros a month for a typical workflow — but not zero, and they scale with volume rather than with headcount.
Maintenance. Systems change. A supplier redesigns their invoice template, an API version is deprecated, someone renames a field in your CRM. Budget something ongoing for this, or accept that the automation will quietly stop working in month seven and nobody will notice for a while.
The three numbers
Before the price matters, work these out. They take an afternoon and they'll tell you more than any vendor conversation.
Number one: hours per month, counted honestly
Not "we spend a lot of time on this." Actual hours. Pick the process, ask the person who does it to note the time for two weeks, and multiply.
Count the whole thing: the doing, the checking, the chasing, the re-doing when something arrived in the wrong format, and the switching cost of being interrupted. That last one is real and people always leave it out.
If the honest total is under five hours a month, stop. It's not that automation wouldn't work — it's that the payback window is too long to survive the first change of priorities.
Number two: the cost of an error, times how often it happens
Some processes are cheap in time but expensive in mistakes. A pricing error sent to a customer, a missed deadline, an order entered against the wrong account. Put a number on one occurrence — including the time spent fixing it and the relationship cost — and multiply by frequency.
This is where automation often justifies itself even when the hours are modest. A process that takes three hours a month but produces one costly mistake per quarter is a better candidate than a ten-hour process that never goes wrong.
Number three: how many exceptions the process has
This one decides feasibility, not value, and it is the number that kills most projects after the money has been spent.
Take a hundred recent instances of the process. How many followed the standard path exactly? If it's ninety or more, you have a strong automation candidate. If it's sixty, you have a process that needs redesigning before anything is automated — otherwise you'll build a system whose main output is exceptions for a human to handle, which is the work you were trying to remove.
The honest version of this conversation is usually: let's fix the process first, then automate the fixed version. That's cheaper and it works. It's also the recommendation clients least expect to hear from someone selling automation.
Putting the three together
Multiply hours by a loaded hourly cost, add the error cost, and you have annual value. Compare it to build cost plus a year of running and maintenance.
A rule of thumb we use: if the payback is longer than twelve months, don't build it yet. Not because the maths fails, but because organisational patience doesn't last longer than that. Priorities shift, the sponsor moves teams, and a system that hasn't yet paid for itself is the easiest thing to cancel.
Under six months, it's usually obvious and you should have done it already. Between six and twelve, it's a real decision that depends on whether the process is stable enough to be worth locking in.
Why so many pilots never reach production
Industry surveys keep reporting that the large majority of AI pilots never make it into day-to-day operations. In our experience the reason is rarely the technology. It's one of these:
- No owner. Nobody inside the company is responsible for the system after handover, so nothing gets adjusted when reality shifts.
- Wrong first project. Something impressive was chosen instead of something boring and frequent. Impressive demos don't survive contact with edge cases.
- The process was never stable. See number three.
- No measurement. Nobody wrote down the baseline before, so nobody can prove the improvement after. Without proof, renewal is a matter of opinion.
All four are avoidable, and all four are decided before a single line of code is written.
What to ask any vendor, including us
- What exactly runs in production at the end, and what is thrown away?
- Who owns it afterwards, and what does handover include?
- What are the running costs per month at our volume?
- What happens when a source system changes?
- What's the baseline measurement, and how will we know in three months whether this worked?
If the answers are vague, the price is irrelevant.
If you want to work the three numbers out for one of your own processes, we wrote a step-by-step version of that exercise: Find the Ten Hours: A Process Audit You Can Run Without Us. It's designed to be useful whether or not you ever hire anyone.
