How to calculate automation ROI without fantasy math

Baseline

Measure the workflow before assigning value to a minute

Start with a stable unit of analysis: a case, document, request or completed outcome. Observe a representative period and segment the work. A routine invoice and a disputed invoice may share a queue but have different effort and risk. Record active touch time separately from elapsed waiting. Count handoffs, reopened cases, manual searches and downstream corrections. A process-mining log can help, but it needs validation with operators because system events do not necessarily equal productive work.

Connect operational measures to financial reality. Confirm volumes against source systems, loaded labor cost with finance and error consequences with the team that absorbs them. Document seasonality and planned demand changes. If time is released, ask what the organization will do with it. Removing contractor spend, avoiding a planned hire, increasing paid throughput and giving employees breathing room are all legitimate outcomes, but they have different financial treatment. Label them honestly.

• Use representative samples rather than the easiest available cases.
• Segment routine, complex and exception work.
• Separate active touch time from queue time.
• Validate logs with the people who perform and receive the work.
• Tie every financial input to an owner and source.

Benefits

Value the mechanism, not the feature

“The model drafts a response” is a capability, not a benefit. The benefit mechanism may be fewer source searches, a higher first-pass acceptance rate or more submissions completed before their deadline. Write each chain explicitly: intervention, changed behavior, operational measure and valued outcome. Apply the expected adoption and eligible-case rate. If only sixty percent of cases can use the automation and half the team adopts it, multiplying savings by total volume overstates value.

Keep benefit categories visible. Cashable benefit changes spend or receipts. Capacity benefit frees time for named work. Service benefit changes speed, consistency or experience. Risk benefit reduces the likelihood or impact of loss. Strategic benefit creates an option such as entering a market. Monetize only where the method is defensible and avoid double counting. A corrected defect may reduce rework and risk; the same event should not be counted twice without explaining distinct effects.

Business case

Include the cost of making the automation dependable

One-time cost includes discovery, process redesign, data preparation, engineering, integration, testing, security and privacy assessment, migration, training and rollout. Recurring cost includes software, models, infrastructure, storage, observability, human review, exception handling, content maintenance, support and governance. Add upgrades, supplier change and retirement. Allocate shared platforms proportionately, but do not hide costs simply because another team already owns the budget.

Forecasts need ranges. HM Treasury’s Green Book describes optimism bias as the tendency to understate cost and duration and overstate benefit, and advises using evidence from similar work. For an enterprise case, compare historical estimates with actual delivery where possible. Show low, expected and high scenarios and the break-even adoption, automation rate, volume and unit cost. Sensitivity analysis is more useful than false decimal precision because it reveals what must be tested first.

• Separate sunk cost from future incremental choices.
• Include human review and exceptions as operating cost.
• Model implementation delay and benefit ramp.
• Use ranges for uncertain variables.
• Show which single assumption most changes the decision.

Evaluation

ROI is realized in operations, not approved in a slide deck

Write the measurement plan before implementation. Define source systems, baseline window, comparison method, quality sampling, owner and review cadence. A pilot should use representative cases and include the costs needed to produce its quality. If experts secretly repair every output, their work belongs in the result. Compare end-to-end cycle and downstream outcomes, not only the automated step. NIST’s AI Risk Management Framework likewise emphasizes measurement before deployment and continued monitoring, feedback, override and change management.

After launch, maintain a benefit register that pairs each forecast with an actual metric and owner. Review adoption and exceptions early because they explain why expected value is not appearing. Update the forecast without erasing the original. Scale when quality and realized unit economics hold under volume. Redesign when the bottleneck moves. Stop when break-even assumptions cannot be reached. A disciplined stop protects capital and provides better evidence for the next automation.

• Pre-register pilot success and stop thresholds.
• Measure the human effort hidden around the automation.
• Compare end-to-end business outcomes.
• Keep forecast and actual values side by side.
• Give benefit owners authority to stop or redesign.