← all field notes
№ 03 scope May 15, 2024 · 9 min read

The AI business case your CFO will actually approve

Most AI business cases fail because they promise transformation. The ones that get funded promise cost savings on a specific workflow with a measurable baseline.


Most AI business cases die in the CFO’s inbox. Not because the CFO doesn’t believe in AI. Because the business case reads like a technology pitch instead of a financial argument.

We see this constantly. A team spends weeks building a prototype, gets excited, writes up a proposal titled something like “AI-Powered Document Processing Platform.” The deck has architecture diagrams, model comparisons, a slide about “the future of work.” It lands on the CFO’s desk and gets the same response every time: “What does this save us, and how do you know?”

The team doesn’t have a good answer. The project stalls.

This is fixable. But the fix starts before you write the business case — it starts with picking the right problem.

The mistake everyone makes

The most common opener in an AI business case is some version of “AI will transform our operations.” This is the wrong frame. Not because it’s untrue — it might be true eventually — but because it’s unfundable. “Transform” is not a line item. You can’t model it. You can’t measure it. You can’t hold anyone accountable for it.

CFOs fund things that reduce cost, increase revenue, or reduce risk — on a specific process, with a measurable baseline, on a known timeline. That’s it. Everything else is a research project, and research projects get cut in the next budget cycle.

The teams that get AI projects funded don’t talk about transformation. They talk about a process that costs $X today and will cost $Y after the project ships. The gap between X and Y is the business case. Everything else is decoration.

Pick the right first use case

Not every process is a good candidate for your first AI project. The best first use case has four properties.

High volume. You want a process that happens hundreds or thousands of times a month. High volume means the savings multiply. It also means you have data — you can measure the current state, and you have enough examples to train or test the system. A process that happens three times a quarter is a terrible first AI use case, no matter how painful it is.

Measurable. You need to be able to measure the current cost — in time, in labor, in error rate, in dollars. If you can’t measure it today, you can’t prove you improved it tomorrow. This sounds obvious. It eliminates about half the use cases teams pitch.

Low risk. Your first AI project is a proof point. If it fails, it should fail quietly. Don’t pick the use case where a wrong answer triggers a regulatory violation or loses a customer. Pick the one where a wrong answer means a human reviews it and fixes it. You want the stakes to be low enough that you can ship something imperfect and iterate.

Boring. The best first AI use case is boring. It’s data entry. It’s document classification. It’s extracting fields from invoices. It’s routing support tickets. These are not impressive demos. They are impressive P&L impacts. The boring use case is the one the CFO funds because the math is obvious and the downside is manageable.

If your first proposed AI project is a customer-facing chatbot — stop. Chatbots are high-risk, hard to measure, and the failure mode is public embarrassment. Save that for project three.

Establish the baseline before you build

This is the step most teams skip, and it’s the step that kills the business case.

Before you write a line of code, measure the current process. How long does it take? How many people touch it? What’s the error rate? What does it cost per unit? You need these numbers, and you need them to be defensible — not estimates from a brainstorming session, but actual measurements from actual work.

Here’s a simple approach. Pick one week. Track the process in detail. Count the inputs, count the outputs, measure the time, log the errors. Do the math. “This process handles 2,400 invoices per month. Each invoice takes an average of 8 minutes of human review. That’s 320 hours per month. At a fully loaded cost of $45/hour, that’s $14,400 per month — $172,800 per year.”

Now you have a number. The CFO understands numbers. The question becomes: “Can we reduce 320 hours to 80 hours?” That’s a question worth answering.

Without the baseline, your business case is “AI will make this faster.” With the baseline, your business case is “We spend $172,800 per year on this process and we can reduce it to $43,200 with 80% automation at a measured accuracy of 94%.” One of those gets funded.

Frame the pilot as a bet with a known downside

CFOs are not allergic to risk. They are allergic to unbounded risk. “We need $2M to build an AI platform” is unbounded. “We need $40K over 8 weeks to test whether we can automate invoice classification — if it doesn’t work, we stop” is a bet with a known downside.

Frame your pilot this way:

The investment. A specific dollar amount — engineering time, API costs, maybe a contractor. Keep it small. The goal is not to build the production system. The goal is to prove the hypothesis.

The hypothesis. One sentence. “We believe we can classify 80% of incoming invoices correctly with no human review.” Not “AI will transform our accounts payable.” A testable claim.

The timeline. 6 to 10 weeks. Long enough to build something real. Short enough that the CFO doesn’t worry about scope creep. If you can’t show results in 10 weeks, you picked the wrong use case.

The kill criteria. This is the part most teams leave out, and it’s the part the CFO cares about most. What would cause you to stop? “If accuracy is below 75% after 6 weeks of iteration, we stop and reallocate the team.” This shows you’re being honest, not selling.

The graduation path. If the pilot works, what happens next? Not a vague “we’ll scale it” — a specific plan. “If accuracy exceeds 85%, we’ll spend $120K over the next quarter to build the production integration with our ERP system. Expected annual savings: $129,600. Payback period: 11 months.”

That’s a business case. Cost, hypothesis, timeline, downside, upside. The CFO can model it, question it, and approve it — all in the same meeting.

What the CFO actually needs to see

The CFO does not need a slide about large language models. They do not need a competitive landscape of AI vendors. They do not need a paragraph about how GPT-4 works.

They need four things.

A P&L impact on a specific line item. “Accounts payable processing costs $172,800/year. This project reduces it to $43,200/year. Net savings: $129,600/year.” Not “AI will create efficiencies across the organization.” A line item.

A credible cost estimate. “The pilot costs $40K. The production build costs $120K. Ongoing costs are $1,200/month in API fees and $8K/month in partial FTE for monitoring.” If you can’t estimate the ongoing cost, you haven’t thought about it enough.

A risk assessment they can believe. Don’t say “no risk.” Say “the downside is $40K and 8 weeks of one engineer’s time. We’ve defined kill criteria. If the accuracy isn’t there, we stop.” Honesty about risk builds more trust than optimism about outcomes.

A timeline with milestones. “Week 4: baseline model tested against 200 historical invoices. Week 8: pilot running on live invoices with human review. Week 10: go/no-go decision.” Not “Q3: AI implementation.” Milestones.

The meta-lesson

The business case is not about AI. It’s about the process. The CFO doesn’t care whether you use a language model, a rules engine, or an army of trained pigeons. They care about the cost of the process today, the cost of the process after, and whether you’ve thought carefully about the path from here to there.

If your business case works just as well with the word “AI” removed, you’ve written a good business case. If removing “AI” makes it fall apart — if the entire argument rests on the novelty of the technology rather than the economics of the process — you don’t have a business case. You have a technology pitch. And technology pitches don’t survive the CFO’s inbox.

The teams that get AI projects funded are not the ones with the best demos. They’re the ones who did the homework — measured the baseline, sized the bet, defined the downside, and showed the math. The math is what gets approved. Everything else is a slide deck.

tl;dr

The pattern. Teams pitch AI projects with transformation narratives instead of financial arguments, and CFOs kill them for lacking measurable impact. The fix. Pick a high-volume, measurable, low-risk process, establish its cost baseline, and frame the pilot as a small bet with defined kill criteria and a specific P&L impact. The outcome. The project gets funded because the math is obvious, the downside is bounded, and the CFO can model the payback period in a single meeting.


← all field notes Start a retainer →