Most automation business cases are one multiplication: hours saved times hourly rate. That number is always large and almost always wrong. Here is the arithmetic we actually use before we agree to build anything.
Step one: what the process costs today
Volume per month, times minutes per item, times the loaded hourly cost of the people doing it. 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.
- Exception handling. Somebody works the queue. That person’s time is an operating cost of the automation, not an afterthought.
- 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 | Volume × minutes × loaded rate × 12, plus rework and error cost | Using base salary, and timing only the easy items |
| Residual manual cost | Expected exception rate × longer handling time × loaded rate | Assuming this is zero |
| Build cost | Fixed implementation price | Treating discovery as free |
| Annual run cost | Usage + maintenance + exception handling | Forgetting maintenance entirely |
| Payback | Build ÷ (current − residual − run), in months | 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.