Key Takeaways
- Start from a measured baseline of today's volumes, effort, errors and costs; without it, benefits are guesses.
- Count the full cost over the solution's life, separating one-off from recurring spend.
- Keep cash savings apart from capacity freed up, and say what the freed time will be used for.
- Show scenarios and key assumptions openly, and test the riskiest ones with a small pilot.
- Agree up front how results will be measured and when the case will be reviewed.
Why AI business cases get sent back
Finance teams are not against AI. They are against proposals that cannot be checked. A case that promises large savings without showing where today's costs sit, what the solution will cost to run or how anyone will know whether it worked is hard to approve, however promising the technology. Many AI proposals stall for exactly these reasons.
A strong case does not need complex modelling. It needs a clear baseline, an honest view of costs, benefits expressed in the terms finance uses and a plan for measuring the result. This is the structure Artifex follows when helping clients with use-case scoring and roadmaps.
Start with the baseline
Every benefit will be measured against how things work today, so begin there. For the process in question, record the volume of work, the time each step takes and who does it, how often errors or rework occur and any direct costs tied to the process. If you have already run a workflow audit, most of this exists. The baseline should cover:
- Volume: how many cases, documents or requests pass through each month.
- Effort: time per case at each step, and the roles involved.
- Quality: how often errors, rework or escalations happen, and what they cost to fix.
- Timing: how long the process takes end to end, and what delays cost.
- Direct costs: external spend, overtime or penalties linked to the process.
Be explicit about where each figure came from, whether system data, a sample of cases or estimates from the people doing the work. Finance will ask. A baseline built from a sample of real cases and checked with the team is far more persuasive than a round number agreed in a meeting.
Count the full cost
Underestimating cost is the quickest way to lose finance's trust later. List everything the solution will need across its life, not just the build, and separate one-off costs from recurring ones, because finance treats them differently.
- Build or purchase.Design, development and testing, or licences and set-up if you are buying a product.
- Integration.Connecting to existing systems, preparing data and completing security reviews.
- Running costs.Model usage, hosting and monitoring, which may rise as volumes grow.
- People and change.Training, staff time during rollout, updated procedures and internal communication.
- Support and improvement.Maintenance, fixes, updates as tools change and the time of a named owner.
Where costs depend on volume, show how they change if usage is higher or lower than expected. It signals that you have thought about the solution in daily operation, not only as a demo. Include the cost of staying as you are, too: if the current process needs extra staff or outsourcing as the business grows, that belongs in the comparison.
Express benefits the way finance does
Benefits usually fall into a few types: time saved, errors avoided, faster turnaround, revenue protected or gained, and risk reduced. Translate each into money where you reasonably can, and describe the rest clearly without forcing a figure onto it.
The most important distinction is between cash savings and capacity freed up. If a team spends less time on a task, the company only saves cash when it spends less, for example by reducing outsourcing or overtime or by not filling a vacancy. Otherwise the time is released for other work. That may be valuable, but finance will want to know what the work is. Blurring the two is one of the most common reasons a case is challenged.
Take a hypothetical example. A customer service team proposes an assistant that drafts replies to routine queries for agents to review. The case might claim shorter handling time per query. Finance will ask whether that means fewer temporary staff during busy periods, which is a cash saving, or agents spending more time on complex complaints, which is capacity. Both can be legitimate, but they should appear on separate lines with separate evidence.
Hours saved are not money saved until someone decides what happens to those hours.
How finance will evaluate it
Expect the case to be judged on familiar grounds. How long until the investment pays back? What return does it offer over a sensible period, set against the risk? Which assumptions drive the result, and what happens if they are wrong? How does it compare with other uses of the same budget?
Answer these directly. Present a cautious, a central and a more optimistic scenario rather than one figure. List the assumptions behind them, such as how many cases the solution can handle without a person stepping in, and show which matter most. Where an assumption is uncertain, propose a small pilot to test it before the full investment is committed. That turns one large, uncertain request into a staged decision, which is much easier to approve. Be clear about what the pilot must show for the next stage to go ahead, so that the go or stop decision is agreed before any results arrive.
Agree how results will be measured
Close the case with a measurement plan: which figures will be tracked, how they will be collected, who reports them and when the case will be reviewed. Commit to comparing results with the baseline at agreed points after launch. This gives finance a way to hold the project to account and gives you evidence for the next investment. It matches the final stage of our process, where proven solutions are refined and rolled out further.
Whether you build the solution with a partner or train your own team, the same discipline applies. A business case finance can check is a business case finance can approve.