Business case: asking for money in a way that gets a decision

A business case argues that a specific spend or change is worth making. It is written for someone who controls a budget, has several competing requests, and will spend a few minutes on yours. That reader has one question — should we do this — and a business case that does not answer it in the opening paragraph will be deferred rather than refused, which is worse.

The most common structural mistake is to describe the solution at length and the decision briefly. The reader does not need the implementation detail; they need to know what is being asked, what it costs, what changes if you do it, and what happens if you do not.

What a business case must contain

• The decision requested, in the first two sentences, with the amount and the date by which it is needed.
• The problem or opportunity, in terms of consequence — money, risk, capacity, customers — not in terms of what is missing.
• Options considered, including doing nothing. A case with one option is a proposal, and readers correctly distrust it.
• The recommendation, with the reason it beat the others.
• Costs, split into one-off and ongoing, and including internal time. Omitting time is the most common way a case understates cost.
• Benefits, each with how it will be measured and when. Unmeasurable benefits should be labelled as such rather than dressed up.
• Assumptions, stated plainly, since they are what the reader will actually probe.
• Risks and what you would do about each, which strengthens rather than weakens the case.
• Timeline and who does the work — a benefit dependent on someone who has no capacity is not a benefit.
• How and when success will be reviewed.

Include the do-nothing option and cost it honestly. It is the option the reader is implicitly comparing against anyway, and being the person who has quantified it is worth more than any amount of enthusiasm for your preferred choice. Sometimes doing nothing is genuinely right — saying so when it is buys credibility for every case you write afterwards.

Writing it

1. Write the decision sentence first: what you want, how much, by when. If it takes more than two sentences, the ask is not clear yet.
2. Quantify the problem before proposing anything. Hours lost, revenue at risk, error rate, customers affected — with a source.
3. List real options, including a cheaper partial version. Two serious alternatives make the recommendation credible.
4. Cost each option fully, internal time included, over the same period.
5. State benefits as measurable changes with a measurement method and a date, and mark the ones you cannot measure honestly.
6. Write assumptions as a short list. Readers who find a hidden assumption stop trusting the numbers around it.
7. Keep it to two pages plus appendices. Detail belongs behind the summary, not in front of it.
8. Send it before the meeting rather than presenting it cold — decisions improve when the reader has had time to find their objection.
9. Agree the review date in the case itself, so the benefits are checked rather than assumed.

Benefits that survive scrutiny

Claimed benefits fall into three types and it pays to label them. Cash benefits reduce a real cost line and can be verified afterwards. Time benefits free up hours, which only become money if those hours are redeployed — say what they will be used for, or the reader discounts them entirely, correctly. Risk benefits reduce the chance or size of something bad, and are best expressed as the exposure avoided rather than as a probability nobody can defend. A case that mixes all three into one number invites the question that sinks it.

In Ettex, the case itself lives in Ettex Docs — templates so every case starts from the same structure, threaded comments with @mentions so a finance reviewer can question a figure against the paragraph it sits in, and version history so the case as approved is recoverable when the benefits are reviewed a year later. The costing and the option comparison belong in Ettex Sheets with formulas and a chart of the cash profile; if you present it, Ettex Slides handles the summary; approval can be recorded through Ettex Signature; and the review date goes in Ettex Calendar so the promise to check the benefits is kept.

The boundary: Ettex has no financial modelling or approval workflow. Nothing here calculates payback, NPV or IRR, routes the case to approvers, tracks benefits after the decision, or maintains a portfolio of cases. You write the document and build the model. Which is the honest division — the numbers in a business case need to be yours in every sense.

Why business cases stall

• The ask buried on page three, so the reader never finds the decision.
• One option presented, which reads as advocacy rather than analysis.
• Do-nothing omitted or dismissed in a sentence.
• Internal time excluded from costs, understating the real figure.
• Benefits with no measurement method, which get discounted to zero by any experienced reader.
• Time savings claimed without saying what the freed hours will do.
• Assumptions hidden inside a spreadsheet rather than listed.
• No review date, so nobody ever finds out whether the last case was right — which is why the next one is harder to get approved.

A business case gets a decision when the ask is in the first two sentences, doing nothing is costed, benefits are measurable, and a review date is written into the document.