Decision Support Reporting
Reports that end in a decision, not a question
Decision support is reporting built around a specific decision: the decision ID, its inputs, thresholds, and the analytical alternatives the data recommends — scoped, bidirectional, and shipped as actions.
What you will learn
- Frame reporting around a decision rather than a topic
- Model what-if inputs and rank alternatives
- Ship recommendations, not just trends
What is this?
Decision support reporting inverts the usual shape: start with the decision to be made (go/no-go, price, ship, hire), then assemble only what informs it — the decision's inputs with thresholds, the alternatives with their analytics, and a recommendation with confidence. It's scoped, bidirectional (both sides of the decision visible), and it lands as an action, not a topic page.
Why do you need it?
- Topic-dashboards serve perusal; decision-reports serve choices.
- A decision has an owner and a deadline — naturally forces scope.
- Showing both sides (buy vs hold) keeps the story honest.
- Senior-analyst work is turning firehoses into decide-now pages.
Mental model
A grocery list vs a tasting menu vs a surgeon's consent form
Decision support
Supermarkets show everything (metric walls); decision support is the consent form — the single choice, its risks, its options, and the recommendation in one sheet. Nobody wants forty options on consent; they want the one decision framed. Decision reports frame one choice perfectly.
How it works
- Name the decision: owner, deadline, go/no-go axes.
- Inputs with thresholds: the few metrics that tip the scale.
- Alternatives: two-plus modeled options with expected outcomes.
- Recommendation + confidence: computed or authored, with assumption list.
- Action plan: who does what if the decision lands either way.
A decision report's anatomy.
Examples
The go/no-go launch decision frame
DECISION Launch US pilot by Feb 15? (owner: GPM)INPUTS readiness 74% (gate 80% -> RISK) forecast 6.2k users (model band 5.3-7.1k) margin preview 61% (target >= 60% -> OK)ALTERNATIVES A Launch now -> 6.2k users, 0.44 risk of ramp failure B Shift +1 wk -> 6.9k users, 0.22 risk, -0.8/208 slots C Kill pilot -> budget recovered, cred lost in regionRECOMMENDATION B (shift a week): buys the readiness gate, cost is 0.8 foreseen, upside on ramp.ACTION GPM to sign; PM to rehearse ramp in 5 days.One decision, its gating inputs, three modeled alternatives, a recommendation with confidence, and an owned plan.
In production
- A pricing decision report weighs price × volume against margin and churn.
- A capacity decision report shows ship-now vs week-delay with slots traded for readiness.
- A hiring decision report frames team size vs plan certainty for the next quarter.
Best practices
- Frame one decision per report — the report's name is the decision.
- Show both sides warmly: alternatives must each be defensible.
- State assumptions beneath the recommendation; they own its validity.
- End every report in a plan: owner + step + date either way.
Common mistakes
- Decision report that degrades into a topic dashboard.
- Recommendation without assumptions — 'trust me', without the model.
- Single-alternative reports ('here's the plan') that fake completeness.
- No named owner; the decision floats to next week's meeting.
Debugging tips
- Report read but decision stalls → no deadline/owner on the recommendation.
- Alternatives untrustworthy → assumptions stale; refresh and date them.
- Recommendation flips weekly → input thresholds wobbling; gate the inputs too.
Interview checkpoint
Quick quiz
A decision report should end in:
Decision reports should show only the recommended alternative.