A business case has to answer eleven questions: what you are asking for, why now, what else was considered, why this option, what it costs, what it returns, whether the money works, what the case depends on, what could go wrong, how it gets delivered, and what you need from the approver. How many slides that takes depends on the approval gate. At a departmental sign-off several questions share a slide. At a capital committee some take two. What does not change is that leaving one unanswered is what sends a case back. The structure matters less than who it has to survive. A strategy deck is judged on whether the reasoning holds. A business case is judged by someone whose job is to find the number that does not. That changes what each slide has to carry, and the eleven below are specified on that basis.
Key takeaways
Build around the questions, not a slide count. The same eleven questions compress into four slides or expand into twenty depending on the gate.
The do-nothing option is mandatory and usually fudged. An approver who suspects you have strawmanned the baseline will discount the whole case.
Benefits without a named owner are wishes. If nobody will be measured on delivering the saving, the case rests on nothing.
Cost of delay persuades where ROI does not. Many approvals turn on what one more quarter of inaction costs rather than on the return.
Name the assumption that breaks the case before anyone asks. Volunteering it reads as rigor. Having it found reads as concealment.
AI builds the exhibits and the narrative. It cannot source the costs or own the benefits. Those come from finance and from the people who will be held to them.
A business case asks for money, and that makes it a different document from the decks around it. A strategy deck persuades a room that an idea is right. A proposal persuades a client to choose you. A business case has to survive a finance function whose specific job is to test whether the numbers hold, and it is usually read by at least two audiences with different concerns: a sponsor who wants the thing to happen and a controller who wants to know what happens if the benefits arrive late.
That dual audience explains most of what goes wrong. Cases written only for the sponsor read as advocacy and get sent back for evidence. Cases written only for the controller read as a spreadsheet with no argument and get sent back for a recommendation. The structure below carries both.
Before you build: three things that set the shape
Settle these first, because each changes the deck materially.
Who approves, and at what threshold. A budget holder signing off a departmental spend wants a page and a number. An investment committee above a capital threshold wants options analysis, sensitivities and a delivery plan. Find out which gate you are going through before you decide how long the deck is, because overbuilding wastes a week and underbuilding costs a cycle.
Whether this is a decision or a ratification. Some cases go to a body that genuinely decides. Others go to a body that formalizes a decision already taken in a corridor. The first needs the options analysis to be real. The second needs it to be defensible on the record.
What the money is being measured against. Cash savings, avoided cost, revenue, risk reduction and compliance are not interchangeable, and some organizations will fund one and not another. A case built on avoided cost presented to a committee that only counts cash will fail on a technicality.
The eleven questions, and the slide each becomes
Each question has a job and a characteristic way of failing. At a small gate, questions 5 to 7 often share one slide and 8 to 10 another. At a capital committee, each earns its own and some need two.
1. The ask. What you want approved, how much, over what period, and by when. Specific: approve $2.4m of capital over 18 months, decision needed by 15 March to hold the vendor pricing.
Fails when: it opens with background and makes the reader hunt for the number. The approver should know what they are being asked in the first ten seconds.
2. Why now. The problem, its size, and what it costs to leave alone. The timing argument sits here: a contract expiry, a regulatory date, a system reaching end of support, a competitor move.
Fails when: it describes a problem without dating it. Without a clock, every case competes with every other case and loses to whichever has a deadline.
3. Options considered. Three or four, always including doing nothing, each with its cost and its consequence.
Fails when: the alternatives are obviously strawmen. An approver who can see the options were built to make one look good stops believing the rest of the deck.
4. The recommendation. Which option and why, against criteria stated explicitly rather than implied.
Fails when: the criteria appear only here and look reverse-engineered from the answer. State them on the options slide and apply them visibly.
5. What it costs. One-off and recurring, split out, phased across the period. Include the costs people forget: internal time, change management, training, decommissioning the thing being replaced, and the run cost after go-live.
Fails when: it shows only the capital number. A case that understates run cost gets found out in year two, and that is remembered on the next case.
6. What it returns. Benefits quantified, each with a basis and an owner. The basis is how you calculated it. The owner is the person who will be measured on it.
Fails when: benefits are stated as percentages without a baseline, or without anyone's name against them.
7. The financial case. Payback period, net present value, and whatever metric your organization actually uses. Show the cash profile across the period, not just the headline.
Fails when: the profile is hidden. A case with a three-year payback and eighteen months of negative cash has a funding question inside it, and the approver would rather hear it from you.
8. Assumptions and sensitivities. The handful of assumptions the case depends on, and what happens to the return if the main ones move.
Fails when: it lists every assumption equally. Name the two that matter, show the case under each moving adversely, and say at what point the case stops working.
9. Risks and mitigations. Delivery risk, benefit risk, and dependency risk, each with an owner and a mitigation that costs something.
Fails when: mitigations are verbs with no resource behind them. "Monitor closely" is not a mitigation.
10. The delivery plan. Phases, milestones, decision points, and who is accountable. Enough to show the thing is deliverable, not a project plan.
Fails when: it implies a smooth line from approval to benefit. Approvers trust a plan with a stage gate in it more than one without.
11. What we need from you. The decision itself, plus anything else: resources, a governance slot, a policy exception, a decision date.
Fails when: it ends on a summary instead of an ask, leaving the room to decide what to do next.
Appendix. The full cost model, benefit calculations, vendor comparison, technical detail, and the options you considered and rejected early. Everything that would be asked for under challenge.
The four things an approver will actually test
Whatever is on the slides, scrutiny concentrates here.
The baseline. Not what the project delivers, but what happens without it. If doing nothing looks implausibly bad, the reviewer assumes the baseline was built to justify the ask and discounts everything downstream.
Benefit ownership. The question is some version of "whose budget goes down when this lands?" A benefit nobody has agreed to carry in their numbers is not a benefit, it is an estimate. Get the owner's name on the slide before the meeting, not during it.
The gap between gross and net. Gross savings are easy. The net figure after run cost, internal time and the benefit that was already counted in someone else's business case is the one that gets tested.
What breaks it. Every approver eventually asks which assumption, if wrong, kills the return. Having that on slide 8 rather than improvising it is the difference between looking rigorous and looking caught out.
An AI workflow for building one
The order matters more than the tooling.
Settle the numbers before any slide exists. Costs come from finance or procurement, benefits from the people who will own them, the baseline from whoever runs the process today. This is sourcing, not drafting, and it cannot be generated. A business case assembled from plausible figures collapses the first time someone checks one.
Draft the options and the recommendation yourself. Which alternatives are genuine, which criteria decide between them, and what you are actually recommending is the judgment the case exists to carry.
Then use AI for the build. Give it the cost model, the benefit schedule and your recommendation, and ask for the deck: the phased cost exhibit, the cash profile, the sensitivity table, and the narrative connecting them. This is assembly work and it compresses well.
Ask for the exhibits as editable charts. Business cases get revised more than most decks, because finance comes back with a changed number. A chart you can edit survives that. An image means rebuilding.
Check the arithmetic independently. Totals should reconcile between the cost slide, the financial case and the appendix model. Compression separates figures from their subtotals, and a case with two different numbers for the same thing loses the room immediately.
Keep each figure traceable to where it came from. When someone asks where the $340k came from, the answer should be a file you can open, not a recollection.
If you would rather not assemble it by hand
Most of the build is mechanical, and the mechanical part is where revisions bite.
A business case has to be structured as an argument, carry exhibits that reconcile, arrive in your organization's template, and be rebuilt every time finance changes an input. Done manually that is days of work, repeated.
Perceptis AI works from the files the case already produced, including an Excel cost model, a Word memo or a PDF of the vendor quotes, and builds the deck top-down with titles that state conclusions rather than label sections. Each figure stays tied to the file it came from, with clickable links in the web interface, so a challenged number can be traced rather than remembered. Charts are generated as native editable objects in your own template, which is what makes the third revision an edit rather than a rebuild.
What remains yours is the part the approver is actually buying: the options, the recommendation, and the benefits someone has agreed to own. The case studies show the output on real work, and you can attach a cost model in the app to see what the first draft looks like.
Frequently asked questions
What goes in a business case deck?
Eleven things: the ask, why now, the options including doing nothing, the recommendation and the criteria behind it, costs split into one-off and recurring, benefits with a basis and an owner, the financial case with a cash profile, assumptions and sensitivities, risks with owned mitigations, a delivery plan, and a clear statement of what you need from the approver. Supporting models and rejected options go to the appendix. Whether each takes a slide or shares one depends on the gate.
What is the do-nothing option in a business case?
The baseline showing what happens if nothing is approved: costs that continue, risks that grow, revenue that does not arrive. It is mandatory because every other option is measured against it, and it is the first thing a skeptical approver tests. A do-nothing case built to look terrible undermines the entire deck.
How do I quantify benefits credibly?
Give each benefit a basis and an owner. The basis is the calculation, including the baseline it improves on. The owner is the person whose numbers change when the benefit lands, and who has agreed to that before the meeting. Distinguish cash savings from avoided cost from revenue, because some approval bodies will fund one and not another.
Can AI build a business case deck?
It can build the deck, not the case. Costs, benefits and the baseline have to be sourced from finance and from the people who will own them, and the options and recommendation are judgment. Once those exist, AI assembles the exhibits and the narrative quickly, which matters because business cases get revised repeatedly as inputs change.
