Capacity Planning: Scenarios
Objective. Drive the scenarios screen to compare alternative assumption sets and explain that a scenario is a simulation under stated assumptions, not a committed or executed plan.
Scenarios let you hold alternative assumption sets side by side - a base case and variations on volume, shrinkage or service goal - so the customer can see how sensitive the requirement is and choose a plan with its assumptions visible.
See it in the demo
What this screen answers
A Sales or CSM person opens this to answer 'what if we are wrong about the assumptions?' Instead of one buried number, scenarios make the requirement a function of stated inputs. This is the core sales move: change a single assumption and show the requirement move, turning a spreadsheet guess into a defensible, testable number.
The task
Start from a base case, then view a variation that changes one assumption (volume up for a seasonal event, or higher shrinkage) and compare the required capacity. Say the integrity line: 'the plan is only as good as these assumptions - here they are, and here is how sensitive the answer is.' Describe actions as 'compare scenarios', not invented button labels.
How to read it
A scenario is a simulation, not a commitment. The 'best' scenario is only best under its own assumptions; nothing on this screen is hired, scheduled or executed. The misread is treating a chosen scenario as an approved plan or an achieved outcome. Read the assumption deltas between scenarios, not just the headline FTE difference - the gap between scenarios is the risk you are quantifying.
Honest limits
Scenarios prove sensitivity, not reality. They do not validate that any assumption set is the customer's true figure - that is the CSM input-validation job. Execution (hiring, scheduling) happens elsewhere. Confirm with product how scenarios are stored and whether a scenario can be promoted to an approved plan for a customer.
Interpretation check
A scenario is a simulated requirement under stated assumptions - it is not hired, scheduled or executed, and the 'best' scenario is only best if its assumptions hold.
In the field
Defending a hiring ask to finance: showing base vs high-volume scenarios proves the number is sensitivity-tested, not a point guess - the difference between the two is the risk finance is being asked to cover.
Practical task
Build or open a base case and one variation that changes a single assumption; capture the requirement in each and write one line stating which assumption drove the difference and by how much.
Self-check
A stakeholder says 'approve scenario B, that's our plan.' What is the honest framing?
Scenario B is a simulation under its assumptions. Selecting it does not hire or schedule anyone; confirm whether and how it is promoted to an approved plan, and validate its assumptions first.
Why change only one assumption at a time?
To isolate sensitivity - you learn how much the requirement moves per driver. Changing several at once hides which assumption is responsible for the swing.
What is the real deliverable of a scenario comparison?
The sensitivity itself - how much the requirement depends on volume/shrinkage/service goal - which is what makes the final number defensible, not the single FTE figure.
Verified vs demo. Screen is live in the demo at /#/scenarios; exact controls and figures are SME-validation-pending.