Produces the document a sponsor can approve, challenge, or kill on its merits — because every benefit shows its arithmetic, every option includes the one nobody advocates for (doing nothing), and the case names the single assumption that flips the recommendation. Decides whether to invest; tech-comparison-matrix picks between technologies after, prd-draft captures requirements after, exec-summary compresses this doc for a board.
-
Pin the decision and the decider. What exactly is being decided ("invest ~3 engineer-quarters in X" — not "improve our tooling"), who decides, and by when. Ask at most 2 questions, spent on the cost of the status quo ("what does the current state cost per month, in what units?") and the decision deadline. A business case without a named decision is an essay.
-
Always include Option 0: do nothing. Costed like every other option — the status quo has a price (ongoing pain, growing risk, deferred opportunity) and the case must beat it explicitly, not by assumption. Then 2–3 real alternatives (typically build / buy / partial-defer). Every option presented is one someone could genuinely champion; a lineup of two strawmen escorting the preferred option is theater, and reviewers smell it.
-
Quantify benefits as calculations a reviewer can re-run. Every benefit shows: the formula, each input with its source tag, and a confidence tag (high = measured data, medium = reasonable extrapolation, low = informed guess). ✅ "40 agents × ~20 min/ticket saved [data: time study] × 30 tickets/day → 18–24 FTE-hours/day, confidence: medium (assumes 75–100% of tickets touch the flow)" — ❌ "significant efficiency gains" — an adjective benefit is a benefit that didn't survive arithmetic.
-
Use ranges, never false precision. Three estimates multiplied together do not produce "327% ROI" — they produce a range, and the case says which end is likelier and why. State payback as a range too ("breakeven month 7–11"). Single-point outputs from multi-guess inputs are the most reliable sign a case is selling, not informing.
-
Cost all three layers, per option: build (people × time, the dominant and most-lowballed term — include ramp-up and the integration tail), run (infra, licenses, support burden, maintenance — the layer "buy" options hide in year 2+ pricing and "build" options hide in maintenance), and opportunity (what these people would otherwise ship — name the displaced thing, don't leave it abstract).
-
Name the flip-assumption. The sensitivity question, answered honestly: which single input, if wrong, reverses the recommendation? ✅ "The case rests on ≥60% agent adoption; below ~40%, Option 0 wins — adoption is [low confidence], so we propose a 4-week pilot before full commit." If no single assumption flips it, say which pair does. A case with no flip-condition is claiming certainty it cannot have.
-
Recommend one option, committally. The recommendation names the option, the reasoning in two sentences, what was given up (the strongest point of the runner-up, stated fairly), and any de-risking step (pilot, staged commit) tied to the flip-assumption. "It depends" is the analyst's job half-done; the decider can disagree with a recommendation, but they can't disagree with a shrug.
-
Lead with the ask. The first lines of the document: the decision requested, the cost, the headline benefit range, the deadline. ✅ "Ask: approve 3 engineer-quarters (~$210k loaded) for Option B; expected payback month 7–11; decision needed by July 1 to hit Q4 capacity." Emit with templates/business-case.md, one message.
