✅ Pre-check: lock the base case and define “downside”
Before you run any scenario analysis, you need a base case that’s “frozen” and versioned; otherwise, every downside result turns into a debate about what changed in the baseline. Confirm your time horizon (e.g., next 13 weeks for cash, next 6–8 quarters for plan), your decision context (board update, hiring plan, fundraising, covenant risk), and the specific definition of downside: is it a realistic adverse case, or a near-stress case used for risk management?
Next, list the model outputs that must stay consistent across scenarios: revenue drivers, gross margin logic, headcount plan, working capital behavior, and cash runway. Define “no double-counting” in plain language: each risk driver should have one primary lever (the cause), and downstream impacts should flow from the model, not be manually layered on top.
If you’re collaborating across finance and ops, put light governance around approvals and change tracking so everyone can see what assumptions moved and why. That becomes much easier when your scenario analysis tool supports audit trails and scenario comparison views.
🛠️ Step-by-step instructions
Step 1: 🧱 Start with a clean baseline (and don’t touch it)
Duplicate or snapshot your base case and label it clearly (Base / Plan / Budget). From this point forward, treat it as read-only. Then create a separate downside scenario version where all changes happen through explicit levers (drivers, inputs, or toggles). This is the single biggest protection against double-counting: you can always compare the downside to a stable baseline and see exactly what moved. If your workflow involves multiple reviewers, set a simple rule: every assumption change gets a short note (what changed, why, owner, and date). That’s where using a system with version history and change review can remove the “spreadsheet sprawl” problem that kills credibility in real-time scenario analysis cycles.
Step 2: 🎯 Define risk drivers as causes, not effects
List 5-10 downside drivers in “cause language,” not “outcome language.” Examples: pipeline conversion declines, sales cycle lengthens, renewal uplift compresses, collections slow, or vendor costs rise. Avoid mixing causes with effects (e.g., “revenue down” is an effect; “bookings down 12% due to conversion” is a cause). Then map each driver to one primary lever in the model, one place where the shock is applied. This is where a scenario matrix helps: drivers on the left, levers in the middle, metrics impacted on the right. When you can’t point to the exact lever, you’re at risk of double-counting later by adding “extra conservatism” in multiple spots. If you want a structured way to build that mapping, use a scenario matrix approach.
Step 3: 🧪 Apply shocks sequentially and test the deltas
Apply one driver at a time and check the delta versus base before layering the next shock. This intermediate check is where double-counting gets caught early. For example, if bookings fall, your model should naturally reduce recognized revenue (with the right lag), reduce variable COGS (if applicable), and change cash timing, without you separately forcing revenue down again. The goal is that effects flow from the model’s logic. If you need a second-order impact (e.g., churn increases because support quality drops), treat it as a separate, explicitly justified driver, not as a “safety haircut.” This sequencing is also easier in a scenario analysis software workflow that supports side-by-side scenario views and driver toggles so you can see what each lever contributed.
Step 4: ✅ Run “sanity checks” that expose hidden double-counting
Sanity checks should be metric-based, not vibe-based. Validate that implied unit economics make sense (ARPA/ASP, retention, CAC payback, gross margin), that operating capacity isn’t contradicted (e.g., you cut headcount but still assume the same implementation throughput), and that working capital assumptions match the story (if customers delay payment, your AR days should move, not just cash as a manual plug). Also, check that risk isn’t counted both as a shock and as a response. Example: if the downside includes a pricing drop, don’t also assume a “discounting program” response unless you’ve separated what’s forced versus what’s chosen. A quick way to pressure-test your downside logic is to compare it with a more extreme stress test and confirm the downside is directionally consistent, just less severe.
Step 5: 🧾 Document assumptions and package decisions (not spreadsheets)
A downside case should end with decisions and triggers. Write a short assumption log: driver, lever location, magnitude, timing, and confidence. Then define operational triggers (e.g., pipeline coverage below X, renewal risk above Y) and the actions you’d take (freeze hiring, renegotiate vendor terms, adjust spend gates). Keep mitigations separate from the downside shock so the team can see the “unmanaged downside” and the “managed downside” clearly. This is where tools like Model Reef can quietly improve outcomes: instead of emailing versions around, you maintain a governed set of scenarios, compare outputs instantly, and keep an audit-ready narrative for stakeholders. If you want to see how workflow features support this (versioning, scenario diffs, collaboration), review the product capabilities.
⚠️ Tips, edge cases, and gotchas
The most common double-count is applying the same demand shock twice: once through a bookings/conversion lever and again by manually reducing revenue. Another classic: hitting gross margin directly and also increasing COGS-pick one method and let the model compute the other. Watch for “stacked conservatism” in working capital (slower collections plus a manual cash reduction), and for capacity contradictions (cutting CS headcount while assuming churn improves). Timing also creates hidden duplication: a sales cycle extension already delays revenue; don’t also shift revenue timing independently unless you can explain the mechanism. Finally, avoid mixing downside with response actions in a single set of inputs; separate them so leaders can decide which responses to activate. If you’re evaluating scenario planning tools, look for driver-based levers, scenario comparisons, and clear change tracking so the model itself helps enforce consistency.
đź“Ś Short example
Base case: a B2B SaaS company plans $12M ARR, stable retention, and improving gross margin as onboarding efficiency rises. Downside driver: pipeline conversion drops due to a category slowdown. Apply a single lever: reduce new bookings by 15% for two quarters, with a gradual recovery. The model should naturally lower revenue (with the correct recognition lag) and reduce variable costs tied to delivery volume. Now sanity-check: if churn is unchanged, don’t also reduce ARR again “to be safe.” If you believe churn rises, add a separate driver with a clear causal story (e.g., reduced onboarding capacity). Run the scenario and confirm cash runway impact, then prepare a “managed downside” variant where you gate hiring. If you need a refresher on running and comparing scenarios cleanly, follow the tutorial flow.
🚀 Next steps
If your downside case takes days to rebuild, it won’t survive contact with reality. Convert your downside into a driver-based set of levers, document triggers, and keep scenarios versioned so you can run real-time scenario analysis when assumptions change mid-quarter. A platform like Model Reef can help teams collaborate on scenarios without losing governance, so updates are fast, explainable, and stakeholder-ready. If you want the full end-to-end framework, return to the main guide.
Back