Capacity Planning: What-if demand
Objective. Change one demand assumption and read how far the requirement moves, treating the result as a simulation, not a decision.
The what-if screen answers: how sensitive is our capacity requirement to a change in the demand assumptions? It is the tool that makes buried assumptions visible and testable.
See it in the demo
What this screen answers
The customer question is: if demand were higher or lower - a seasonal surge, a lost client, a volume shift - how much would the requirement change. This is the core of the sales story and the CSM's sensitivity check.
The task
Change a single demand assumption (volume up for an event, a shift in mix) and watch the requirement move. Change one thing at a time so the sensitivity is attributable. The line to deliver: 'the plan is only as good as these assumptions - here is how much the answer moves when one changes.'
How to read it
A what-if is simulated. It shows sensitivity; nothing is executed, committed or staffed. The value is precisely in seeing how far the requirement swings per unit of assumption change - a requirement that moves sharply tells you which assumption to validate hardest. The classic misread is to treat the what-if output as a plan of record or a decision. It is a sandbox for testing assumptions, not an instruction to hire.
Honest limits
A scenario is a sandbox. Turning a chosen scenario into a staffed plan is Scheduling; acting inside the live day is Intraday Management. Confirm the assumption ranges you test against the customer's real operating conditions so the sensitivity is meaningful.
Interpretation check
A what-if is a simulation of sensitivity, not an executed or committed plan; its value is showing how far the requirement moves per assumption.
In the field
For an OVO-style contact centre or a KnackGlobal-scale RCM operation, the what-if is the moment buried assumptions come onto the table - the requirement's sensitivity, not the headline number, is what makes the plan defensible.
Practical task
Run one what-if: change a single demand assumption, record how the requirement moves, and write one line on which assumption that sensitivity tells you to validate first with the customer.
Self-check
A customer wants to act on a what-if result as the new plan. What do you clarify?
A what-if is simulated - nothing is committed or staffed. It shows sensitivity. Turning a scenario into a staffed plan is a separate, owned step in Scheduling.
Why change only one assumption at a time?
So the movement in the requirement is attributable to that assumption - that is what makes the sensitivity readable and tells you which input to validate hardest.
What is the real value of running a what-if in a demo?
It makes buried assumptions explicit and shows the requirement's sensitivity to them, turning a lone spreadsheet number into a defensible, testable requirement.
Verified vs demo. Screen is live in the demo at /#/fcwhatif; exact controls and figures are SME-validation-pending.