A guide to building a business case deck that survives an investment committee — the seven sections it needs, what approvers are actually checking, and where most of them fall apart.
Most business cases don't fail because the idea is bad. They fail because the deck asks the room to trust a conclusion it hasn't been walked to. The analyst spent three weeks on the model and forty minutes on the slides, and it shows: the logic that lives in their head never made it onto the page.
A business case presentation has a narrow job. It has to move a decision-maker from "I'm not sure why we're here" to "approved, here's the money" inside twenty to thirty minutes, most of which will be interruptions. That is a structural problem before it is a design problem. Get the structure right and the deck almost writes itself. Get it wrong and no amount of formatting saves it.
Below is the structure that works, followed by what the people in the room are actually testing for, and the failure modes that sink otherwise-solid cases.
The seven sections a business case deck needs
Think of the deck as an argument, not a report. Each section answers the objection the last one raised.
-
Problem or opportunity. Open with the "why now," not the solution. What is broken, what is at stake if nothing changes, and why this window is open today and not next year. Quantify the status quo — the cost of doing nothing is your real baseline, and if you can't size it, you can't claim a return against it.
-
Options considered. Approvers distrust a case that presents one option, because it reads as advocacy rather than analysis. Show the two or three real alternatives you evaluated, including "do nothing" and the cheaper half-measure. Make it visible that you looked before you leapt.
-
Recommendation. State the single option you are backing, in one line, early. Everything after this point exists to defend it. Don't make the room reverse-engineer your recommendation from the financials.
-
Financials and ROI. The numbers that matter to a committee are cost, the return (NPV, IRR, or payback depending on your organisation's convention), and the shape of the cash flows over time. Show the base case, but show a downside case beside it — a single-scenario projection signals you haven't stress-tested the idea. Tie every major assumption to a source the room can challenge.
-
Risks and mitigations. Every experienced approver is already building this slide in their head. Build it for them. List the three or four risks that could actually kill the return, rate them honestly, and pair each with a mitigation or an early-warning trigger. Naming the risk yourself is what earns trust; hiding it is what loses the vote.
-
Implementation plan. A recommendation without a credible path to execution is a wish. Show the timeline, the major milestones, who owns delivery, and what resourcing it requires. Staged plans with decision gates are far easier to approve than one irreversible commitment, because they let the room say yes to a smaller bet first.
-
The ask. End with exactly what you need: the decision, the amount, and the date. If the room has to guess what you want approved, you have already lost momentum. One clear slide — "we are asking the committee to approve €2.4M in staged funding, decision needed by month-end" — closes the loop the problem statement opened.
This is the same spine whether you're pitching a corp-dev acquisition, a finance transformation, or a new product line. The section on structure and reusable smart templates covers how to keep this skeleton consistent across a portfolio of cases so approvers learn to read your decks quickly.
What decision-makers actually check before they approve
Understanding what the room is testing changes how you build every slide. Approvers are rarely evaluating your enthusiasm. They are checking a short, specific list:
- The counterfactual. What happens if we don't do this? A case measured against a healthy status quo is weak; a case measured against a deteriorating one is strong. Make the baseline explicit.
- The downside. Not "what do we expect" but "what if we're wrong." Committees approve cases where the downside is survivable, not cases where the upside is largest.
- Decision rights and reversibility. Can we stop, pivot, or claw back? Staged commitments with off-ramps clear far faster than all-or-nothing asks.
- Ownership. Whose name is on delivery? A business case with no accountable owner is a document, not a plan.
- Assumption traceability. Where did the growth rate, the synergy number, the ramp curve come from? If the source is "the team's view," expect the whole case to be discounted.
For a deeper read on how senior approvers weigh a case and where their attention goes in a live meeting, our piece on reading executive insights is a useful companion to this one.
Common failure modes
Most rejected business cases share the same handful of self-inflicted wounds:
Leading with the solution. Opening on the recommendation before the problem is established forces the room to evaluate an answer to a question they haven't accepted. Earn the problem first.
No do-nothing baseline. Without a status-quo option, there is nothing to compare the recommendation against, and "better than nothing" is not a return.
One scenario. A single confident projection reads as naïveté, not conviction. A base case flanked by a downside reads as rigour.
False precision. An NPV quoted to the euro built on a growth assumption that's a guess invites the room to attack the decimals instead of debating the decision. Round to the precision your inputs actually support.
Burying the ask. If the specific decision, amount, and deadline aren't on one clean slide, approval stalls in ambiguity even when everyone in principle agrees.
Implementation as an afterthought. A brilliant case with a vague delivery plan tells the committee you've thought about winning the argument but not about doing the work.
Too many slides. Thirty dense slides do not signal thoroughness; they signal that you couldn't find the argument. Put the analysis in an appendix and keep the main line tight.
How AutoPresent helps assemble one
Structuring the argument is the hard part, and no tool does that thinking for you. What a tool can remove is the hours between "I know what I want to say" and "the deck looks like it came out of a strategy studio."
AutoPresent is built for exactly this audience — strategy, corporate development, and finance — rather than general presentations. You can turn a model, a Word memo, or a diligence dump into a first structured draft instead of building from a blank slide, then edit everything in fully editable PowerPoint, because a business case is never final until five minutes before the meeting. Its smart templates give you a consistent options-comparison layout, financial-summary slide, and risk register to drop your own numbers into, and the theme switcher rebrands the whole deck to your company or client colours in one step. For a high-stakes case going to a board or IC, the Expert Deliverables option puts former MBB consultants on building or reviewing the deck before it ships.
None of that replaces the judgment in your financials. It just means the twenty hours you'd have spent formatting go back into pressure-testing the assumptions the committee is about to attack.
The takeaway
A business case presentation is an argument with a budget attached. Build it as seven linked sections — problem, options, recommendation, financials, risks, plan, ask — anticipate the five things approvers check, and avoid the self-inflicted failure modes, and you give a good idea its best chance in the room. The structure is what gets it approved. Everything else is presentation.