What people use this for
- Building the business case for an AI project
- Ranking several candidate processes against each other
- Pressure-testing a vendor's savings claim
- Deciding whether to start with an off-the-shelf tool or a custom build
Most AI ROI calculators multiply hours saved by an hourly rate and present the product as money. It is not money, and everyone who has run a project knows it. The calculator above adds the two adjustments that make the number defensible — how much of the task is genuinely automatable, and how much of the freed time turns into anything — and it will tell you not to bother when the answer is not to bother.
The number that makes most ROI cases wrong
Ten hours a week saved, at fifty dollars an hour, forty-eight weeks a year, is twenty-four thousand dollars. That figure appears in a great many proposals and it is almost never true, because a freed hour only becomes money under one of two conditions: someone is no longer employed, or that hour gets refilled with work that generates revenue.
Neither happens automatically. In practice the first chunk of any hour freed dissolves into the day — a longer lunch, a slower start, the meeting that expands to fill it. That is not a criticism of anyone; it is how work behaves. The realisation slider exists to make you state, out loud and in a number, how much of it you actually expect to recover. Sixty percent is a realistic default for most teams. A hundred percent means you are planning to reduce headcount, and you should say so.
What "automatable" honestly means
Almost no business process goes to zero human involvement, and the ones that do were usually not AI problems in the first place. The realistic ceiling is that AI does the first pass and a person checks, corrects, and owns the result. That is genuinely valuable — a good first draft removes most of the effort — but it is not the whole hour.
What tends to stay human even in a working automation:
- Checking the output, which is a permanent cost and not a transitional one
- The awkward fifteen percent of cases the system was never built to handle
- Anything requiring a judgment call the business is accountable for
- The relationship parts — the call that goes with the quote
- Owning the result when it is wrong, which cannot be delegated to software
For a process that is genuinely repetitive and well documented, sixty to eighty percent is a defensible estimate. For anything involving judgment, exceptions, or client contact, thirty to fifty is closer to what teams actually achieve.
What makes a process worth automating
The pattern is consistent enough to be predictive.
Good candidates
- High volume, low variation — the same shape of task repeatedly
- Clear inputs and a checkable output
- Text-heavy: reading, drafting, summarising, extracting, classifying
- Already documented, or easy to describe out loud
- A bottleneck, where the delay costs more than the labour does
Poor candidates
- Low volume — a few times a month will never repay a build
- Every instance different, with the rules living in someone's head
- Being wrong is expensive, unrecoverable, or regulated
- The process is broken and automation would only speed up the mess
- Nobody will own it after launch, which is how most of these actually die
How to read the payback figure
| Payback | What it means in practice |
|---|---|
| Under 6 months | Do it. This is comfortably inside the window where a project still has attention and momentum behind it. |
| 6 to 18 months | Defensible, but it needs a named owner past launch. Projects in this band fail from neglect far more often than from bad arithmetic. |
| 18 months to 3 years | Only if the process is strategically important or the tooling gets cheaper. Do not lead with this one. |
| Over 3 years, or never | The process is too small, too varied, or the effort band is wrong. Find a bigger one. |
What this model cannot capture
Two effects matter more than anything on the sliders, and neither can be estimated from four inputs. The first is quality: if the automated version is more consistent than the human one, the value is fewer errors rather than fewer hours, and that is frequently the larger prize. The second is capacity: if freed time goes into work you previously turned away, the return is revenue, not cost, and it is not bounded by the hourly rate at all.
Both cut the other way too. If the automated version is worse and the errors reach clients, the cost is not on any slider either. Use the calculator to decide what to look at first — not what to sign.
How do you calculate ROI on AI automation?
Take the hours a process consumes per week, multiply by the share AI can genuinely handle, then by the share of freed time that turns into billable or revenue work. Multiply by the loaded hourly cost and by working weeks to get annual value. Subtract annual running costs, then divide the build cost by that net figure to get payback in years. The two adjustment factors — automatable share and realisation rate — are what separate an honest estimate from a sales figure.
What is a realistic payback period for an AI project?
Well-chosen automation of a repetitive, high-volume process typically pays back in three to twelve months. Anything projecting under a month is usually understating the build cost or overstating the automatable share. Anything over two years is generally the wrong process rather than the wrong technology.
How much does it cost to automate a business process with AI?
Three broad bands. Configuring an existing tool properly and training the team runs to low thousands. Wiring existing tools together with custom glue and tuned prompts typically runs five figures. A purpose-built system integrated with your existing software is a larger project again. Budget roughly a fifth of the build cost annually for running it — licences, tokens, upkeep, and the oversight it needs to keep working.
Why do most AI automation projects fail to deliver the promised savings?
Usually one of four reasons: the automatable share was overstated because nobody counted the exception cases; the freed time was never actually redeployed, so the saving stayed theoretical; no one owned the system after launch and it drifted out of usefulness; or the underlying process was broken and automating it just produced the wrong result faster.
Should I automate my most expensive process first?
Usually not. Start with the highest-volume, lowest-variation process, even if the hourly cost is modest. It is easier to automate well, delivers a visible result faster, and teaches your team how this works before the stakes are high. The expensive process is often expensive precisely because it needs judgment — which is the hardest kind to automate and the worst place to learn.
The short version
- Hours saved are not money until someone leaves or the time gets refilled with revenue work.
- Almost nothing is 100% automatable — a person still checks, handles exceptions, and owns the outcome.
- A case that only works at optimistic settings is not a case. Test it pessimistically.
- Bottlenecks beat the maths: if delay costs more than labour, automate it regardless.
- Start with high-volume, low-variation work, not with your most expensive process.