The AI business case: How to build one that gets approved

I have sat across the table from a lot of CFOs presenting business cases for AI programmes. I have seen cases get approved, shelved, sent back for revision, and, on a handful of occasions, killed at the last moment despite months of preparation. The pattern that distinguishes the cases that succeed from the ones that fail is not the quality of the financial modelling, it is whether the case speaks the CFO's language. 

That sounds obvious. In practice, most business cases for AI are written by people who understand the technology and unconsciously frame the case in terms that technology people find compelling. They lead with the capability, not the problem. They model savings in FTEs, not risk in regulatory penalties. They present a technology roadmap, not an operational investment thesis. 

The CFO is not reading any of that the way the author intended. Here is how to write a business case that they will. 

Start with the problem the board already owns 

The most powerful opening for an AI business case is not 'we have an opportunity to deploy an AI agent.' It is 'we have a problem that is costing us X, and here is the evidence.' 

The problem should be one that is already visible at board level such as a recurring audit finding, a persistent backlog, a compliance risk that has been flagged in the risk register, or a capacity constraint that is limiting growth. When the business case starts with a problem the board recognises, you are not introducing a new conversation, you are proposing a solution to an existing one. That is an entirely different dynamic. 

The implication is that the best business case preparation starts months before the business case is written. It starts with understanding what operational risks and constraints the board is already focused on and designing the automation programme to address them directly. 

The cost of inaction is the most underused number 

Most business cases calculate the return on the investment while very few calculate the cost of not making it. 

For complex, rule-bound, high-volume processes (the kind that AI automation addresses most effectively) the cost of the current manual approach is often significantly larger than it appears in the cost base. It includes direct processing costs, yes, but it also includes error remediation costs, compliance penalty exposure, the cost of delayed decisions, the operational risk of single-point-of-failure staffing, and the opportunity cost of capacity that is consumed by repetitive work instead of value-adding activity. 

When you quantify the cost of inaction properly, two things happen. First, the investment looks proportionate rather than large. Second, the urgency of the investment becomes evident in a way that a pure ROI calculation rarely conveys. A business case that shows the board what continuing as-is will cost them over the next three years is a much more compelling document than one that shows what the automation will save. 

Three value lines, not one 

The single biggest limitation of most AI business cases is that they model only the efficiency gain which is the cost and time reduction from replacing manual processing. This is the least interesting part of the value story, and it is often the most contested, because it is the part that depends most heavily on assumptions about headcount, utilisation, and process volumes. 

A more robust case models three value lines. Efficiency: the direct reduction in processing cost and time. Quality: the reduction in error rate, rework, compliance incidents, and audit findings, each of which has a quantifiable cost that is typically larger than the efficiency gain. Resilience: the reduction in operational risk from volume spikes, staff absence, and system changes. This is quantified, as described above, through the cost-of-failure framework. 

A programme that delivers across all three lines is a materially different investment case from one that delivers only on efficiency. It is harder to challenge, because any single line can absorb scrutiny while the others continue to stand. And it is more accurate, because it reflects the actual value that mature automation programmes deliver. 

Anchoring the case in comparable outcomes 

Abstract ROI projections are easy to challenge. Concrete outcomes from comparable live deployments are much harder to dismiss. 

The instinct in most organisations is to build a bespoke financial model, with assumptions specific to their own process volumes, cost rates, and error frequencies. This model is then presented as the basis for the investment decision. The problem is that every assumption in the model is a potential point of attack. CFOs who have seen optimistic projections before will find them. 

The more effective approach is to anchor the case in real outcomes from comparable programmes, not benchmarks from industry reports. Those are easily dismissed as not applicable to this organisation, this process, and this market. Real outcomes from real deployments, with the specifics of the programme described clearly enough that the board can assess the comparability themselves. 

This is a more demanding standard of evidence, and it requires working with a partner who can provide it. But it is the standard that gets business cases approved in organisations where the CFO has seen too many optimistic projections and too few delivered results. 

Frame it as a programme, not a project 

The final element that distinguishes the business cases that get funded from the ones that get shelved is how the ask is framed. A one-off AI project is a technology experiment. A phased programme is an operational investment. 

The framing difference matters because it changes what the CFO is being asked to approve. A project has a defined scope, a budget, and an end date, after which the organisation either has something, or it doesn't. A programme has a first phase, defined milestones, a governance structure, a managed service model, and a clear path to expansion as value is demonstrated. It is an investment in a capability, not a purchase of a deliverable. 

Boards understand investment in capabilities. They have been making those investments in people, processes, and infrastructure for decades. The language of programme investment is familiar. The language of AI project funding is not. 

The business case that gets approved is the one that speaks in terms the board already uses to think about operational investment: risk, return, phasing, governance, and evidence of comparable value delivered elsewhere. The technology is there to make the case, not to lead it.