Business Cases
Automation business cases
Build an automation business case around measured work, workable alternatives, operating costs and assumptions a decision maker can inspect.
An automation business case should help someone decide whether to fund a defined change. It needs a measured starting point, workable alternatives, forecast benefits and costs over the appraisal period, and the assumptions that could change the decision. Hours saved are one input, not the decision on their own.
Start with the decision
State the problem as a business result. For example, a team may want complete service requests to reach a correct decision sooner. Name the requests included, the event that starts them, the result that ends them and the person accountable for the outcome. If the proposed automation handles only one step, say so.
Write the approval question plainly: Should we fund this change for these cases, under these conditions, instead of the other workable options? Process selection and mapping may already have been done; the business case uses those findings to justify a choice.
Compare workable options
Include the current approach as a baseline. Compare it with a practical change that does not require the proposed automation, such as removing duplicate entry or clarifying an intake rule. A combined option may also make sense: simplify the route, then automate repeated work that remains.
| Option | What the case needs to establish |
|---|---|
| Continue the current route | Expected workload, costs and performance over the appraisal period |
| Simplify the process | Which steps change, what effort remains and which decisions or records must be preserved |
| Automate a defined segment | Which cases are eligible, what people still do and what it costs to build and operate |
| Simplify, then automate | The incremental benefit of each stage without counting the same work twice |
Use the same case types, volume assumptions, time period and outcome measures for every option. An option that saves more handling time may still be unattractive if it adds substantial support work or makes exceptions harder to resolve.
Workable options to compare in the business case
- Continue the current routeExpected workload, costs and performance over the appraisal period
- Simplify the processWhich steps change, what effort remains and which decisions or records must be preserved
- Automate a defined segmentWhich cases are eligible, what people still do and what it costs to build and operate
- Simplify, then automateThe incremental benefit of each stage without counting the same work twice
Build benefits from observable work
Summarise the measured baseline and relevant outcome measures for the cases in scope, including efficiency and service quality.
For each benefit, show the baseline, assumed change, calculation, owner and point at which it could begin. Use ranges where volume, adoption or exception rates are uncertain. Keep service quality, correction work and effects on receiving teams alongside the efficiency measure.
Treat released staff time carefully. Fewer handling hours can create capacity for other work. Call that a cash saving only when a budget or expenditure will actually fall and the budget owner agrees with the treatment.
Avoided future expenditure may also have value, but identify the cost that would otherwise be needed and show that assumption separately. Do not count the same hours as both a labour saving and extra output without evidence for two distinct effects.
Select measures that fit the benefit
Return on investment (ROI) compares capital investment with projected operational cost savings over time, often to estimate how long it will take to recoup the investment. It can be difficult to use when an option offers benefits that are not easily quantified in simple payback terms, so do not rely on it as the only view of financial viability.
Where value depends on actual use, utilisation can show how the investment's net gain per unit scales with usage. For example, a system saving 4 per cent per unit used 24 hours a day may be more beneficial than one saving 5 per cent per unit used 12 hours a day, assuming equal product rates.
For equipment that produces units, Overall Equipment Efficiency (OEE) measures good units against total units while accounting for rejects and stoppages. Include a measure such as this when the case depends on usable output, and make clear how it complements the financial measures in the comparison.
Measures that match the benefit being claimed
- Return on investment (ROI)Compares capital investment with projected operational cost savings over time; useful for estimating recoupment, but not the only view of financial viability
- UtilisationShows how the investment's net gain per unit scales with actual use, which matters when value depends on how much the system is used
- Overall Equipment Efficiency (OEE)Measures good units against total units while accounting for rejects and stoppages; include it when the case depends on usable output
Cost the life of the option
Show initial work and the running commitment. Initial costs might include design, configuration, integration, testing, training and transition. Running costs may include licences, hosting, monitoring, human review, incident response, fixes, upgrades and changes to connected systems. Include replacement or retirement where it falls within the appraisal period.
State who supplied each estimate and what it covers. An annual software quote does not establish the cost of operating the full process. Keep internal staff effort visible even when it does not require a new purchase.
Compare costs and benefits by period so an upfront spend is not weighed against a single steady-state year of benefit. For a material investment, use the organisation's finance appraisal method.
Initial and running costs over the appraisal period
- Initial costsDesign, configuration, integration, testing, training and transition
- Running costsLicences, hosting, monitoring, human review, incident response, fixes, upgrades and changes to connected systems
- Replacement or retirementInclude where it falls within the appraisal period
- Internal staff effortKeep visible even when it does not require a new purchase
Show what could change the result
Test the assumptions that matter most. Lower eligible volume, slower adoption, more exceptions or higher maintenance effort may change the case. Show a conservative and an optimistic scenario alongside the central estimate, with their assumptions visible. Identify dependencies such as access to a source system, an agreed approval rule or a team able to handle failed cases.
A decision summary should state the proposed scope and outcome, the alternatives, measured baseline, forecast benefits and owners, costs over the appraisal period, material risks and conditions for proceeding, revising or stopping.
Name who will check the agreed outcome and guardrails after launch, and when the case should be updated if its assumptions change.
What the decision summary should state
- Proposed scope and outcome
- Alternatives considered
- Measured baseline
- Forecast benefits and their owners
- Costs over the appraisal period
- Material risks and conditions for proceeding, revising or stopping
- Who checks the agreed outcome and guardrails after launch, and when the case is updated if assumptions change
In this guide
- Estimating savings from measured handling timeMeasure active work, forecast eligible hours released and separate staff capacity from a defensible reduction in spending.
- Comparing automation with process simplificationCompare simpler process routes and automation against the same outcome, costs and constraints without counting benefits twice.
- Including support and maintenance in automation costsEstimate automation costs for monitoring, exceptions, support, planned changes and retirement without counting work twice.
