What goes in a business case: the sections every one needs
A business case is a structured argument for spending money, time, or attention on something, written for whoever has the authority to say yes. It does not need to be long, but it does need to be complete: a decision-maker should be able to read it and understand what you want, why it matters, what it costs, what could go wrong, and what happens if they do nothing.
Formats vary by organization, but nearly every business case contains the same core sections. Here is the standard anatomy and what belongs in each.
1. Executive summary
This goes first and is written last. In a few short paragraphs (or one page), it states the request, the expected benefit, the cost, and the recommendation. Busy approvers often read only this section, so it has to stand alone. If someone reads nothing else and still understands your ask, your summary works.
2. Problem or opportunity statement
Describe the problem you are solving — or the opportunity you want to capture — in concrete terms. What is happening, who is affected, and how big is it? Ground it in facts you can support: observed pain points, customer feedback, operational data, or known constraints. A vague problem ("our processes are inefficient") produces a vague case; a specific one ("the support team spends half its day re-entering order data by hand") makes the rest of the document easy to write.
3. Objectives
State what success looks like in measurable terms. Objectives connect the problem to a target: reduce handling time, cut error rates, increase capacity, improve a specific customer metric. Keep the list short — three to five objectives is plenty — and make each one specific enough that you could later check whether it was achieved.
4. Options considered
Never present only your preferred option. Decision-makers want to see that you weighed alternatives, including the "do nothing" option. A typical structure:
- Option A: do nothing. What happens if the problem is left alone? This is your baseline — every other option is compared against it.
- Option B: the recommended approach. Your proposal, described concretely enough to cost and evaluate.
- Option C: a lighter or heavier alternative. A cheaper partial fix or a more ambitious version. This shows range.
One option is a demand. Two or three options is a case.
5. Costs
List the full cost of each option — not just the headline purchase price. Include implementation effort, training, ongoing maintenance, and the time of people who will work on it. State your assumptions plainly: costs are estimates, and decision-makers respect estimates that show their working more than precise-looking numbers with no basis. Include a time horizon (one year, three years) so costs and benefits are compared over the same period.
6. Benefits
Benefits should be as specific as the costs. Quantified benefits — time saved, errors reduced, revenue enabled — carry the most weight. Qualitative benefits (better morale, reduced risk, improved customer experience) are legitimate too, but present them as secondary and be honest about which is which. Every claimed benefit should trace back to the problem statement: if it does not address the stated problem, it does not belong.
7. Risks and mitigations
Listing risks does not weaken your case; it strengthens it, because it shows you have thought it through. Common risks include implementation delays, lower-than-expected adoption, dependency on a single vendor or person, and cost overruns. For each risk, note how likely it is and what you would do about it. A risk with no mitigation plan reads as a hope.
8. Recommendation and next steps
Say plainly which option you recommend and why, in one or two sentences. Then list the concrete next steps: who approves, what the decision unlocks, and what happens first after approval. Ending with next steps makes it easy for the approver to say yes — they know exactly what their yes sets in motion.
9. Appendix (optional but useful)
Detailed calculations, data sources, vendor quotes, and technical detail belong in an appendix, not the main body. The main body tells the story; the appendix proves it. Anyone who wants to audit your numbers can; everyone else can read the case without drowning in detail.
Length and proportion
For most internal proposals, two to five pages of main body (plus appendix) is the sweet spot. Longer cases do not persuade more — they get skimmed. A useful rule of thumb: the executive summary should be roughly ten percent of the total, the problem and options about half, and the costs, benefits, risks, and recommendation the rest.