Most automation business cases follow the same shape. Someone estimates the hours a task consumes, multiplies by a salary figure, compares it to a quoted project cost, and produces a payback period.
The number is almost always wrong, usually optimistic, and it omits the costs that determine whether the project was worth doing.
What the standard calculation misses
Ongoing running cost. Infrastructure, API calls, model inference, monitoring. For AI-based automation this can be substantial and it scales with volume — precisely the dimension the business case assumes will grow.
Maintenance. Vendor APIs change. Dependencies need updating. Edge cases surface. A reasonable planning assumption is that a system requires meaningful attention every year, indefinitely. An automation is not a purchase; it is an ongoing commitment.
The exception path. Automation rarely handles 100% of cases. If it handles 85%, someone still processes the other 15% — and those are now the hardest 15%, because the easy ones were removed. The remaining work is slower per case than the average used to be.
Change cost. Training, documentation, the period where people run both processes in parallel and trust neither. Real, and routinely omitted.
Evaluation cost, for AI systems specifically. A test set has to be built and maintained, quality has to be monitored, and drift has to be detected. Skip it and you have an unmaintainable system that will be switched off after its first visible failure.
Freed time is not saved money
This is the assumption that quietly invalidates most business cases.
If automation removes forty minutes a day from eleven people, the company has not saved a salary. It has redistributed 7.3 hours daily across eleven people who will fill it with other work — quite possibly valuable work, but not work that appears in the calculation.
The saving is real only when one of these is true:
- A hire is genuinely avoided, and would otherwise have been made. Not "we might need someone eventually" — an approved requisition.
- Volume grows without headcount growing. Often the strongest case: the process now scales sub-linearly with the business.
- The freed time goes to something with an identifiable value that you can name.
- The team was already over capacity and the alternative was overtime or attrition.
If none of those hold, the benefit may still be real — lower error rates, faster response, reduced key-person risk — but it is not a cost saving, and presenting it as one damages the credibility of the next proposal.
Count the benefits that are not time
Several genuine benefits never appear in an hours-based calculation:
Error reduction. If manual transcription produces a background error rate, and each error costs something to detect and fix, that is quantifiable. Usually with better precision than the time saving.
Speed as revenue. Faster response times can improve conversion. This is measurable, but only if you had the instrumentation before the change — which is an argument for measuring first.
Capacity under peak load. Volume peaks that used to require overtime or degrade service now do not. Real value, and difficult to see in an average.
Reduced key-person risk. When a process exists only in one person's head, their absence is an operational risk. Automating it converts tacit knowledge into documented, testable rules — often the most valuable output, and never in the spreadsheet.
Measure the current process first
The most common practical failure is having no baseline.
If you do not know today how long the process takes, how many cases it handles, or what its error rate is, you cannot demonstrate improvement afterwards. You will be left arguing from impression, which is where automation projects go to be quietly deprioritised.
Measure for a few weeks before building. It is inexpensive, it improves the estimate, and it occasionally reveals that the problem is somewhere other than where everyone assumed.
When the honest answer is "don't build it"
There are several situations where declining is correct:
- The process is about to change. Automating a workflow scheduled for redesign is money spent twice.
- Volume is too low. The tuning and maintenance cost exceeds the benefit. This applies more often than people expect for AI systems specifically.
- The process is wrong. Automating a bad process faithfully preserves it and makes it harder to change. Sometimes the correct recommendation is to redesign first and automate later.
- Nobody will own it. An automation without an owner degrades until it is switched off. If no one on the client side will take it, the project has already failed.
We tell clients this regularly, and it is not altruism. Selling work that should not exist is the fastest way to lose a client permanently.
A defensible calculation
Costs: build + first-year running + estimated annual maintenance + evaluation (for AI) + change management.
Benefits: avoided hires that were actually planned + measured error reduction + measured speed effects + capacity headroom + documented risk reduction.
Compare against: the current process, measured — not the current process as remembered.
The resulting number will be less impressive than the standard calculation. It will also survive scrutiny, and it will tell you which projects are genuinely worth doing — which is the only reason to run the exercise at all.