You have an idea worth doing. You have a spreadsheet, a deck, and a slot on someone’s calendar. Three weeks later the answer is a polite version of “not right now,” and nobody can quite explain why.
Business cases rarely get rejected on merit. They get rejected because the person who had to say yes could not see the shape of the decision clearly enough to feel safe saying it. Approval is not a prize awarded to the best idea in the room. It is a choice made by a specific human being, with specific incentives, under time pressure, usually with incomplete information and several other things competing for the same money.
That reframing changes what you build. A business case is not a persuasion document. It is a decision-support document. Your job is to make the decision easy to make, easy to defend six months later, and cheap to reverse if it turns out to be wrong. What follows is how to construct one that clears that bar, whether you are asking a board for a serious budget line or asking your co-founder for two months of engineering time.
Why solid proposals get turned down
If you have watched enough proposals die, the patterns repeat. Almost none of them involve the idea being bad.
The most common cause is ambiguity about what is actually being asked. A document that describes an opportunity at length but never states a specific amount, a specific timeline, and a specific decision date leaves the approver with nothing to approve. They cannot say yes to a mood. So they ask for more analysis, which is the polite form of no.
The second cause is unowned risk. Every proposal carries risk, and everyone in the room knows it. When a document pretends otherwise, the approver has to generate the risks themselves, on the spot, in front of colleagues. That is unpleasant work and it makes them defensive. When you list the risks yourself, you take that job off their plate and you signal that you have thought past the enthusiasm stage.
The third cause is a mismatch between your framing and their scoreboard. You may care about developer experience, technical debt, or customer sentiment. The person approving may be measured on gross margin, cash runway, or headcount efficiency. Both sets of concerns can be legitimate at once, but the document has to be written in the currency the approver is paid in.
A business case does not need to be exciting. It needs to be defensible by someone who was not in the room when you wrote it.
The fourth cause is timing you did not check. Budgets have cycles. Attention has cycles. A perfectly good proposal presented the week after the annual plan is locked competes against nothing and loses anyway, because there is no mechanism left to fund it. Knowing when money gets allocated in your organization is worth more than another ten hours of analysis.
Start with the decision, not the idea
Before you open a document, write one sentence: “I am asking [person] to approve [specific thing] by [date] so that we can [outcome].” If you cannot fill in all four blanks, you are not ready to write.
This sounds trivial. It is not. Most weak business cases are weak because the author never decided what they were asking for. They wanted general support, or budget “in the range of,” or a green light to explore. Vague asks get vague answers, and vague answers are indistinguishable from rejection.
Know who actually decides
The person who calls the meeting is often not the person who decides. In small companies the decider is usually obvious. In larger ones there is typically one economic buyer, one or two people with veto power, and several who will be consulted and whose objections carry weight even though they cannot approve anything.
Find out who those people are before you write. Then write primarily for the economic buyer and pre-handle the objections of the veto holders. If your finance lead always asks about payback period, put payback period in the summary rather than in an appendix. If your operations lead always asks who will support the thing after launch, answer that before being asked.
Right-size the effort
A twenty-page business case for a modest decision reads as poor judgment, not as diligence. Scale the artifact to the size of the commitment. A useful rule of thumb:
- Small and reversible: one page or a well-structured message. State the ask, the cost, the expected benefit, and the date you will review it.
- Meaningful but recoverable: two to three pages with a simple financial model attached. Include options and a recommendation.
- Large or hard to unwind: a full case with sensitivity analysis, a staged plan, defined kill criteria, and named owners.
Reversibility matters more than size. A decision you can undo in a month deserves less scrutiny than a decision that locks you into a three-year contract, even if the three-year contract looks cheaper per month on paper.
The five parts that survive scrutiny
Structure varies by organization, but the content that actually gets tested in a review is consistent. Five components do the work.
1. The problem, stated in the business’s own terms
Describe the current state with something observable, not adjectives. “Onboarding takes eleven business days from contract signature to first successful use” is a problem statement. “Our onboarding is inefficient” is a complaint. If you do not have a measurement, spend a week getting one before you write anything else. A crude measurement collected honestly beats a confident assertion every time.
Then connect the problem to money or risk. Slow onboarding delays revenue recognition, increases support load, and raises early churn. You do not need to quantify each link precisely. You need to show the chain of causation clearly enough that the approver believes the problem costs something real.
2. The options, including doing nothing
Present at least three: do nothing, a minimal intervention, and your recommendation. Sometimes a fourth, the expensive comprehensive version, is worth including specifically so the recommendation looks proportionate.
Include “do nothing” honestly. Describe what happens if the status quo continues for another year. This is the option the approver is implicitly choosing every time they defer, and making its cost visible is often the single most persuasive thing in the document. It also protects your credibility, because it shows you are not in love with your own proposal.
3. The financial picture
Three numbers matter more than the rest: total cost including the parts people forget, the expected benefit expressed as cash or risk reduction, and the time it takes to get back to even. Everything else is supporting detail.
Total cost is where most cases lose trust. The license fee is easy. The migration effort, the internal time, the training, the parallel running period, the ongoing administration, and the eventual exit cost are the ones that get missed. When you include them, a reviewer who has been burned before relaxes, because you have demonstrated that you know where the bodies are usually buried.
4. The risks and what you will do about them
List the four or five risks that would genuinely derail this. For each, say how likely it is in plain words, what it would cost, and what specific action reduces it. Avoid risk registers with twenty low-severity entries; they read as bureaucracy rather than thought.
Include at least one risk that is genuinely uncomfortable. If every risk you list is minor and well-controlled, an experienced reviewer will assume you are hiding something or have not looked hard enough.
5. The plan and the exit
Show the sequence, the owner of each phase, and the checkpoint dates. Then state the kill criteria: the specific conditions under which you would stop and what stopping would cost. Almost nobody does this, and it is disproportionately effective. It converts an open-ended commitment into a bounded experiment, which is a much smaller thing to say yes to.
Getting the numbers right without faking precision
The fastest way to lose a business case is to present a number you cannot defend. Someone asks where the growth assumption came from, you hesitate, and the whole document becomes suspect.
The fix is not more decimal places. It is showing your reasoning. Every significant number should have a visible source: measured from your own data, quoted from a vendor, or explicitly assumed. Label assumptions as assumptions. A clearly labeled estimate is credible. An unlabeled estimate dressed as a fact is not.
Build the model backward
Start from the outcome and work back to what has to be true. If the case rests on saving six hours a week across a team, ask what those six hours are worth in practice. Do they translate into cancelled contractor spend, deferred hiring, or more output from existing staff? Only the first two are cash. The third is real but softer, and pretending it is cash will get you caught.
Show the range, then commit
Give a conservative case, an expected case, and an optimistic case, then say plainly which one you are willing to be held to. Approvers are not fooled by single-point forecasts, and they respect someone who names their downside. The conservative case should still clear the approval bar. If the proposal only works in the optimistic scenario, you do not have a business case yet.
Test the assumption that carries the most weight
In most models, one or two assumptions drive nearly everything. Find them by changing each input by a fifth and seeing what moves the answer most. Then spend your remaining research time on those inputs alone. This is the highest-return hour you will spend on the analysis, and it also tells you exactly which question to expect in the meeting.
Writing it so a busy person can approve it
Assume your reader gives the document four minutes, on a phone, between two other meetings. Everything important has to survive that.
Open with a summary that stands alone: the ask, the cost, the benefit, the payback, the main risk, and the decision date. Six lines. If someone reads only that block and approves, the document has done its job. Everything after it exists to answer questions, not to build up to a reveal.
Use plain language. Write “we would spend” rather than “an investment would be deployed.” Avoid the passive voice around commitments, because it hides who is responsible. Cut every sentence whose removal would not change the decision.
Keep the appendix separate and generous. A short main document with a thick appendix signals confidence.
The meeting before the meeting
Proposals that get approved in the room were usually approved before the room. The formal meeting ratifies a decision that has already been shaped in private conversations.
Send the document to your key stakeholders two or three days ahead with a specific request: “Tell me what would stop you approving this.” That question outperforms “any feedback?” by a wide margin, because it asks for objections rather than opinions. Then fix what you can and, for what you cannot, acknowledge it explicitly in the document. Nothing disarms an objection like seeing it already written down in your own words.
Watch for the stakeholder who says nothing in private and then raises a fundamental concern in the meeting. Go find them first.
Failure modes worth avoiding
- Leading with the solution. If the first thing the reader learns is which tool you want to buy, they evaluate the tool instead of the problem.
- Hiding the total cost. Presenting the monthly figure without the annual commitment or the implementation effort destroys trust the moment someone does the multiplication.
- Benefits with no owner. If the case promises savings, someone has to be accountable for realizing them. Unowned benefits are treated as fiction, correctly.
- Ignoring the operating cost after launch. Many proposals fund the build and forget who maintains the thing in year two.
- Arguing from urgency alone. Manufactured deadlines read as pressure tactics and invite the reviewer to slow down on principle.
- No definition of success. If you cannot say what result would prove this was the right call, you have not finished thinking.
Frequently Asked Questions
How long should a business case be?
Short enough that the decision-maker reads all of it. For most decisions inside a small or mid-sized company, one to three pages plus an appendix is right. Length should scale with how hard the commitment is to reverse, not with how much work you did. If you cannot summarize the ask in six lines, the thinking is not finished.
What if I do not have reliable data to support the numbers?
Use explicit assumptions and label them. State the assumption, state where it came from, and show what happens to the conclusion if it is wrong by a meaningful margin. Reviewers accept uncertainty that is disclosed and quantified. What they will not accept is discovering an invented number themselves during the meeting.
My proposal was rejected. Should I resubmit it?
Only after you understand which of three things happened: the idea was wrong, the timing was wrong, or the case was wrong. Ask the decision-maker directly which it was. If it was timing or presentation, a revised case at the right point in the budget cycle often succeeds with the same underlying idea. If the idea itself does not fit the strategy, resubmitting the same thing in nicer formatting will only cost you credibility.
What approval actually buys you
Getting a yes is not the finish line, and treating it that way is how people burn the credibility they just earned. The moment a business case is approved, it becomes a promise with your name on it. The numbers you used are now the numbers you will be measured against, whether or not anyone says so out loud.
The practical move is to close the loop deliberately. Put a review date in the calendar at the moment of approval, report against your own forecast honestly at that date, and say plainly where you were wrong. Do this two or three times and something valuable happens: your future proposals get read differently. People stop auditing your assumptions line by line, because your track record is doing that work for you.
That is the real asset. Any individual business case is worth whatever it is worth. A reputation for cases that turn out roughly the way you said they would is worth far more, and it compounds. Build each one as though the person reading it will check your last three.
