Every automation supplier gives the same answer to this question — “it depends” — and every buyer hears it as evasion. It is not, but the people saying it rarely explain what it depends on, which is the part you can actually use.
So here is the breakdown, including the bits that make a project expensive.
What drives the number
How well the process is understood. This is the single largest variable and it has nothing to do with technology. A process someone can describe accurately in an hour costs a fraction of one where three people describe it three different ways and all of them are partly right. If you do nothing else before getting quotes, get one person to write down what actually happens, step by step, including the exceptions.
How many systems have to be touched. Reading an email and sending a reply is one thing. Reading an email, checking a record in a CRM, pricing against a spreadsheet somebody maintains by hand, writing to a finance system with no API and notifying someone on Teams is another. Each integration is a fixed cost, and the ones without an API cost several times the ones with.
How bad it is to be wrong. A workflow that drafts an internal summary can be built quickly. A workflow that sends something to a customer, moves money or affects a person’s application needs confidence thresholds, exception routes, an audit trail and an approval step. That is not padding — it is most of the difference between a demo and a system you can defend.
How variable the input is. Invoices from five regular suppliers in fixed formats are a different problem from invoices from four hundred suppliers in any format. Both are solvable. They are not the same price.
Volume, but less than you would think. Volume affects the running cost and the return, not usually the build. Automating something that happens twice a month costs roughly what it costs to automate something happening two hundred times a day — which is exactly why low-volume processes are often not worth automating at all.
The shape of the spend
Most projects have three parts, and the proportions surprise people:
- Discovery is a small fraction of the total and reliably saves more than it costs. Skipping it is the most expensive decision available to you.
- Build is the largest part, and is roughly proportional to integrations and exception handling rather than to how clever the AI is.
- Running costs are usually modest — model usage, hosting, and the attention someone pays to the exception queue. Ask for this figure specifically. A build quote without a running cost is half a quote.
Estimating your own number before you speak to anyone
You can get surprisingly close on your own.
- Count how many times a person picks up one item of work from arrival to done. Not how long it takes — how many separate touches.
- Estimate the time per touch, honestly. People underestimate this by about half, because the interruption cost is invisible.
- Multiply by volume and by the loaded cost of the person doing it. For a firm that bills time, use the rate you could have charged instead, not the salary — that is the real figure.
- That is your annual cost of the process as it stands. A project that pays back inside a year is straightforward to justify; one that pays back in three is a strategic decision rather than an operational one.
If step 4 gives you a number smaller than a decent laptop, the honest answer is that this process is not worth automating yet. We would rather tell you that on a call than after a quote.
What to ask a supplier
- What happens when the model is not confident?
- Who approves output before it reaches a customer?
- What is the running cost, separately from the build?
- What happens if we want to change the rules in six months — do we call you?
- Do we own what you build?
The answers to those five tell you more about the eventual cost than any day rate will.