How to write a business case for AI agent projects that actually gets approved

Failed AI agent pitches follow a recognizable pattern: three slides on the technology, a final slide claiming 'expected 30% efficiency gains,' and no calculation to support it. When the CFO asks how you arrived at 30%, there is silence.

The problem in these meetings is rarely the Agent itself. It's that the business case never answers the four questions decision-makers are asking: What specific pain point are you solving? What does this cost now? What will it save after implementation? If this fails, how much do we lose and how quickly will we know?

Answer those four questions clearly, and approval becomes likely. Below is the five-section template structure we actually use, with pass criteria for each.

Section 1: Problem statement

The most common mistake is framing the problem as 'We want to use AI to improve operational efficiency.' No one will argue with that, but no one will approve it either, because it doesn't point to anything measurable.

Here's what works: lock onto a specific process. For example: 'The support team processes 800 tickets daily, with 62% being repetitive order queries and returns. Average handling time is 6 minutes per ticket. Peak response times lag by 40 minutes, which drove an 18% increase in complaints last quarter.'

The difference is clear: every number in the second version is verifiable and automatically defines what the Agent needs to accomplish. If you can't describe a problem in numbers, it's not ready for investment.

Section 2: Baseline

This is what most people skip, and it's the most damaging omission. Lock down 'current cost' before deploying the Agent.

Baseline should cover at least three dimensions: time cost (duration per task, total monthly hours), financial cost (headcount, outsourcing, existing tool licenses), and quality cost (error rates, complaint rates, SLA breach penalties). These numbers should come from system records, not from memory.

One manufacturing client measured processing time for standard orders but missed exception handling, which consumed 35% of labor. After the Agent went live, that was where the biggest savings appeared. Because the baseline didn't capture it, the ROI looked artificially low and nearly got cut in review. Don't measure just the common case.

Section 3: Projected ROI

Decision-makers aren't afraid of imperfect numbers. They're afraid of hidden assumptions. The purpose of the ROI section isn't to arrive at an impressive total; it's to lay out each calculation in a form others can challenge.

Here's what an honest ROI looks like:

With this table, payback is obvious: net benefit of approximately NT$1.56M in year one, break-even in about 14 months, pure savings from year two onward. The rightmost column is essential, every number is tagged with its assumption, so reviewers can challenge each line. You've moved the 'that 55% seems optimistic' debate from the boardroom into the spreadsheet, which actually makes consensus easier to reach.

Better to use conservative assumptions and secure approval than to oversell and have it backfire three months after launch. Over-promised ROI has a way of coming back to haunt you.

Section 4: Risks and mitigations

People who list risks in their proposals are more likely to get funded, because decision-makers know you've thought it through. Typical risk categories include data quality issues causing wrong answers, poor internal adoption (the most common cause of failure), integration problems with existing systems, and compliance risk from hallucinations.

Each risk needs a mitigation and a detection metric. For example: 'Risk: Low adoption. Mitigation: Pilot with one team in month one with a dedicated champion. Detection: Track actual usage weekly; if it drops below 40%, we review.' The purpose of the risk section is turning 'What if this doesn't work?' into a set of measurable numbers you can actually monitor.

Section 5: Milestones

Don't ask for three years of budget all at once. Break the project into stages with clear acceptance criteria and built-in exit points. Decision-makers' psychological resistance drops dramatically.

The standard rhythm is three phases: Phase 1 (4 to 6 weeks) builds a working prototype on a real process, with acceptance criteria of 'accuracy targets met on live data.' Phase 2 (8 to 10 weeks) pilots with a single team, with acceptance criteria of 'usage stays above threshold and baseline metrics begin improving.' Phase 3 is full rollout. Each phase end is a 'continue or stop' decision point, not a one-way commitment.

Once you've filled this in, you have a complete business case: problems in numbers, baseline sourced, ROI with assumptions visible, risks with detection metrics, milestones with exit points. It doesn't guarantee project success, but it ensures you won't lose the budget meeting because you failed to make the case clearly.

When we deploy AI Copilots and Agentic workflows for clients, we often skip writing code in week one and instead help them fill out these five sections. However beautiful the demo is, it doesn't matter if you can't clear the budget gate or if no one actually uses it once it goes live. The business case is the bridge between those two outcomes.