Most automation return on investment figures do not survive contact with a finance team, and the reason is usually that the baseline was reconstructed after the fact. Once the old process is gone, everyone remembers it as slower and more error-prone than it was.
The fix is unglamorous. Measure the manual process before you replace it, and agree in advance what would count as success.
Capture the baseline first
- Time the process end to end, across enough instances to cover the awkward cases rather than the clean ones.
- Record the error rate and, separately, the cost of a typical error including the rework it causes.
- Note the volume, and whether it is stable or seasonal.
- Record who does it and what they would otherwise be doing, because that is where the value actually appears.
That fourth point is the one teams skip and the one that decides whether the saving is real. Hours freed from a role with no queue of higher-value work behind it are a comfort rather than a return.
The costs that get left out
Build cost is the easy number. The ones that get forgotten are the ongoing model or platform usage, the monitoring somebody has to do, the exception handling that now lands on a person, and the maintenance when an upstream system changes its format. A model that ignores these produces a payback period that quietly doubles in year two.
The honest number is almost always smaller than the first estimate and still comfortably worth doing. The projects that get cancelled are usually the ones that promised the inflated figure.
Ethan Caldwell, CTO & Co-Founder, Engineered With AI
Separate the automation from everything else that changed
Automation projects almost always arrive alongside a process redesign, because writing the process down forces improvements before any software is built. That means part of the benefit belongs to the documentation rather than to the system. Crediting all of it to the automation overstates the case and makes the next project harder to assess.
Time saved is a weak headline on its own
Hours saved is easy to compute and easy to dismiss. Stronger measures are throughput at the same headcount, reduction in rework, cycle time from request to completion, and the error rate at volume. Those connect to something a business actually feels.
What a defensible report looks like
One page. The baseline as measured, the post-launch measurement over a comparable period, the full running cost, the assumptions stated plainly, and an explicit note on which improvements came from redesigning the process rather than automating it. Anything that hides an assumption will be found, and finding it costs you the rest of the report.
When the number comes back disappointing
It is worth having anyway. A modest, believable return on a well-chosen process builds more confidence than an impressive one nobody can reproduce, and it tells you where the next project should not be. The automation index covers which processes tend to repay the build in specific sectors.
Measuring over a comparable period
A four-week measurement after launch compared against a four-week baseline sounds fair and often is not, because the launch period contains the teething problems and the baseline usually does not contain the seasonal spike. Choose comparable windows deliberately, allow a settling period that you exclude from both, and say in the report which weeks were used and why.
Where volume is seasonal, measure the ratio rather than the total. Hours per hundred documents processed is a stable number. Hours per month is not, and a quiet month will make a mediocre system look excellent.
The number that matters after year one
Initial return is about the build paying for itself. Sustained return is about whether the system still works when the surrounding systems change, and that is largely a maintenance question. Track how often the automation needed intervention, and how much of that was routine exception handling against how much was genuine repair caused by something upstream changing.
A system needing frequent repair is not necessarily a bad system. It may be integrated with something unstable, in which case the honest conclusion is about the upstream dependency rather than the automation, and the fix belongs somewhere else entirely.
Want a number your finance team will accept?
We will help you capture the baseline before the build, so the benefit afterwards is arithmetic rather than an argument.