Most AI investment decisions get made on enthusiasm and shelved on ambiguity. The pitch is exciting, the demo looks polished, and someone approves a budget. Six months later, nobody can answer whether it worked, and the next AI proposal faces a much harder room.
The problem is almost never the technology. It's that the case for funding was built on possibility rather than specificity, and when the project hit the inevitable friction of implementation, there was no framework for evaluating whether to push through or stop.
A good business case for AI investment is not a technology pitch. It is a structured argument that a specific problem is worth solving, that an AI solution can solve it, and that the expected return justifies the cost. This post covers how to build one.
Start with a problem, not a technology
The most common mistake in AI business cases is leading with the technology instead of the problem. "We should implement AI to improve our customer service" is a technology pitch. "Our support team spends 60% of ticket time answering the same fifteen questions, and AI can reduce that to under 20%" is a business case.
The distinction matters because decision-makers — finance teams, executive leadership, boards — evaluate investment opportunities by comparing them against alternatives for that budget. A proposal to "do AI" competes poorly against specific proposals with clear outcomes. A proposal to reduce support ticket resolution time by 40% with a defined implementation cost competes on the same terms as any other operational investment.
Before you write anything, answer this question in one sentence: what specific problem are we solving, and what does the current situation cost us?
Quantify the cost of the status quo
You cannot build a credible case for change without documenting what the current situation is costing you.
This is the step most business cases skip. They move straight to the projected benefit of the AI without establishing a baseline, which means decision-makers have nothing to compare against.
Quantify the current state across at least two of these dimensions:
Time. How many hours per week does your team spend on this problem? Multiply by headcount and fully-loaded cost. Be honest about whether that time would be productively redeployed or simply absorbed into adjacent tasks.
Errors and rework. How often does something go wrong in the current process, and what does a single error cost — in time to fix, customer impact, or downstream financial consequence?
Capacity constraints. Is the current process a bottleneck that limits throughput? If so, what is the commercial value of that constraint — revenue you're not capturing, customers you're not serving, deals you're losing because the process is too slow?
Speed to outcome. How long does the current process take from trigger to result? What does that delay cost in customer satisfaction, competitive position, or decision quality?
You don't need to be precise. An order-of-magnitude estimate is enough to anchor the conversation. If your current approach costs roughly $80,000 per year in staff time and errors, you have a meaningful number for evaluating the cost of an AI solution.
Build a conservative case for the benefit
Overestimating the benefit is the most reliable way to destroy credibility when the project delivers less than promised.
Use a conservative estimate — not the best case, not the vendor's case, not the demo result. Base your projection on realistic assumptions about how much of the problem the AI will actually solve, accounting for edge cases, human review requirements, and the adjustment period while your team adapts to new workflows.
If AI can reduce the time spent on a process by 40% (rather than the 80% shown in the demo), calculate on 40%. If AI will handle 60% of cases autonomously and escalate the rest to a human, account for the continued human cost on that 40%.
This produces a less exciting number. It also produces a number you can defend, and a number that — if exceeded in practice — makes you look credible rather than lucky.
For a structured view of what AI projects can realistically return, how to measure AI ROI covers the main categories of value — time savings, error reduction, throughput, and decision quality — in detail.
Account for the full cost of implementation
AI implementations have costs that proposals routinely understate.
One-time costs: scoping and design, development or configuration, integration with existing systems, data preparation and cleaning, testing, staff training, and any change management required. If you're working with a consultant or development partner, this is the quoted engagement cost — but internal staff time during implementation is also real and worth including.
Ongoing costs: artificial intelligence systems carry running costs that traditional software often doesn't. API fees scale with usage. Human review of AI outputs takes time. Models require periodic re-evaluation as your data or process changes. Infrastructure maintenance, updates, and the occasional reconfiguration add up even when the system is working correctly.
A complete cost picture includes both, projected over a twelve-month horizon. This gives you a true denominator for your return on investment calculation, rather than comparing the benefit against only the initial build cost.
Be explicit about what you don't know
A business case that pretends to more certainty than it has will be torn apart in the room.
There are things you genuinely cannot know before implementation: how well the AI will handle your specific data, how quickly your team will adapt to changed workflows, whether your data quality is sufficient for the accuracy level you need.
Name these unknowns explicitly and describe how the pilot is designed to answer them. This does not weaken the case — it strengthens it. It signals that you understand the difference between a proof-of-concept and a production system, and that you've thought through the risk before asking for budget.
If you're not sure whether your underlying data is in a state to support what you're proposing, is your data ready for AI is worth reading before you write the business case. Data gaps discovered after approval are harder to explain than data gaps flagged upfront.
Propose a pilot before full commitment
A request for a small, time-boxed pilot is almost always easier to approve than a full budget commitment.
A well-structured AI pilot typically runs four to eight weeks, focuses on a single part of the problem, and produces real usage data against the baseline you've established. The pilot result — not the projected result — becomes the core of any request for full investment.
This approach de-risks the decision for approvers and de-risks the implementation for you. If the pilot doesn't deliver, you've spent a fraction of the full budget to find that out, which is a better outcome than discovering it after full deployment. If it works, you have evidence rather than projection, and the approval conversation for phase two is substantially easier.
How to run an AI pilot project covers how to structure the pilot so you get reliable signal rather than a favourable-looking result that doesn't survive contact with full-scale deployment.
What the business case document should include
If you need to produce a written document for executive or board review, keep it to one or two pages and structure it as follows:
- The specific problem and why it matters now
- The current cost, quantified as described above
- The proposed solution in plain language — not technical detail
- The expected outcome, with conservative estimates and stated confidence level
- Full implementation and ongoing cost over twelve months
- Pilot proposal with timeline and success criteria
- Named unknowns and how the pilot addresses them
That structure gives a reader everything they need to make a decision without requiring them to decode a technology pitch. Decision-makers who are being asked to approve AI spending have usually seen several poor business cases already; a document that is specific and honest about uncertainty tends to stand out.
What happens after the pilot
The pilot either works or it doesn't. If it works, the business case for full investment is largely built — the data is there, and you're presenting results rather than projections. If it doesn't work at the level projected, you have a decision to make: adjust the scope, revisit the approach, or stop.
The worst outcome is neither success nor failure — it's ambiguity, where nobody can say whether the pilot delivered or not because the baseline was vague and the success criteria were never agreed. That is why the measurement framework matters as much as the technology. A clearly failed pilot costs you a small budget and produces useful learning. An ambiguous one tends to drift into ongoing spending with no clear owner and no clear outcome.
If you're working through this and want a second opinion on whether the numbers hold up or the framing is right, that's something I cover as part of AI consulting engagements. Most business cases benefit from a short conversation with someone who has seen a range of similar projects — it often changes both the framing and the projected numbers in ways that make the document significantly more credible. Get in touch if that would be useful.