Automation ROI, Honestly

Hours saved times hourly rate is not a saving. It is a saving only if the hour goes somewhere.

Nearly every automation business case has the same first line: hours saved multiplied by an hourly rate. It is easy to compute, it produces a satisfying number, and it is almost always wrong.

It is wrong in a specific and correctable way, and it is worth fixing, because the honest version of the calculation is usually still positive. It is just positive for different reasons than people expect.

Why hours saved is a weak number

Suppose an automation removes fifteen minutes a day from an administrator's work. That is about 65 hours a year. At a loaded cost of $45 an hour, the business case writes itself: roughly $2,900 a year saved.

Except nothing has been saved. That administrator is still employed, still paid the same, and still works the same hours. What has changed is what they do with fifteen minutes of them.

The saving is real only under one of two conditions. Either the freed time is redeployed to something that generates value (the administrator now handles more client requests, or takes work off someone more expensive), or the headcount genuinely changes, meaning a role is not backfilled or a contractor is not renewed.

If neither is true, you have not saved $2,900. You have made someone's day slightly less irritating, which is worth something, but it is not worth $2,900 and it will not appear anywhere in your accounts.

There is a second failure mode worth naming. Fifteen minutes a day spread across six people is not 65 hours of anything. It is six people each getting two and a half minutes back, which reliably converts into zero measurable output. Concentrated time can be redeployed. Diffuse time evaporates. When you see a business case that aggregates small savings across many people into one impressive total, that is the number to interrogate first.

Count the errors, properly

Here is the line that is usually missing, and it is usually the biggest one.

Every manual process has an error rate. Those errors have costs, and the costs are systematically underestimated because they are delayed and spread out. A mistyped figure costs the two minutes to type it wrong and then, six weeks later, forty minutes of somebody tracing a discrepancy, twenty minutes fixing it, and an awkward conversation with a client.

To count this defensibly, use your own history rather than a published error rate. Go back twelve months and list the incidents that traced back to the process you are considering. For each one, add up the time to detect, the time to fix, the downstream rework, and any client cost. It will be a smaller list than you fear and a larger total than you expect, and unlike an industry benchmark it will survive scrutiny, because every line is something that actually happened to you.

Then apply judgement about what the automation removes. A deterministic process does not make transcription errors, so it removes that whole category. It does not remove logic errors, and it can introduce a new failure mode of its own, which is doing the wrong thing very quickly and consistently. Count the categories you actually eliminate, not all of them.

Count the things nobody puts in the spreadsheet

Three more lines belong in the case, and they are usually left out because they are harder to defend.

Revenue that stops leaking. If enquiries are being missed, the value of not missing them is not a time saving at all, it is revenue. Even a conservative estimate here often dwarfs every efficiency line in the model. Take your actual enquiry volume, your actual close rate, and your actual average value, and be deliberately pessimistic about the uplift.

Capacity you can use without hiring. If the process is a constraint on growth, so that you cannot onboard more clients this month because onboarding takes a person a day, then removing it is worth more than the hours. It is worth the margin on the work you can now accept.

Risk you stop carrying. Some processes have a small chance of a large loss: a compliance deadline, a payment run, a regulatory filing. Reducing that probability is worth money even in the years nothing goes wrong, and insurers price exactly this every day.

Then subtract the parts people forget

Against all of that, three costs:

The build. Including discovery. Working out the edge cases is commonly a third of the project, and omitting it is the single most common reason a case that looked comfortable comes in over.

Maintenance. Budget 15 to 20 percent of build cost per year for anything integrating third-party systems. APIs change, credentials expire, upstream vendors ship breaking updates on their schedule and not yours. An automation nobody maintains is not a neutral asset, it is a liability with a delay fuse, because it will eventually fail quietly and nobody will be watching.

The transition. For a period, people run the old way and the new way at once, and things are slower than either. That period is real and it is a cost.

What an honest case looks like

For the Xero onboarding work, the time saving per client is a few minutes. Multiplied out across a year it is a real number, but it is not the number that justified the project and it would have been dishonest to present it as such.

What justified it was the error line and the reconciliation line: client records that no longer acquire transcription defects, and two systems that agree without anyone making them agree. Neither of those appears in an hours-saved calculation, and together they are worth several times the time saving.

If your business case does not have at least one line arguing against the project, you have not finished writing it. The maintenance figure, the transition dip, and an honest statement that some of the saved time will simply evaporate: put them in. A case with its weaknesses stated is far more persuasive than one without, because the person reading it can see you looked.

Key takeaways

Saved hours are not saved moneyAn hour freed only becomes money if it is redeployed to something that earns or if headcount actually changes.
Count avoided errors properlyError avoidance is usually the biggest real line and the one nobody quantifies, because the cost is spread out and delayed.
Budget for maintenance from day oneAn automation that nobody maintains is a liability with a delay fuse. Put a real number against it.

Frequently asked

So are hours saved worthless?

No, but they are worth what they are redeployed to, not what they cost. Forty hours a year freed from a senior person who then does more client work is genuinely valuable. Forty hours spread as three minutes a day across six people is real relief and near-zero measurable saving, and it is honest to say so.

How do you put a number on avoided errors?

Count the incidents you actually had over the last year, and estimate the full cost of each: the time to find it, the time to fix it, any rework downstream, and the client-relationship cost where there was one. Use your real history rather than an industry error rate, because your history is the only evidence that will survive a sceptical CFO.

What is a realistic maintenance figure?

Budget 15 to 20 percent of the build cost per year for something integrating third-party systems, more if any of those systems ship breaking API changes. If that turns the payback negative, the project was marginal to begin with and you have learned something cheaply.

Should we count the time we spend specifying the automation?

Yes. Discovery and edge-case definition are real costs and they are often a third of the project. Leaving them out is the most common reason a business case that looked fine comes in over.

What if the main benefit is not financial at all?

Then say that plainly rather than manufacturing a number to justify it. Not losing enquiries, or removing a task everyone hates, can be perfectly good reasons. A fabricated ROI figure is worse than an honest qualitative case, because the first person to check the arithmetic stops believing the rest of it.