An AI business case has seven sections: the problem in dollars, the proposed solution, all-in costs, the benefit, the owner and timeline, risks and the exit, and the ask. Six of them are structure; the benefit section is the case – it is where a claimed gain either survives scrutiny or dies. Build that section by counting the hours or errors the project avoids, converting them to loaded cost, and stating the result as a range with every assumption visible. Get that right and the rest of the document is an afternoon’s work.
Open with what the status quo costs, not what AI could do. Count the concrete waste the project attacks: hours of manual work per week, error rates and their rework, decisions delayed and what the delay costs. If the problem cannot be counted yet, counting it is your first task, because a case built on an uncounted problem inherits every weakness of a guess. One honest paragraph and one number: what this is costing us now, per year.
Describe the pilot in operational terms: which process, which team, what changes on day one, and what the tool actually does. Just as important, write down what is out of scope – the departments not included, the systems not touched. A bounded description reads as a plan; an unbounded one reads as an appetite. Skip architecture and vendor detail here; the reviewer is deciding whether the shape is sensible, not approving a design.
One table, three lines: software and subscriptions, people’s time at loaded cost, and outside help if any. Loaded cost matters – forty hours of an analyst’s time is not free just because the salary is already paid. Reviewers do not punish honest costs; they punish discovered ones. The expense that surfaces in month four without having been declared is the one that damages you, not the one you wrote down up front.
This is the section you will be challenged on, so build it to be challenged. The method: count what the pilot avoids – hours of manual work, errors and their rework – then convert that count to dollars at loaded cost, then state the result as a range, never a single number. Twelve hours a week of report assembly at a $55 loaded hourly rate is roughly $34,000 a year; write it as $25,000 to $40,000 depending on adoption, with each assumption listed beside it.
The range plus the visible assumptions is how you handle uncertainty honestly, and honesty here is a tactic, not just a virtue: when a reviewer attacks an assumption, they refine your number and the case survives; when they attack an unexplained number, the case dies. One test before you submit: the low end of the range must still justify the project. If it only works at the high end, it does not work.
Name the person who runs it – not a team, a name – along with the reporting rhythm and the dates that matter: start, first checkpoint, decision point. An approver reads this section as insurance: it tells them the project cannot drift for two quarters unattended. Three lines is enough, provided all three are specific.
List the three or four honest risks – adoption, data quality, integration effort – each with one line on mitigation. Then add the piece most cases omit: the exit. The checkpoint date, the deciding metric, and what stops if the target is missed. Writing the exit into the case converts the project from an open-ended commitment into a bounded one, and bounded commitments are the kind that get approved.
End with one sentence a reviewer can approve: the amount, the duration, and the decision you want from this meeting. “Approve $18,000 and one analyst at 25 percent time for a 90-day pilot, with a go/no-go decision at the 60-day checkpoint.” Vague endings squander sharp cases – if the reviewer finishes your document unsure what saying yes means, the answer defaults to no.
Five questions. One clear picture across all five dimensions of AI readiness. No credit card, no sales call, no fluff.
Take the QuickScan →Free · 5 questions · 3 minutes · Instant results
