Why Most AI Business Cases Die in Committee
A VP at a 200-person logistics company told us last month that she’d pitched an AI project three times. Three different decks. Three different meetings. Three rejections. The idea was solid (automating freight invoice reconciliation, which was eating 60+ hours a week of manual work). But the business case read like a tech blog post, not a financial argument.
The fourth time, she rebuilt the whole thing around one number: $340,000 in annual labor costs tied to a process with a 4.2% error rate. She got approved in a single meeting.
That’s what a good ai business case does. It translates a technology bet into a financial decision. And financial decisions have a language, a structure, and a set of expectations that most AI proposals completely ignore.
An AI business case is a structured document that quantifies the costs, risks, expected returns, and timeline of a proposed AI initiative, written specifically to help decision-makers compare it against other uses of the same budget. It’s not a pitch deck about how cool the technology is. It’s a financial argument with a technology component.
This guide walks you through building one that doesn’t get tabled, sent back for revisions, or politely ignored. We’ve helped dozens of SMBs get AI projects approved internally, and the pattern of what works (and what doesn’t) is consistent enough to be a repeatable process.
Step 1: Pick the Right Problem Before You Pick the Right Technology
Here’s where most people start: “We should use AI for something.” That’s backwards. The business case starts with a business problem, not a technology solution.
Sit down with the people who actually do the work. Not the department head (though you’ll need them later). The people processing the invoices, answering the support tickets, reconciling the data. Ask them what takes forever. Ask them what they hate doing. Ask them where mistakes happen.
You’re looking for problems with three characteristics:
- High volume: The task happens hundreds or thousands of times per month. AI gets better ROI at scale.
- Repetitive pattern: There’s a recognizable structure to the work, even if it requires some judgment. Sorting emails into categories, extracting data from documents, matching purchase orders to invoices.
- Measurable cost: You can put a dollar figure on the current process. Hours spent, error rates, customer churn from slow response times, whatever. If you can’t measure it, you can’t build a business case around it.
What can go wrong here: picking a problem that sounds impressive but is hard to quantify. “Improving our strategic decision-making with AI” is not a business case. “Reducing our quote turnaround time from 48 hours to 4 hours so we stop losing deals to faster competitors” is a business case. The difference is specificity.
Side note: if you’re struggling to find a problem worth solving, that’s actually useful information. Not every company needs AI right now, and a business case that admits “we looked and the ROI isn’t there yet” builds more credibility than forcing a weak proposal.
Step 2: Quantify the Current Pain in Dollars
This is the step that separates business cases that get approved from business cases that get a polite “let’s revisit next quarter.” You need real numbers.

