Automation Business Case Without Inventing ROI: Ranges, Costs and a Review Date
In short
An automation business case that holds up starts from a measured baseline, counts every cost including running, maintenance and exception handling, and states the benefit as a low, expected and high range with the assumption it is most sensitive to. It says whether saved time becomes saved cash or freed capacity, names who carries each risk, and sets a review date when the same measurement is repeated.
Key takeaways
- Include uncertainty. A single ROI figure is an estimate multiplied until it looks like a fact; a low, expected and high range is more honest and easier to defend.
- Time saved is not automatically cash saved. Hours only become money when a cost goes away; otherwise they are capacity, and the case should say so.
- Count every cost, not just the build: access, data cleanup, running, monitoring, maintenance, and the time the exceptions still take.
- Name the assumption the case is most sensitive to, then test that one first, ideally in a short pilot before the full build.
- Set the review date in the case itself, and repeat the baseline measurement then. The difference is the result.
Table of contents
Most automation business cases are built backwards. Someone estimates the hours a task takes, multiplies by an hourly rate and by twelve months, divides by the build cost, and a return of several hundred percent appears on a slide.
Nobody on the finance side can defend that number, because nobody can say where its parts came from. And after launch nobody checks it, because checking would mean measuring something that was never measured in the first place.
An automation business case does not need a dramatic number. It needs one a sceptical reader can trace back to evidence, with the uncertainty left in. Include uncertainty, and the case gets smaller, more credible, and much more likely to be approved by someone who has read a few of these before.
What an automation business case has to answer
A useful business case answers five questions, in this order. What does the work cost today? What will the automation return, and how sure are we? What will it cost to build and to keep running? What could go wrong, and who carries it? And when will we check?
Each answer is a range or a named assumption, not a single figure. The document is short, and every number in it has a source a reader could ask to see.
Start from a measured baseline
The benefit side of the case is only as good as the measurement of today's work. That means frequency from records, hands-on time logged by the people doing the work, and rework, waiting and exceptions counted separately. We set out that method in measuring manual work before automation, and its illustrative example carries on below.
A case built on an estimate given in a meeting is a guess with a spreadsheet around it. If there is no baseline yet, the business case is not ready to be written. The next step is two weeks of measurement.
Time saved is not automatically cash saved
This is the line most business cases blur. Freed hours only turn into money when a cost actually goes away: overtime that stops, temporary staff not renewed, a planned hire not made, or a backlog cleared that was delaying revenue.
If fifteen hours a month are freed across three people, no hire is avoided and no invoice disappears. The time is real, and it is valuable, but it is capacity rather than cash. Say which it is, and if it is capacity, say what it will be used for. A case that claims cash savings from freed minutes is the first thing a finance reviewer will take apart.
Count every cost, not only the build
Build effort is usually the most predictable cost and rarely the largest over time. A complete case counts:
- Access and integration: permissions, approvals and connections to systems another team or supplier controls
- Data cleanup: fields that need to be filled in consistently before a rule can rely on them
- Running costs: licences, hosting and usage charges, where they apply
- Monitoring: someone checking that the automation ran and did the right thing
- Exceptions: the cases the rule does not cover, which still take a person's time, often more per case than before
- Maintenance: fixes when an upstream system, form or supplier changes
Leaving out the last three is how an automation that looked like it paid back in months turns out to cost more to live with than the manual process did.
State the uncertainty as a range
Give the benefit as three figures: low, expected and high. Tie each one to a specific assumption rather than to optimism: what share of cases the rule will cover, how much rework it prevents, how quickly people stop double-checking its output.
Then name the single assumption the case is most sensitive to. It is usually the coverage rate: the share of cases that go straight through. That assumption is the one worth testing before the full build, often with a short pilot on real items. If the pilot comes in below the low case, the case has done its job by stopping a weak project early.
Name the risks and who carries them
List what could make the case wrong and who absorbs it if it happens. The exceptions land on a named team. A supplier changes an interface and the automation breaks until someone fixes it. The data quality turns out worse than the sample. People keep doing the task by hand in parallel because they do not yet trust the output.
For each, write down the owner and what would happen next. A risk with an owner is a plan; a risk without one is a surprise waiting for a date.
An illustrative business case, with ranges
The figures below are illustrative, not from a real engagement. They continue the invoice example from the baseline article: about 32 hours a month of hands-on work, of which roughly 19 are the first pass, 6 are rework and 7 are exceptions. Everything is in hours, so it can be converted with your own rates.
| Monthly hours | Low | Expected | High |
|---|---|---|---|
| First pass the rule covers | 70% | 85% | 95% |
| Hours returned, first pass | 13.2 | 16.1 | 18.0 |
| Rework prevented | 0 | 3.0 | 4.6 |
| Ongoing monitoring and maintenance | 5 | 4 | 3 |
| Net hours returned per month | 8.2 | 15.1 | 19.6 |
| One-off build, access and cleanup | 120 | 95 | 70 |
| Months until the hours break even | about 15 | about 6 | under 4 |
The exceptions, about 7 hours a month, stay with a person in every column.
Read this way, the case is honest about its own spread: somewhere between under four months and well over a year. The deciding assumption is the first row, and a two-week pilot on real invoices can narrow it before anything else is built. It also shows the freed time is capacity, not a saved salary, which is what the approver needs to know.
Set a review date, and measure the same way again
The last line of the case is the date it will be checked, and how. Pick a date a few weeks after the automation has settled, then repeat the baseline measurement exactly as before: same method, a comparable period, the same definitions of rework and exceptions.
Decide in advance what result means keep going, adjust, or switch it off. Without a review date, the case is a forecast nobody revisits. With one, it becomes the first number the project can actually stand behind.
If there is a process you would like to automate and the case for it is currently a single number on a slide, scope the automation opportunity with us: building a defensible case from a measured baseline is how our business process optimization work starts.
Frequently asked questions
Start from a measured baseline of the current work, then state the benefit as a low, expected and high range tied to named assumptions. Count every cost, including access, data cleanup, running, monitoring, maintenance and the exceptions that stay manual. Say whether saved time becomes cash or capacity, name who carries each risk, and set a review date for re-measuring.
Because it is usually an estimate of task time multiplied by a rate and a year, divided by the build cost, with no baseline behind it. It typically ignores running and maintenance costs, the time exceptions still take, and the fact that freed hours only save money when a cost actually goes away. A range with named assumptions is far easier to defend.
No. Freed hours become saved money only when a cost goes away, such as overtime, temporary staff, a planned hire, or a backlog that was delaying revenue. Otherwise the saving is capacity: real and valuable, but not cash. A business case should say which it is, and if it is capacity, what the freed time will be used for.
Beyond the build, include access and integration work, data cleanup, running costs such as licences and hosting, monitoring, the time spent on exceptions the rule does not cover, and maintenance when upstream systems or forms change. The last three are the most often left out and the main reason automations cost more to live with than planned.
Give the benefit as three figures, low, expected and high, each tied to a specific assumption such as the share of cases the rule will cover. Then name the single assumption the case is most sensitive to and test it first, often with a short pilot on real items, before committing to the full build.
Set the review date in the business case itself, a few weeks after the automation has settled. Repeat the original baseline measurement with the same method, period length and definitions, and compare the two. Decide beforehand what result means keep going, adjust or switch it off, so the review leads to a decision rather than a discussion.
Have a Business process optimization project like this in mind?
Tell us what you are trying to build. We will tell you plainly what Business process optimization work like this would take.
Get a quoteContact Us
Lahore, Pakistan · London, U.K · Austin TX, U.S · Toronto, Canada