Every FP&A team I've worked with does scenario planning. The question is never whether to do it — it's whether the scenarios they build actually help anyone make a decision, or just produce a set of numbers that the board nods at and immediately sets aside.
The problem isn't commitment or effort. Most FP&A teams spend enormous energy on their quarterly scenario packages. The problem is structural: the traditional base/upside/downside framework is a narrative convenience, not an analytical tool. It bundles together dozens of independent assumptions into three tidy rows, which makes it fast to present but nearly impossible to interrogate.
This guide covers how to move from that static, narrative-driven approach to a driver-based model that can actually answer follow-up questions — because that's where board conversations go wrong.
Why the Base/Upside/Downside Model Breaks
Consider what the classic three-scenario pack actually represents. You have a "base case" built on last quarter's actuals plus a set of largely intuitive adjustments. The "upside" typically means the sales team hits quota and nothing goes wrong with headcount. The "downside" usually means a uniform haircut — say, 15% — applied across all revenue lines.
The board asks: "What if we lose our two largest accounts?" The model can't answer that, because gross churn by account tier isn't a discrete driver anywhere in it. You'd need to go back and rebuild a scenario from scratch. That process takes two days. By the time you have the answer, the conversation has moved on.
The deeper structural problem is that most spreadsheet-based scenario models are output-first — they were built by copying last year's budget, adjusting line items manually, and presenting the result. There's no causal chain connecting a driver (say, sales rep headcount) to a revenue outcome. When a driver changes, someone has to manually propagate that change through 15 linked workbooks. Version control breaks. The model becomes opaque.
We're not saying base/upside/downside is bad as a communication format. At the board level, three scenarios with clearly labeled narratives remain a readable, decision-useful structure. The issue is using that same three-row structure as the modeling architecture rather than as a final presentation layer on top of a driver-based engine.
The Driver-Based Planning Model: Structure First
Driver-based planning starts from the opposite direction: identify the handful of variables that actually determine your financial outcomes, parameterize them explicitly, and build the model so that any combination of driver values produces a valid P&L, balance sheet, and cash flow statement.
For a mid-market SaaS company, the core driver set typically looks something like this:
- Revenue drivers: Beginning ARR, new bookings (split by segment), expansion ARR rate, gross churn rate by cohort, average contract start month
- Headcount drivers: Starting roster from HRIS, planned hires by role and quarter, attrition rate by department, average ramp period to full productivity
- Cost drivers: Fully-loaded cost per employee by band, COGS per customer as a function of infrastructure unit costs, variable marketing spend as a percentage of new pipeline target
Once you've mapped these drivers explicitly and connected them to your three-statement model, scenario planning changes character entirely. A scenario isn't a new set of manually entered P&L numbers — it's a named configuration of driver values. You can run as many scenarios as you need in the time it used to take to build one.
Building the Scenario Tree
The scenario tree is the organizing structure that makes driver-based planning practical. Instead of three isolated cases, you work with a branching hierarchy of conditional assumptions.
At the top level, you define your macro assumptions — the variables that have the widest downstream impact and the highest uncertainty. These tend to be things like annual new ARR target, gross churn rate assumption, and headcount plan trajectory. For each of these, you define a range of values corresponding to different states of the world.
Below that, you define dependent assumptions that vary based on the macro state. If gross churn is elevated (say, running at 14% annualized vs. a target of 8%), then you'd expect net revenue retention to compress, expansion bookings to slow as the customer success team gets stretched, and potentially marketing spend to shift toward new logo acquisition. Those secondary effects need to be wired into the tree, not bolted on manually after the fact.
A well-constructed scenario tree for a 150-person mid-market software company might have:
- 4–6 top-level macro driver dimensions
- 3–4 named branches per dimension (conservative, base, optimistic, stress)
- A set of pre-built "scenarios" that select a specific branch from each dimension
- The ability to mix and match branches for ad-hoc sensitivity analysis
This sounds complex, but the key is to build the tree incrementally. Start with the two or three drivers that explain 80% of your revenue variance — for most SaaS businesses that's new ARR and gross churn — and add dimensions as your analytical maturity grows.
Connecting ERP and CRM Data to the Model
The biggest practical obstacle to driver-based planning isn't the modeling architecture — it's data. Your revenue drivers live in your CRM (pipeline by stage, average deal size, close rates, expansion opportunities). Your headcount drivers live in your HRIS (current roster, comp bands, planned start dates). Your actuals flow through your ERP (GL trial balance, AP/AR aging, departmental expense detail).
In a spreadsheet-based workflow, getting all of that into the model requires manual exports: a GL trial balance from NetSuite, a headcount roster from Workday, a pipeline summary from Salesforce. Each export is a point-in-time snapshot. By the time you've assembled the three exports, updated the assumptions, and rebuilt the model, you're typically working with data that's 1–2 weeks old. In a volatile quarter, that lag is significant.
The shift to a live-connected model means those data pulls happen automatically at whatever refresh cadence you configure — daily, weekly, or on-demand before a critical meeting. The model stays current without the assembly process, and when assumptions change, you're changing driver inputs rather than editing cells.
A Practical Example: Stress-Testing a Headcount Freeze
Take a mid-size distribution company's FP&A team working through their Q3 2024 planning cycle. Their CFO has signaled that the board wants to understand the financial impact of a 90-day headcount freeze before approving the full-year plan. In a traditional spreadsheet model, that analysis would require someone to manually edit the hiring plan across five departmental tabs, recalculate all downstream compensation expense, adjust the employer burden and benefits lines, recheck the headcount-linked COGS assumptions, and then rebuild the three-statement output.
In a driver-based model with the headcount plan as an explicit driver dimension, the same analysis takes about 20 minutes: change the "hiring pace" branch from "plan" to "freeze," verify that the attrition assumptions still look right, review the output. The resulting scenario shows exactly what a 90-day freeze does to operating expenses, how it affects the fully-loaded cost per customer as headcount-linked infrastructure costs shift, and what the runway implication is at the current burn rate.
That's not just faster. It's a qualitatively different conversation — one where the CFO can see the specific mechanisms driving the outcome, not just a revised bottom-line number.
The Counterpoint: When More Scenarios Isn't Better
Driver-based planning can generate scenarios faster, which creates its own problem: model proliferation. Teams that get comfortable building new scenarios quickly sometimes end up presenting 8–10 cases to the board, each with marginally different driver assumptions. The result is decision paralysis rather than clarity.
The discipline here is scenario curation. Your scenario tree should be able to generate many configurations, but your board package should present only the 3–4 scenarios that bracket the realistic decision space. The value of driver-based planning is that you can run the eighth scenario if someone asks, not that you should present all eight by default.
There's also an assumption maintenance burden that scales with model complexity. Every driver you add to the tree is an assumption that needs to be reviewed when conditions change. A model with 40 active driver dimensions and stale assumptions in 12 of them is less useful than a simpler model where every assumption is current and defensible.
Getting Started Without a Clean-Sheet Build
Most FP&A teams can't stop running the quarter to rebuild their model from scratch. The practical path is incremental: identify the two or three drivers that account for most of your forecast variance, pull those out of your existing model as explicit parameterized inputs, and start running scenario branches on just those variables.
You don't need to overhaul your entire model to get most of the benefit. Externalizing your gross churn rate, your top-of-funnel conversion assumption, and your headcount ramp period as explicit scenario variables — and wiring those to your revenue and expense lines — gets you 70% of the analytical value of a fully driver-based architecture.
From there, the natural next step is connecting those driver inputs to live data sources so that your actuals-vs-plan comparison happens automatically rather than through manual export. That's when the two-week spreadsheet marathon genuinely goes away — not because the analysis gets simpler, but because the data assembly that currently dominates the process gets automated.
The goal is a model that can answer the next question in the room, not just confirm the narrative you built before the meeting.