An AI automation is worth building when its current annual process cost, minus the manual work and operating cost that will remain, produces enough net benefit to repay the build within an acceptable period. Calculate that with measured volume, handling time, loaded labour, rework and error costs—not hours saved multiplied by salary alone.
Step one: what the process costs today
Volume per month, times minutes per item, divided by sixty to turn those minutes into hours, times the loaded hourly cost of the people doing it. That gives a monthly cost; multiply by twelve for the annual one the comparison below uses. Loaded means salary plus employer taxes, benefits and the share of overhead that person carries - usually somewhere between 1.25 and 1.4 times base pay, not base pay itself.
Two additions that most cases skip. Rework: the share of items that come back and have to be handled again, at whatever they cost the second time. And the cost of the error itself, which is where the interesting money hides - a mis-keyed order is not thirty minutes of labour, it is a shipment, a return and a phone call with a customer.
Step two: what stays manual
This is the term that separates a real estimate from a sales pitch. No automation of an unstructured input goes to a hundred percent. There will be a share of items the system will not decide on its own, and they will be the awkward ones, so they take longer than average to handle.
Estimate that residual honestly and use a pessimistic number. If you assume fifteen percent goes to a human, plan on twenty. An automation that handles eighty percent of the volume is an excellent outcome; one that was sold as handling a hundred percent and handles eighty is a failed project. Same system, different promise.
Step three: what it costs to run
- Infrastructure and model usage. Usually the smallest line, and usually metered per item, so it scales with volume rather than sitting there as fixed cost.
- Maintenance. Vendors change APIs, models change behaviour, your own systems get upgraded. Something touches the workflow every few months whether you plan for it or not.
- Not exception handling. Somebody does work that queue, and that time is real, but it is the residual manual cost from step two. Counting it here as well subtracts the same labour twice and makes every payback look worse than it is.
- Improvement. Optional, but it is the difference between a system that is as good in year two as it was on launch day and one that has quietly got better.
Step four: the actual comparison
| Term | How to get it | Typical mistake |
|---|---|---|
| Current annual cost | Monthly volume × minutes per item ÷ 60 × loaded hourly rate × 12, plus rework and error cost | Using base salary, and timing only the easy items |
| Residual annual manual cost | Annual volume × expected exception rate × longer handling time ÷ 60 × loaded hourly rate | Assuming this is zero, or leaving it monthly while everything around it is annual |
| Build cost | One agreed price, quoted after the free initial audit and approved before delivery begins | Leaving your own side out. The audit costs nothing; the access, the sample and the decisions it needs are your team’s time |
| Annual run cost | Usage + maintenance + improvement | Forgetting maintenance entirely, or counting the exception queue here as well as in the residual above |
| Payback | Build ÷ ((current − residual − run) ÷ 12), in months - divide the annual figures above by twelve first, or the answer comes out in years | Comparing build cost against gross hours saved |
If the payback lands inside a year on a workflow whose rules are stable, it is usually worth building. If it needs three years of perfect operation to break even, the assumptions will not survive that long, and you should not build it.
Why recovered hours are not saved money
Removing four hundred hours of manual work a month does not reduce payroll by four hundred hours unless you actually reduce headcount, and most of our clients have no intention of doing that. What you get is capacity.
Capacity turns into money in three specific ways, and it is worth being precise about which one applies to you:
- 1It absorbs growth you would otherwise have hired for. This is the most common and the most defensible: the next twenty percent of volume arrives without the next two hires.
- 2It clears a backlog that is costing you revenue - quotes going out late, invoices going out slowly, customers waiting.
- 3It moves experienced people off data entry and onto work only they can do. Real, but the hardest of the three to put a number on, so we do not lead with it.
Estimated capacity value, not guaranteed savings. If a vendor tells you the second thing, ask which of the three mechanisms above turns their number into cash.
The signals that decide it before the arithmetic does
Some workflows are worth automating and some are not, and you can usually tell before you open a spreadsheet. Good candidates have high volume, stable rules, a clear owner, and a cheap failure mode. Bad candidates are rare, judgement-heavy, politically contested, or built on a process that is about to change anyway.
The one that fails quietly
A process that is genuinely broken. Automating it makes it produce wrong answers faster and at greater scale. If the rules cannot be written down because the business does not agree on them, the problem is not technology, and no amount of AI will fix it.
We publish a calculator that does the first version of this arithmetic in about a minute. It is deliberately conservative and it will not tell you what you want to hear.