The automation business case: what the ROI calculation leaves out

An automation business case is usually built from an hourly rate times hours saved, and that calculation is wrong in two directions at once: it overstates the benefit by counting hours that never leave the payroll, and it understates the cost by omitting everything after go-live.

Below: the benefit that is real and the one that is not, the costs routinely left out, why the regional rate changes the answer, and what a defensible case looks like.

Nearly every automation proposal contains the same figure: hours saved per month times a fully loaded hourly cost, annualised. It is easy to produce, easy to present, and it does not survive contact with the finance team that has to book the saving.

The version that survives is not more complicated. It is more honest about which of the numbers are cash and which are capacity.

That distinction is not accounting pedantry. It decides whether the programme gets a second round of funding, because the first round is judged on whether the promised number appeared anywhere a controller can see it.

The benefit that is real and the one that is not

Hours saved become money in three ways only: a role is not backfilled, an increase in volume is absorbed without hiring, or an external cost — overtime, a contractor, a service — stops being paid. Everything else is capacity.

Capacity is genuinely valuable and it is not a saving, and presenting it as one is what makes the second-year conversation difficult. Twenty hours a month released across eight people does not reduce any cost, and finance is right to say so.

The stronger position is to state both separately: this much cash, this much capacity, and here is what the capacity is for. A named use for the released hours converts a soft benefit into a commitment somebody owns.

The costs routinely left out

Maintenance. Two to three hours per automation per month is a reasonable planning figure. Over three years it frequently exceeds the original build cost.

Licences and infrastructure, which are usually per-process or per-bot and grow with the estate rather than staying flat.

The exception handling. Ten per cent of cases still needing a person is not ten per cent of the original effort — exceptions are the slow cases, and the residual effort is commonly a quarter of the original.

The change effort: the process documentation, the testing, the training and the time the operating team spends validating. Real, budgeted nowhere, and taken from the people who have the least slack.

Why the regional rate changes the answer

Most automation business cases circulating as templates were built on salary levels that do not apply in Colombia or Mexico. The same process saving the same number of hours produces a materially smaller benefit here, while the licence is priced in dollars.

That combination shifts the threshold. Processes that clear the bar comfortably in a market with high labour costs sit marginally in this one, and the ones that pay are those with high volume rather than high complexity.

The exchange rate deserves an explicit line rather than a footnote. A case built at one rate and reviewed a year later at another can move from positive to negative without anything about the process changing, and that is a foreseeable risk rather than a surprise.

Who should build the case

Not the supplier, and not the automation team alone. Both have an interest in the answer, and a case built by an interested party gets discounted in the room where it is decided — often more heavily than its errors deserve.

The arrangement that carries weight is a case where the process owner supplies the baseline, the automation team supplies the effort estimate, and finance agrees the method before any number is produced. Agreeing the method first is the part that saves the argument.

It also changes what gets proposed. A team that knows finance will ask which line of the budget improves tends to bring forward processes where that line exists, which is a better portfolio than one selected on enthusiasm.

The benefits nobody quantifies but should

Error reduction is usually the largest unclaimed benefit, and it is measurable: the current correction rate times the cost of a correction, including the downstream work a wrong figure causes.

Cycle time is the second. A process that completed in three days and now completes in three hours may unlock something with real value — a faster close, an earlier collection, a customer commitment that can be made with confidence.

Both require a baseline measured before the automation exists, which is the single cheapest thing on this list and the one most often skipped. After go-live, the pre-automation figure is unrecoverable and the benefit becomes an assertion.

A third, harder to price but worth naming, is the reduction in key-person risk. A process that only one person knows how to run is an exposure the organisation carries without measuring, and documenting it well enough to automate removes that exposure whether or not the automation is ever built.

The comparison that is missing

Almost every case compares automating against doing nothing. The comparison that matters is against the alternatives: simplifying the process, removing the step entirely, buying a system that already does it, or negotiating the requirement away.

Automating a process that should not exist is the most expensive outcome available, and it is reached by a business case that never asked the question.

A useful discipline is to require every automation proposal to state why the process cannot simply be eliminated or simplified first. The answer is often good; the cases where it is not are the ones worth catching.

The same question applied to the sequence is equally useful. A process about to be replaced by a system migration in eighteen months should not be automated now, and that fact is usually known by somebody who was not asked.

What a defensible case looks like

Cash benefit and capacity benefit stated separately. Three-year costs including maintenance and licences. A baseline measured before the build. An explicit alternative that was considered and rejected. And an exchange rate assumption written down.

It is longer than the template and it is defensible in a room where somebody is trying to find the flaw — which is where these cases get decided.

It also produces better decisions inside the programme. A portfolio ranked by an honest number is ranked differently from one ranked by an optimistic one, and the difference tends to be the processes that were about to consume a year for little return.

Where to start

With the baseline. Volume, elapsed time, exception rate, correction rate — all measurable on the manual process, all unrecoverable once it changes. Two weeks of measurement before the build is the cheapest insurance available anywhere on the entire programme, and it is almost never done.

A process automation assessment establishes those and calculates the return with local costs and local rates, so the automation plan is ranked by what will actually pay rather than by what presented best.

Frequently asked questions

How should automation ROI be calculated?

By separating cash from capacity. Hours become money only when a role is not backfilled, growth is absorbed without hiring, or an external cost stops being paid. Everything else is capacity and should be stated as such.

Which costs are usually left out?

Maintenance at two to three hours per automation per month, per-process licences and infrastructure, the residual effort on exceptions, and the change effort borne by the operating team.

Why does the region change the calculation?

Labour costs in Colombia and Mexico are lower while licences are priced in dollars, so the same process produces a smaller benefit against a similar cost. High volume matters more than high complexity here.

What is the most under-claimed benefit?

Error reduction — the current correction rate times the cost of a correction including downstream work. It requires a baseline measured before the automation exists.

What comparison is usually missing?

Against simplifying the process, eliminating the step, or buying a system that already does it. Automating a process that should not exist is the most expensive available outcome.

What makes a case defensible?

Cash and capacity separated, three-year costs including maintenance, a measured baseline, a rejected alternative named, and the exchange rate assumption written down.