Most automation ROI numbers are wrong because they only measure the happy path. A vendor demo shows the automation doing the thing it does well, timed against a person doing it slowly, and the difference gets multiplied by volume and called savings. That number is real. It is also incomplete, and the missing pieces usually cost more than the pilot ever accounted for.
Start with the number that gets sold
The pitch is always some version of the same sentence: this saves you X hours a week. Say a support team handles 400 tickets a month, each one takes 15 minutes to triage and route, and an automation can do that instantly. That is 100 hours a month of triage work removed. At a loaded cost of £25 an hour, that is £2,500 a month, gross. This is the number in the sales deck, and it is the number most internal business cases stop at.
It is not fake. It is just half the ledger.
What the gross number leaves out
Build time is the first omission, and it is rarely small. A workflow that “just” routes tickets by category still needs someone to map the categories, handle the ones that do not fit cleanly, and connect it to whatever system holds the ticket data. If that takes forty hours of a specialist’s time at a higher rate than the ticket handler’s, the first month is a loss before the automation has processed anything. Anyone scoping this properly builds a time estimate for the workflows involved before promising a payback date to a stakeholder.
Maintenance is the second, and it does not stop. APIs change their response shape, a category gets renamed in the source system, someone adds a new ticket type nobody scoped for. None of these break the automation loudly — they break it quietly, and someone has to notice, diagnose, and fix. Budget an ongoing hour or two a week for this on anything nontrivial, because zero is not a real answer and treating it as zero is how automations rot in place.
Exception handling is the third, and it is the one that changes the maths most. No automation resolves everything; some fraction of cases fall outside what it was built to handle, and those still need a human — often one who now has to figure out why the automation didn’t handle it before doing the work manually. If a fifth of tickets need a human anyway, the 100 hours saved is really closer to 80, and someone still has to monitor the fifth to make sure it is not silently misrouted rather than flagged.
Review time is the fourth, and it is the one people budget for during the pilot and forget about after. Early on, someone checks the automation’s output regularly, because trusting it blind after two weeks is how a routing error becomes a missed SLA that nobody caught for a month. That review time shrinks over time but rarely reaches zero, and it needs to be someone’s actual job, not an assumption.
Redoing the maths honestly
Take the same example and add the missing pieces as assumptions, made explicit rather than hidden. Suppose build takes 40 hours at £40/hour (£1,600), maintenance runs 6 hours a month at £30/hour (£180), exception handling claws back 20 of the 100 hours saved, and review costs another 8 hours a month at £30/hour (£240). Net hours saved per month become roughly 80, worth £2,000 at the ticket handler’s rate, minus £420 a month in maintenance and review. Net monthly benefit is around £1,580, and the one-off £1,600 build cost is recovered in roughly a month rather than paid back instantly. That is still a good result — it is just a different number from the one in the pitch deck, and it is the number that should go in front of whoever signs off the budget.
Where this maths says stop
If the exception rate is high, or the process changes shape often enough that maintenance never settles down, the honest version of the calculation can turn negative even when the gross-savings version looks great. That is not a failure of execution; it is a signal the process was the wrong candidate for automation in the first place, and a person who builds these things for a living will tell you that before they build it, not after. This is the actual value of bringing in outside services for the first few of these: not the build itself, but a second opinion on whether the process is even a good fit before four figures of build cost go in.
The honest version of this maths is not a reason to avoid automation. It is a reason to run the calculation properly before committing, and to keep measuring the same four missing numbers after launch, because a process that looked stable in the pilot can start generating more exceptions six months later as the business around it changes.