How to Build a Business Case for AI (That Actually Gets Approved)

Most AI business cases fail before they reach the decision-maker’s desk.

Not because the numbers are bad. Not because the technology doesn’t work. They fail because the person writing the case frames it as a technology investment when leadership is evaluating it as an operations decision.

Here’s how to build one that gets approved — and then actually delivers what you promised.

The One-Page Standard

Before anything else: your business case should fit on one page. If it doesn’t, you haven’t finished thinking through it yet.

A one-page AI business case has four sections:

1. The problem — one paragraph, specific and quantified
2. The proposed solution — what changes, for whom, how long it takes to build
3. The numbers — cost, savings, payback period
4. The ask — what you need approved, by when, to start

Everything else is backup material. Leadership doesn’t read appendices before they approve things. They read the one-pager, ask two questions, and decide.

Section 1: The Problem (Make It Feel Real)

The most common mistake: describing the problem in abstract terms.

“Our reporting process is inefficient” → nobody approves that.

“Our quality team spends 14 hours per week manually pulling data from three systems to produce the Monday morning defect report — a report that’s usually 48 hours stale by the time it reaches the plant manager” → that’s a problem a CFO can feel.

The formula for a good problem statement:

• Who does the work
• What they do (specifically)
• How long it takes (hours per week)
• What it costs (hours × loaded rate = annual labor cost)
• What the failure mode is (errors, delays, decisions made on bad data)

If you can’t fill in all five, you’re not ready to build the case yet. Go back and time the actual work.

Section 2: The Solution (Scope It Tightly)

Describe what changes — not what technology gets deployed.

Bad: “We will implement an AI agent using a large language model to automate reporting workflows.”

Good: “A reporting agent will pull data nightly from the QMS and ERP, normalize it, and deliver a formatted defect summary to the plant manager’s inbox by 6am Monday — eliminating the 14-hour weekly manual process.”

Three things your solution description must answer:

1. What does the system do, in plain language?
2. Who uses it, and how does their day change?
3. What does it not do? (Scope boundaries prevent scope creep and manage expectations)

Also include:

• Build timeline: 2–6 weeks for a first AI project is reasonable. More than 8 weeks and you need to cut scope.
• Who owns it after launch: AI systems need an owner. Name them in the proposal.

Section 3: The Numbers (Keep Them Conservative)

This is where most business cases oversell and then fail to deliver. Build your numbers conservatively — if anything, understate the benefit.

The basic ROI structure:

Item	How to Calculate
Annual labor cost of current process	Hours/week × 52 × loaded hourly rate
Build cost	Estimated hours × developer rate + any platform/API costs
Annual run cost	Ongoing maintenance + API/platform fees
Year 1 net savings	Annual labor cost − (build cost + annual run cost)
Payback period	Build cost ÷ monthly labor savings

Example:

• 14 hours/week × 52 weeks × $55/hour loaded = $40,040/year in labor
• Build cost: $12,000 (one-time)
• Annual run cost: $2,400 (API + maintenance)
• Year 1 net savings: $40,040 − $14,400 = $25,640
• Payback period: ~4 months

That’s a business case. It’s not complicated. It doesn’t require a financial model. It requires honest math.

What not to include:

• Productivity gains beyond the specific workflow (too speculative)
• Revenue upside (almost impossible to attribute directly)
• Competitive advantage claims (subjective, unverifiable)
• “Future AI capabilities” that aren’t in scope

Stick to the cost of the specific process you’re automating. That’s what you can defend.

Section 4: The Ask (Be Specific)

Leadership approves specific asks. They defer vague ones.

Vague ask: “Approval to explore AI automation for our reporting process.”

Specific ask: “Approval for $12,000 to build and deploy a quality reporting agent by July 15, with a 60-day post-launch evaluation period. Project owner: [Name]. First milestone: working prototype in 3 weeks.”

Your ask should include:

• Dollar amount (total, not “up to”)
• Timeline (specific date, not “Q3”)
• Owner (named individual, not a team)
• First milestone (within 3 weeks — proves momentum)
• Evaluation criteria (how will you know it worked?)

The Two Questions You’ll Get Asked

Every AI business case gets two questions. Prepare your answers in advance.

“What if it doesn’t work?”

The honest answer: the risk is the build cost, not ongoing costs. If the agent fails to deliver the report accurately, you revert to the manual process. The $12,000 build cost is the full downside. That’s the same risk as any process improvement project.

Don’t oversell the risk mitigation. Just quantify the downside clearly.

“Why now?”

This is actually an opportunity. The answer isn’t “because AI is hot.” The answer is the specific cost of waiting: “Each week we don’t build this costs us $770 in manual labor and produces a report 48 hours too late for the Monday production meeting. The next 6 months of delay costs $20,000 and 26 stale reports.”

That’s a concrete answer to a concrete question.

The Political Layer (Don’t Ignore It)

Numbers alone don’t get business cases approved. You also need:

An exec sponsor — someone at or above the decision-maker level who has already heard your proposal and said “this makes sense.” Find them before you formally present.

A named victim — who is currently doing this work? What will they do instead? “We’re freeing up 14 hours of [Name]‘s week so she can focus on supplier qualification instead of report assembly” is far more compelling than abstract headcount savings.

A fast first win — propose the simplest version that delivers real value, not the most impressive version. Getting a small win approved, delivered, and celebrated is worth more than a grand proposal that stalls in committee.

After Approval: Don’t Overpromise on Launch

The business case gets you the budget. The first 30 days after launch determines whether you get to do this again.

Set expectations correctly at the start:

• Week 1–3: build and internal testing
• Week 4: pilot with one user, gather feedback
• Week 5–6: refinement
• Week 7: full rollout

Track the baseline metric you cited in the business case. If you said 14 hours/week, measure whether that drops. Report back to the approver at 30 days with actual numbers.

This is what creates a track record that lets you propose the next project — and the one after that.

---

Want a template for each section of a one-page AI business case? The Operator’s AI Playbook includes fill-in-the-blank frameworks for every stage of an AI implementation — from first use case through full deployment.