Automation business cases are usually built from the saving and lose their credibility on the cost side, because the current effort was estimated rather than measured and the undocumented step was not priced.
This guide covers how to measure what the task costs today, how to tell removed work from work that simply moved, and why writing the review date into the case protects the next one.
Key takeaways
- Measure the hours, do not estimate them: A case built on a guess collapses the first time somebody from finance asks where the number came from.
- Removed is not the same as moved: Work that lands on another desk is a reallocation, and presenting it as cash costs credibility.
- Price the undocumented step: The part nobody has written down is where automation projects overrun, and it belongs in the case.
- Write the review date in: Automation that is never re-measured is why the next business case is harder to approve than this one.
Start with the business outcome
Aim at a decision somebody in finance will sign. Write down what the automation removes and what it costs to keep running, because a case built only on hours saved falls apart the first time the figures are checked.
Have the people doing the task record their time for a week rather than estimating it. Estimates of manual effort are wrong in both directions, and a measured figure is the only part of the case that cannot be argued with later.
Four areas to define before choosing features
1. Current Cost
Measure the hours per month the task takes rather than estimating them, and cost the errors and the delay separately. Estimates of manual effort are wrong in both directions, and a case built on a guess collapses the first time finance asks for the source.
2. Expected Gain
Distinguish what is genuinely removed from what simply lands on somebody else, and decide whether the freed hours become capacity or slack. Hours returned to a team that stays the same size are real, but they are not cash and presenting them as cash costs credibility.
3. Delivery Risk
Name the part of the process nobody has documented and what it will cost if it is more complex than assumed. That undocumented part is where automation projects overrun, and the risk belongs in the case rather than in the first status report.
4. Ownership
Decide who maintains the automation when the rules change and what their time costs per year. An automation with no owner degrades silently as the business moves, and the manual workaround comes back without anyone deciding that it should.
Decide what to measure
Measure adoption together with cycle time, rework, exception volume, customer outcome, and management response. A rising login count does not prove transformation if the old channels and reconciliation work remain necessary.
Manage the most likely risks
| Decision area | Risk to make visible | Practical safeguard |
|---|---|---|
| Current Cost | Current effort is estimated | Measure it for a week with the people who do the work, including the interruptions. |
| Expected Gain | Moved work is counted as saved | Mark what disappears and what lands on somebody else, and only count the first. |
| Delivery Risk | The undocumented step is ignored | Name the part nobody has written down and price what happens if it is harder than assumed. |
| Ownership | Nobody maintains the rules | Decide who updates the automation when the process changes and what their time costs. |
Build a roadmap around evidence
1. Measure the current cost
Have the team record their time for a week and cost the errors and the delay separately.
2. Separate removed from moved
Go through the proposal step by step and mark which column each saving belongs in.
3. Price the unknown part
Identify the undocumented step and add a realistic allowance for it being worse than expected.
4. Fix the review date
Write into the case when the same figures will be measured again and by whom.
For the operating model questions that decide whether a saving is real, see How to Build a Digital Operating Model for Your Business.
Plan adoption and operating ownership
The team whose hours appear in the business case needs to know what happens to those hours. If the honest answer is that the work is reallocated rather than the team reduced, say so early, because the alternative is a project that is quietly undermined by the people best placed to make it work. Decide who re-measures at ninety days and make it the person who signed the original case.
Design the exception model before the happy path is final
Write the five situations most likely to interrupt automation return on investment: missing information, conflicting rules, unavailable dependencies, changed circumstances, and a user who needs human help. Assign each situation an owner, a safe system state, a visible message, a staff action, and a route back to the journey.
Use current cost and expected gain to test where an exception first becomes visible. Use delivery risk to determine what context staff need, and ownership to record whether recovery succeeded. This turns exception handling into product scope instead of post-launch improvisation.
Estimate the first release using both normal and recovery paths. The extra clarity can reduce late redesign and helps the business compare current effort, error, delay, change cost, adoption, and operating ownership without pretending that every user and operational situation follows one ideal sequence.
A 30-day validation plan: Automation ROI
Days 1 to 5: measure the current effort instead of estimating it. Have the people doing the task record their time for one week. Estimates of manual effort are consistently wrong in both directions, and a business case built on a guess falls apart the first time somebody from finance asks where the number came from. Include the interruptions and the chasing, because those are a large part of the real cost and they never appear in a process description.
Days 6 to 15: separate removed work from moved work. Go through the proposed automation step by step and mark what disappears and what simply lands on someone else. Only the first column is a saving. The second is a reallocation, and presenting it as a saving is what makes the ninety-day review uncomfortable. Ask the receiving team whether they agree they can absorb it, since a saving that depends on somebody else having spare capacity is not a saving at all.
Days 16 to 30: write the review date into the business case. Fix the date the same figures will be measured again and name the person who signed the original case as the one who will present them. Automation projects that are never re-measured are why the next business case is harder to get approved than this one. Agree what happens if the figures miss, as a review with no consequence is a diary entry rather than a control.
A practical worksheet: Automation ROI
Automation business cases are usually built from the saving and lose their credibility on the cost side. Complete all four rows, and use the same level of rigour on the ones that work against the project.
| Decision area | What to record |
|---|---|
| Current Cost | Hours per month on the task, measured rather than estimated, plus what the errors and the delay cost separately |
| Expected Gain | What is genuinely removed as opposed to moved, and whether the freed hours turn into capacity or into slack |
| Delivery Risk | The part of the process nobody has documented, and what it will cost if it turns out to be more complex than assumed |
| Ownership | Who maintains the automation when the rules change, and what their time costs per year |
| Measurement | The same figures re-measured ninety days after launch, by the person who signed the original case |
Count a saving only where a cost actually leaves the business. Hours returned to a team that stays the same size are real but they are capacity, not cash, and presenting them as cash is what makes the next business case harder to get approved.
Related guides
- The operational half of this is in Digital Transformation Roadmap: A 7-Step Business Guide.
- If your team is already past the planning stage, read Paperless Workflow: How to Digitize Paper-Based Processes.
If Automation ROI: Formula, Costs, Benefits, and Risk is the start of a roadmap someone has to own, Discuss Your Digital Roadmap.
Ali Boran Gazel