Return on Automation (ROA)

What is Return on Automation?

Return on Automation, or ROA, measures what an automation returns against what it costs across its whole life. It answers a plain question: was this bot or flow worth building and worth keeping?

ROA is not a standardised ratio. Different teams use different formulas, periods, and assumptions, so a percentage means little without that context. State the formula, the baseline, and the time window every time.

A workable version follows the shape of ROI: net realised benefit divided by total automation cost.

ROA = (realised benefits - total lifecycle cost) / total lifecycle cost

Total lifecycle cost

Count discovery, process analysis, design, build, testing, and deployment. Then add the parts that are easy to forget: platform licences, machines or capacity, model usage, and any external services.

After go-live come monitoring, support, handling exceptions, credential management, upgrades, and changes forced by source systems. Retirement and data migration can matter too. Counting build hours alone makes a fragile automation look cheaper than it is.

Counting the benefits

Direct benefits are less manual work, lower external spend, or avoided error correction. Freed-up capacity only turns into money when the time is genuinely redeployed or a cost is actually avoided, not when a report says hours were saved.

Other benefits are faster processing, better compliance, less leakage, and higher service quality. Put a number on these only when you have a defensible method, and keep the non-financial outcomes visible on their own. A required control can be worth having without adding revenue.

A worked example

An invoice automation costs 60,000 euro in year one for analysis, build, licences, and support. It demonstrably avoids 45,000 euro of manual processing and 15,000 euro of error and missed-discount losses.

Realised benefits are 60,000 euro. By the formula above, the net ROA in year one is 0 per cent: the benefits cover the cost, no more.

If year two brings 20,000 euro of run and change cost against 65,000 euro of benefit, the cumulative figure has to include both years. Mention discounting when the period is long or the amounts are large.

Baseline and causality

Measure volume, time, errors, and cost before the change, then use the same definitions afterwards. Correct for volume, season, and price changes, because not every drop after automation was caused by the automation. A pilot or a phased rollout often gives stronger evidence than a plain before-and-after.

Adoption and realised value

A business case estimates expected benefit. ROA should be updated after go-live with real volumes and real exceptions. When staff work around the flow or correct many items by hand, the theoretical time saving never lands. Track the straight-through rate and the exception time, because automatable minutes are not the same as saved minutes.

ROA versus ROI and payback

ROI is the general ratio of net return to investment. ROA applies the same thinking to automation but has no universal formula. Payback period asks how long until cumulative benefits cover the cost, which is easy to grasp but ignores everything that happens after that point. Total cost of ownership looks only at cost over the life of the automation and carries no benefit ratio at all. Use several measures when they answer different questions.

Using ROA across a portfolio

Compare opportunities with the same cost and benefit rules, and factor in process stability and the teams available to maintain each one. As process automation and hyperautomation programmes grow, ROA is what keeps a portfolio honest, alongside operational KPI figures like throughput and error rate. Stop or redesign automations whose realised value keeps falling short. A sunk cost is no reason to maintain weak work forever, and the goal is a better investment decision, not the highest percentage you can present after the fact.