Map out the process you’re targeting. Every step. Then attach costs:
- How many people touch this process?
- How many hours per week do they spend on it?
- What’s their fully loaded cost per hour? (Salary plus benefits, usually 1.3x to 1.5x base salary. Your finance team can give you the exact multiplier.)
- What’s the error rate? What does each error cost to fix?
- Are there downstream costs? Lost deals from slow turnaround? Customer churn from bad experiences? Compliance risk from manual data entry mistakes?
Say you’re running a 50-person insurance agency and your team spends 30 hours a week manually entering policy data from PDF applications into your management system. At a fully loaded cost of $28/hour, that’s $43,680 per year just in labor. Add a 5% error rate that requires rework and occasionally causes E&O issues, and the real cost climbs higher.
Now you have a number. That number is your anchor for everything else in the ai business case. Every cost you propose gets compared against it. Every timeline gets evaluated against how long the company will keep bleeding that money.
What can go wrong: underestimating costs because you only counted direct labor and ignored error correction, management overhead, opportunity costs, and employee turnover driven by tedious work. Capture all of it. The bigger (and more honest) this number, the easier the approval.
Step 3: Define What “Success” Looks Like With Uncomfortable Precision
Vague goals kill business cases. “Improve efficiency” means nothing to a CFO. You need targets that are specific, time-bound, and connected to the dollar figures from Step 2.
Good success metrics look like this:
- Reduce policy data entry time from 30 hours/week to 8 hours/week within 90 days of deployment
- Decrease data entry error rate from 5% to under 1% within 60 days
- Free up 22 hours/week of staff capacity to handle 15% more policy renewals without hiring
Notice that last one. It connects the time savings to a revenue opportunity, not just a cost reduction. This matters. Decision-makers respond to growth arguments even more than efficiency arguments. If you can show that the freed-up capacity translates into revenue your team is currently leaving on the table, you’ve made the case twice as compelling.
Be honest about what you’re NOT claiming, too. If the AI will handle 80% of cases automatically but the remaining 20% still needs human review, say that. Overclaiming is the fastest way to lose credibility, and credibility is the currency of internal proposals. A reviewer who catches one exaggeration will doubt every other number in your document.
Step 4: Build the Cost Model (The Whole Cost, Not Just the Software)
Most failed business cases undercount costs. The software license or API fees are usually the smallest line item. Here’s what a realistic cost model includes:
| Cost Category | What to Include | Typical Range for SMBs |
|---|---|---|
| Software/API Costs | Licenses, API usage fees, cloud compute | $500 – $5,000/month |
| Implementation | Setup, integration, customization, consulting | $10,000 – $75,000 one-time |
| Internal Time | Staff hours for testing, training, feedback during rollout | 40-200 hours total |
| Change Management | Training, documentation, workflow redesign | $2,000 – $15,000 |
| Ongoing Maintenance | Monitoring, updates, model retraining, prompt tuning | $500 – $3,000/month |
| Contingency | Budget buffer for unknowns (industry standard: 15-25%) | 15-25% of total |
Add it all up. Compare it against the pain cost from Step 2. If your total first-year cost is $80,000 and the problem costs $150,000 per year, you have a story worth telling. If the numbers are close, you need to either find a cheaper solution or include the multi-year picture where the ongoing costs drop after implementation.
What can go wrong: forgetting the contingency buffer. AI projects hit surprises. Data turns out to be messier than expected. Integration takes longer. Your team needs more training than you planned. Build in 20% contingency and present it transparently. Decision-makers trust budgets that acknowledge uncertainty more than budgets that claim precision down to the penny.
Step 5: Calculate ROI in a Way Finance Actually Trusts
Here’s a thing nobody tells you about AI business cases: the ROI formula itself isn’t complicated. What’s complicated is making the inputs credible.
The basic framework:
Year 1 Net Benefit = (Annual cost of current problem) – (Total Year 1 project cost)
Payback Period = Total implementation cost / Monthly savings
3-Year ROI = (Total 3-year benefits – Total 3-year costs) / Total 3-year costs × 100
For the insurance agency example: if the current problem costs $43,680/year, implementation runs $45,000 in year one (including software, setup, and training), and ongoing costs are $12,000/year after that, here’s what the math looks like:
- Year 1 net: -$1,320 (basically break-even)
- Year 2 net: +$31,680
- Year 3 net: +$31,680
- 3-year total benefit: $62,040
- 3-year ROI: 90%
- Payback period: about 13 months
That’s a solid case. Not a slam dunk, not a moonshot. A realistic projection that a finance person would look at and say “this makes sense.”
Present three scenarios: conservative (assume 60% of expected benefit), expected, and optimistic (assume the AI handles more cases than projected). This shows you’ve thought about downside risk, not just the happy path. And if even your conservative scenario breaks even within 18 months, you’ve made it hard to say no.
Step 6: Address Risk Before They Ask About It
Every approval committee has at least one person whose job is to find reasons to say no. Respect them. Address their concerns before they raise them.
Common risks decision-makers worry about with AI projects:
- Data privacy and security: Where does the data go? Is it stored? Who has access? Is it compliant with your industry regulations? If you’re in healthcare, finance, or insurance, this section alone could be a page long. It needs to be.
- Accuracy and reliability: What happens when the AI gets it wrong? What’s the human review process? How do you catch errors before they reach a customer or a compliance report?
- Vendor dependency: What if the AI provider raises prices, changes their API, or goes out of business? What’s your exit strategy?
- Employee impact: Are people losing their jobs? (Usually the honest answer for SMBs is no, you’re freeing them from the worst parts of their job so they can do higher-value work. But you need to say this explicitly and mean it.)
- Implementation disruption: How much will this mess up day-to-day operations during rollout? Can you run old and new processes in parallel?
For each risk, include your mitigation plan. Don’t just list the risk and move on. “Data stays within our Azure tenant, never leaves our environment, and the vendor’s SOC 2 Type II report is attached as Appendix B” is a mitigation. “We take data security seriously” is not.
Step 7: Write It So a Non-Technical Person Can Approve It in 20 Minutes
You’ve done all the hard work. Now you need to package it so the person who controls the budget can actually process it quickly. Because they’re not reading your 15-page document word by word. They’re scanning it in the 20 minutes before the meeting.
Structure the final document like this:
Executive Summary (1 page): The problem in one paragraph. The solution in one paragraph. The cost vs. benefit in one paragraph. The ask in one sentence.
Problem Definition (1-2 pages): Current state, cost quantification, impact on the business. All the work from Steps 1-2.
Proposed Solution (1-2 pages): What you’re proposing, how it works at a high level (skip the technical architecture unless they ask), success metrics from Step 3.
Financial Analysis (1-2 pages): Cost model, ROI calculation, three scenarios. The table from Step 4 goes here.
Risk Assessment (1 page): Risks and mitigations from Step 6.
Implementation Timeline (half page): A simple Gantt-style breakdown. Pilot phase (4-6 weeks), evaluation (2 weeks), full rollout (4-8 weeks), optimization (ongoing).
Total: 6-8 pages, plus appendices for anyone who wants to go deeper.
What can go wrong in this final step: burying the ask. Put the specific budget request and approval needed on page one, in the executive summary. Don’t make them hunt for the number. If you want $60,000 for a six-month project, say so in the first half-page. Hiding it at the end signals that you’re not confident in it.
After the Approval: What to Do Next
Getting the green light is the starting line, not the finish. A few things we’ve seen trip up companies right after approval:
Start with a pilot, not a full rollout. Even if you got budget for the whole thing. Pick one team, one process, one workflow. Prove it works in a controlled environment before you scale it across the company. This also gives you real performance data to update your business case projections (which you should do quarterly, by the way).
Set a 90-day checkpoint. Come back to the approval committee with actual results compared to your projected metrics. This builds trust for the next AI project you propose, and there will be a next one.
Document everything. What worked, what didn’t, what took longer than expected, what was easier than expected. This becomes your template for the next ai business case, and it gets better every time.
We’ve seen companies go from struggling to get one AI project approved to having a standing quarterly AI budget because they proved the model works. That first business case is the hardest. It’s also the most important.
If you’re not sure where to start, or you want someone to pressure-test your numbers before you walk into that approval meeting, book a free AI audit with Tiger Tail. We’ll help you find the highest-ROI opportunity and build the business case around it, so you walk in with numbers that hold up to scrutiny.