The return on an automation is measured by comparing the process after deployment with its baseline: the measurement of the same process before anything changed. Without a baseline, any savings figure is an estimate. With one, the return is a number your finance director can review and audit.
What a process baseline is
A baseline is a snapshot of the process before any change, taken with real data over a representative period. It covers how long each case takes, how many cases there are, how many errors occur, who is involved and how long the customer waits.
It is taken at the start of the project, before anything changes. And it is kept exactly as recorded, because everything else will be measured against it.
Why an estimate is not enough
Estimates tend to exaggerate the problem before a project and forget it afterwards. When nobody remembers how long things used to take, any improvement looks tiny or huge depending on who tells the story.
A baseline ends that debate. It turns “we think we will save a lot” into “the process went from six minutes per case to one”.
Which metrics to track
Four metrics are enough to start. You can add more, but these should always be there:
| Metric | What it measures | How to obtain it |
|---|---|---|
| Time per case | Minutes of human work per case | Sampling or system logs |
| Touchless rate | Share of cases the system resolves on its own | Logs from the automated system |
| Errors | Corrections, returns or incidents | Ticketing system or sampling |
| Cycle time | Time from a case arriving to its closure | Entry and closure timestamps |
Everything else derives from these four: hours released, cost per case or extra capacity without growing the team.
How to calculate the return
The calculation has three steps:
- Annual saving = (cost per case before − cost per case after) × cases per year.
- Net annual benefit = annual saving − the system’s annual cost, including maintenance.
- Return on investment = (net annual benefit − initial investment) ÷ initial investment.
The payback period, which boards usually care about most, is the initial investment divided by the monthly net benefit.
A worked example
Example with round, illustrative figures:
- A team processes 24,000 supplier invoices a year.
- Before automation, each invoice takes 6 minutes of work: 2,400 hours a year.
- Afterwards, 80% are recorded without intervention and the remaining 20% need a 2-minute review: 160 hours a year.
- Hours released: 2,240. At a cost of €30 per hour, the annual saving is €67,200.
- The system costs €40,000 up front and €8,000 a year to maintain.
On those figures, the net annual benefit is €59,200. The investment pays back in just over 8 months and the first-year return is 48%. From the second year on, the net benefit holds as long as volume does not fall.
Note that every figure in the example comes from a measurement, not an assumption. That is the difference between a business case and a promise.
Notice too what happens if volume changes. With half the invoices, the annual saving halves, but maintenance does not. That is why real, measured volume is the figure that weighs most in the calculation.
Benefits the formula leaves out
Some benefits are real but hard to express in euros. Record them even if they stay outside the calculation:
- Avoided errors. A duplicate payment or a penalty that never happens.
- Shorter lead times. Closing the month earlier or replying to customers in minutes.
- Less reliance on key people. The process keeps running when someone is on holiday.
- Traceability. Every case leaves an auditable record of what was done and why.
- Capacity to grow. More volume without expanding the team at the same rate.
In many projects these benefits end up outweighing the hours released.
Common measurement mistakes
- Measuring only afterwards. Without a “before” figure there is nothing to compare.
- Counting released hours as direct savings. They only are if those hours go to other valuable work.
- Forgetting maintenance costs. A system nobody maintains degrades, and its upkeep belongs in the calculation.
- Measuring an atypical period. A month without a quarter-end close does not represent the process.
- Changing a metric’s definition mid-project. Metrics are fixed at the start and left alone.
Who should validate the figures
Return figures lose credibility if they are calculated only by whoever built the system. The baseline and later measurements are best validated by someone in the business, ideally from finance or management control.
To make that easy, each metric needs a written definition, a specific data source and an owner. Anyone can then repeat the calculation and reach the same result. That is the standard we hold our own projects to: measured against your starting point and verifiable by the client.
How to present the return to the board
A CEO or CFO needs few figures, well explained. A good presentation fits on one page:
- The starting point, with its four metrics and the period measured.
- The current position, with the same metrics and the same method.
- The calculation, with the investment, the annual cost and the payback period.
- The non-financial benefits, one sentence each.
- The next step, with the next candidate process and its expected return.
When every figure has a source, the conversation stops being about whether automation works and becomes about what to automate next.
How often to measure
Measure after every delivery to confirm the system does what was promised before moving on. Then, in operation, measure monthly against the same baseline. That way any degradation is caught early and improvements are prioritised on evidence.
This follow-up is part of continuous evolution, the last step of our method: we compare the after with the before and share it with you.
Where to start
Pick a candidate process and record its four metrics over a representative period. If you are unsure where to begin, our article on which processes to automate first will help you choose. And if you would rather measure it with us, request a first conversation: in our process consulting work, defining the indicators and measuring the starting point is the first thing we do.