Six months after a successful automation build, someone in finance asks what it delivered. If the only available answer is "the team says it's much better", the next project doesn't get funded. The evidence has to be designed in before launch, because a baseline you didn't capture cannot be recovered.
Capture the baseline in the two weeks before go-live
Four numbers, measured not estimated:
- Volume. Instances per week.
- Handling time. Median and 90th percentile minutes per instance. The p90 matters, it's where the pain lives.
- Cycle time. Request to completion, including waiting.
- Error and rework rate. How often it's redone, and the cost of the redo.
Two weeks of observation beats a year of assumption. Nobody guesses their own handling time accurately, the estimate is reliably half the reality.
Count all four kinds of return
Labour hours are the obvious one and usually the smallest:
- Labour. Hours × loaded cost. Be honest that hours freed rarely become headcount cut, they become capacity, which is a real but different argument.
- Speed. Faster response means higher conversion. If lead response drops from six hours to four minutes, ask sales what that's worth. They'll know.
- Error avoidance. Rework cost, plus the occasional expensive mistake that no longer happens.
- Capacity. Volume you can now handle without hiring. For a growing business this is frequently the largest term and the one nobody puts in the deck.
Subtract the real costs, including the boring ones
Build cost, model and infrastructure spend per month, integration licences, and, the one that gets forgotten, maintenance. APIs change, edge cases surface, prompts need tuning. Budget 10–20% of build cost annually. An ROI model without a maintenance line is a model nobody in finance will believe.
A conservative case that survives scrutiny funds more work than an optimistic one that collapses under the first question.
Instrument the system, not the spreadsheet
Every run should log: timestamp, outcome, duration, items processed, human interventions, cost. That table is the business case, generated continuously. Put a small dashboard on it and the question "did it work" becomes a link rather than a project.
Report honestly, including what didn't work
Show hours returned, cycle time before and after, error rate, cost per run, and the exceptions still needing humans. Include the categories the agent handles badly. A report that admits 12% of cases still route to a person is far more credible than one claiming full automation, and it makes the next scope obvious.
The pattern worth knowing
Automations rarely pay back on labour alone in month one. They pay back on speed and capacity, over a quarter. Set that expectation before you start, measure those two things properly, and the second project sells itself.
Put this to work
Want this built, not just read?
Tell us the workflow that's eating your week. Thirty minutes, no deck.