Search for what AI automation costs and you will find a hundred articles that carefully avoid saying anything. I understand why — the honest answer is "it depends" — but that is useless if you are trying to budget.
So let me explain what it actually depends on, so you can estimate your own situation and tell a fair quote from a bad one.
Why nobody gives you a number
Two people ask for "an invoice automation."
The first has clean data in one system, a clear approval rule, and one email template. That is a few days of work.
The second has invoices in three places, four exceptions to the approval rule that only one person knows about, a legacy system with no API, and a compliance requirement for audit trails. Same sentence, three weeks of work.
This is why any provider who quotes a firm price before understanding your process is either padding heavily to cover the unknown, or is about to find out they underquoted and deliver something rushed.
What actually drives the price
Five factors, roughly in order of impact.
1. Number of systems that must talk to each other
The biggest single driver. Two systems with good APIs is straightforward. Five systems, one of which is a legacy tool with no API and a login page that changes, is a different project entirely. Every integration adds surface area for things to break.
2. How messy the input is
A structured form is easy. Free-text emails from customers who each describe the same thing differently is hard, and needs an AI layer plus a fallback for when the AI gets it wrong.
3. The cost of being wrong
A social media scheduler that misfires is embarrassing. A payment system that misfires is a serious problem. High-stakes automations need validation, approval steps, audit logging and far more testing — and that testing is often longer than the build.
4. Rules versus judgement
Fixed rules are cheap. Genuine judgement — where the right action varies and an agent must decide — costs more to build, more to test, and more to run.
5. Who maintains it afterwards
A system built to be handed over needs documentation, clear naming, and a human who understands it. That work is real, and it is what separates a system you own from one you are permanently dependent on someone else for.
Running costs people forget
The build is a one-off. These are monthly, and they are where budgets quietly break.
| Cost | Notes |
|---|---|
| Platform fees | Zapier and Make charge per task or operation, so cost scales with success. Self-hosted n8n is a flat server cost instead. |
| AI model calls | The one that surprises people. A simple automation makes one call per run. An agent makes several, sometimes many. |
| Hosting | Only if self-hosting. A small VPS covers a lot, but someone has to own updates and backups. |
| Third-party APIs | Enrichment, transcription, document parsing. Each has its own meter. |
| Maintenance | APIs change, credentials expire, business rules shift. Budget for this even if nothing appears to be wrong. |
The one that catches people: agent-based systems make multiple model calls per task. A workflow that seems cheap in testing at ten runs a day can look very different at a thousand. Always model your cost at expected volume, not at test volume.
The payback calculation
This is the only calculation that matters, and it is simple enough to do on paper.
- Hours saved per month. Be honest and count the whole task, including the context-switching around it.
- Multiply by the loaded hourly cost of whoever does it now — salary plus overhead, not just salary.
- Subtract monthly running costs.
- That is your monthly gain. Divide the build cost by it to get payback in months.
Worked example. A task takes 5 hours a week — about 21 hours a month. The person doing it costs $25/hour loaded, so that is $525/month of time. Running costs are $60/month. Net gain: $465/month. If the build costs $1,400, payback is roughly three months, and everything after that is upside.
As a rule of thumb: payback under six months is a clear yes. Six to twelve is worth doing if the process is stable. Beyond eighteen months, the process will probably change before you break even.
And note what this calculation deliberately ignores — the second-order benefits. Faster response times winning deals, fewer errors, work happening at 2am, and the fact that the person freed up is now doing something more valuable. Those are real, but they are harder to defend in a budget conversation, so treat them as upside rather than justification.
When it is not worth it
I turn down projects for these reasons regularly, and you should be suspicious of anyone who never does.
- The process changes every month. You will spend more maintaining it than you save.
- It runs a handful of times a year. Low frequency rarely justifies build cost.
- Nobody can explain the current rules. If three people describe the process differently, you do not have a process yet — you have a habit. Fix that first.
- The real problem is upstream. Automating a broken workflow makes it break faster and at scale.
- Judgement is the whole job. Some tasks look repetitive but rely on context a human has and a system does not.
Questions to ask any provider
These separate people who build systems from people who build demos.
- What happens when it fails? A good answer describes retries, alerts and a fallback. A bad answer is "it won't."
- What will this cost me to run each month, at my volume? They should be able to estimate this before building.
- Who owns the system? Is it on your infrastructure and accounts, or theirs? This matters enormously if the relationship ends.
- What happens if the API changes? Is that covered, or is it a new invoice?
- Can my team maintain this? If the honest answer is no, that is fine — but you should know it up front.
- What would you not automate here? Anyone who says everything is worth automating is selling, not advising.
The last one is my favourite. The most useful thing a consultant can tell you is which parts of your process should stay human — and someone willing to say that is usually worth listening to on the rest.