Automation proposals often rely on broad claims: this will save time, reduce errors and improve the customer experience. All of that may be true, but claims like these are hard to evaluate and easy to dismiss. A finance director asked to approve a budget wants to know how much time, which errors, and what the improvement is worth relative to the cost.
A good business case answers those questions with numbers grounded in how the process runs today. It does not need to be precise to the minute, but it does need to be traceable: anyone reading it should be able to see where each figure came from and challenge the assumptions. This framework sets out a structure for building that kind of case.
Establish the baseline
Everything in the business case depends on an honest picture of the current state. Without a baseline, there is nothing to compare the future state against, and no way to verify the benefits after the project is complete. The baseline should cover four dimensions.
- Volume: how many times the process runs in a typical week or month, and how that varies seasonally.
- Effort: how much hands-on time each instance takes, across everyone involved.
- Cycle time: how long the process takes from start to finish, including waiting.
- Quality: how often something goes wrong, and what it takes to correct it.
Volume is usually available from systems. Effort is harder, because systems rarely record hands-on time. The most practical method is to ask the people doing the work to time a sample of cases over a week or two, or to observe a few cases directly. Self-reported estimates without any measurement tend to be either too low, because people forget the small steps, or too high, because the frustrating cases are the most memorable.
Cycle time can often be derived from timestamps: when a request was received and when it was completed. Quality is measured by counting rework, such as invoices returned for correction, tickets reopened or payroll adjustments made after the run. Where exact figures are not available, a documented sample is far better than a guess.
Translate the baseline into value
With a baseline in place, you can estimate the value of improvement. The most direct component is time saved. As an illustration, if a team processes 600 expense claims a month and each takes twelve minutes to review, that is 120 hours a month. If automation handles the checks for straightforward claims and reduces average review time to four minutes, the saving is around 80 hours a month.
Be careful about how that time is described. Saved hours rarely translate into reduced headcount, and presenting them that way can create resistance and set expectations that will not be met. More often, the time is redirected: the team handles growing volume without adding staff, finishes the month-end close sooner, or spends more time on analysis and exceptions. Say plainly which of these is expected.
Other components of value are often more significant than time. Shorter cycle times might mean suppliers are paid on schedule and early-payment terms can be used. Fewer errors might mean fewer customer credits, fewer compliance issues or less time spent on audits. Faster onboarding means new employees are productive sooner. Where these can be estimated, include them. Where they cannot, describe them qualitatively rather than inventing figures.
A business case earns trust when every number in it can be traced back to something someone measured.
Account for the full cost
The cost side is frequently underestimated. Software licenses and implementation fees are the obvious items, but a complete view also includes the time of internal staff during design and testing, the effort to clean data before automation can rely on it, training and change management, and ongoing maintenance.
Maintenance deserves particular attention. Automated processes need someone to monitor them, handle exceptions, update rules when policies change and fix integrations when connected systems are upgraded. If no one is assigned to this, the automation will degrade and people will quietly return to manual workarounds. Include a realistic estimate of ongoing ownership in the case.
Present ranges and assumptions
Single-point estimates suggest a precision that rarely exists. A more honest presentation gives a conservative, expected and optimistic scenario, with the key assumptions behind each. For example, the conservative scenario might assume automation handles 50 percent of cases without intervention, the expected scenario 70 percent, and the optimistic scenario 85 percent.
Listing assumptions explicitly has a practical benefit: it shows decision-makers exactly what would need to be true for the benefits to materialize, and it makes the case easier to revisit after implementation. If the actual automation rate turns out lower than expected, you can see which assumption was wrong and adjust.
- State the baseline figures and how they were measured.
- Show the expected change for each metric under each scenario.
- List the assumptions, especially automation rates and adoption.
- Include one-off and ongoing costs separately.
- Describe benefits that cannot be quantified without assigning them a number.
Plan how benefits will be verified
A business case should not end at approval. Decide in advance how you will measure the result: which metrics, from which systems, at what intervals. Ideally, the same measurements used for the baseline are repeated three and six months after go-live. This turns the case from a one-time argument into a record of what the organization actually gained, and it builds credibility for the next proposal.
Where to start
Pick the process you are considering and gather two weeks of baseline data on volume, effort, cycle time and errors. Use a sample if full data is not available, and note how it was collected. Estimate the change automation could realistically deliver under three scenarios, and list the costs honestly, including ownership after launch. Keep the document short enough that a busy reader can follow the logic in a few minutes. A modest, well-supported case is far more persuasive than an ambitious one that cannot be checked.