Capacity Planning - Evidence-Led Sales Demo
Objective. Give the rep a runnable, evidence-led demo of Capacity Planning using the five-beat structure (question -> screen -> evidence -> interpretation -> next step): the story arc, the exact screens in order with the one value point each, the limitation to state out loud, and the discovery questions the demo answers - all in a form that works live.
This demo proves one thing: Capacity Planning turns a buried, intuition-based headcount guess into a defensible requirement with its assumptions on the table. The arc moves from the customer's current pain (a single number nobody can defend) to a requirement read by skill and interval, to a what-if that shows how sensitive that requirement is, and closes on defensibility to finance. Every beat separates projection from result and simulation from execution. Runnable in roughly seven minutes with two drill-downs and one explicit limitation.
See it in the demo
The story arc
Before: the customer plans capacity in a spreadsheet built on last year's averages and a planner's intuition. The plan is a single number with its assumptions buried, so when it is wrong nobody can see which assumption broke - and they cannot defend the headcount ask to finance.
The turn: Capacity Planning computes a required capacity from stated drivers (volume, standards, shrinkage, service goal), sets it against available capacity, and exposes the gap by skill and interval. Then one what-if shows how sensitive the requirement is to its assumptions.
After: the customer has a number they can take to finance with the drivers behind it, a view of exactly which skill is short at which interval, and a sensitivity test proving the number is not a point guess.
The spine of the demo is the integrity line, said out loud: 'The plan is only as good as these assumptions - so here they are, on the table, and here is how sensitive the answer is to them.' That honesty is the differentiator against a spreadsheet, not a weakness.
The screens in order, one value point each
Run these in sequence (host: capacityplanner.demo.timechamp.io):
- Overview (/#/overview) - value point: 'Here is required capacity against available capacity for the period, and the gap.' Frame the whole story in one screen before drilling in.
- Balancing (/#/balancing) - drill-down 1, value point: 'The gap is not a headline total - it is a specific skill short at a specific interval.' This is the beat that beats a spreadsheet FTE number; read coverage by skill and interval.
- Standards and workforce availability (/#/standards, /#/availability) - value point: 'These are the assumptions behind the number - handling standards and shrinkage - and they are visible and editable, not buried.' Point at shrinkage as the biggest lever.
- Scenarios or what-if (/#/scenarios or /#/fcwhatif) - drill-down 2, value point: 'Change one assumption - a seasonal volume rise or higher shrinkage - and watch the requirement move. The gap between scenarios is the risk you are quantifying.'
- Models and accuracy (/#/fcmodels) - value point: 'The forecast carries its own credibility - here is its backtested accuracy and bias, so you know how much to trust it.'
Use real navigation language ('open balancing', 'compare scenarios'), not invented button labels.
The five beats applied
Map each screen to the five-beat structure so the demo is evidence-led, not a tour:
- Question: 'How do you build your capacity plan today, and can you tell which assumption broke when it is wrong?'
- Screen: Overview, then Balancing.
- Evidence: the required-vs-available gap, and on drill-down the specific skill short at the specific interval - not a net total.
- Interpretation: 'A net FTE balance can still hide a peak-skill shortage. This is coverage, read properly.' Then on the what-if: 'This is a simulation under stated assumptions - it shows sensitivity, it does not hire anyone.'
- Next step: 'Let's take your real volume, standards and shrinkage, build this for one of your queues, and see the requirement you would actually defend to finance.'
Keep each beat tight. The two drill-downs are Balancing (coverage by skill/interval) and the what-if (sensitivity). Everything else is framing.
The limitation to state out loud
Say this plainly, do not let it be discovered: **'Everything you are seeing runs on seeded demo data and the model's logic. The output is only as good as the inputs - your real volume source, your measured handling standards and your true shrinkage. A scenario is a simulation, not an executed plan; a forecast is a projection with error bars; and the accuracy figure is backtested on history, not a guarantee of the next period. Which forecasting method and data source would apply for you is something we confirm with product, not something I will assert in a demo.'
Stating the limitation is the move that makes the rest credible. It also sets up the honest value claim: the deliverable is a better, testable requirement with owned assumptions - not a promise of perfect staffing, and not a cash saving. Keep capacity value separate from cash throughout: a freed-FTE figure is an opportunity the customer decides to realise, not money the plan delivers.
The discovery questions this demo answers
Pair the demo with these discovery questions - the demo exists to answer them, so ask them first and tie each beat back:
- 'How do you build your capacity plan today, and what assumptions sit inside it?' (answered by Standards/Availability).
- 'When the plan is wrong, can you tell which assumption broke?' (answered by Scenarios/what-if).
- 'Do you plan to an FTE total or to skills by interval?' (answered by Balancing - usually the aha moment).
- 'How do you defend a headcount ask to finance today?' (answered by the whole arc - a requirement with visible drivers).
- 'How do you know how far to trust your forecast?' (answered by Models and accuracy).
Qualifying note: against an incumbent WFM tool, ask what it actually does for skills balancing and scenario sensitivity before positioning - do not assume it does neither. Against Excel, the explicit, sensitivity-testable assumptions and skills-in-intervals view are the clear differentiators.
Interpretation check
The demo's job is to prove a defensible requirement, not a guaranteed staffing outcome. Every figure shown is a projection, a simulation, or a requirement under stated assumptions - the rep names which, reads coverage by skill and interval, and states the seeded-data and input-validity limitation out loud.
In the field
An OVO-style contact centre defending a seasonal hiring ask: the Overview shows the gap, Balancing shows a scarce voice skill short at the evening peak that the net total hid, and a what-if on a higher-volume event quantifies the risk finance is being asked to cover - a requirement defensible with its drivers, not a spreadsheet guess. The same arc fits KnackGlobal's claims-staffing case, keeping any cost-per-claim cash claim separate from the capacity figure.
Practical task
Build and rehearse a seven-minute demo script: list the five screens in order with the one value point for each, mark the two drill-downs (Balancing and what-if), write the exact limitation sentence you will say out loud, and pair each of the five discovery questions to the beat that answers it. Run it once against a mock 'just give me the number' objection and a mock 'our FTE is balanced' objection.
Self-check
What is the single idea the demo must prove?
That Capacity Planning turns a buried, intuition-based headcount guess into a defensible requirement with visible, sensitivity-testable assumptions, read by skill and interval - defensible to finance, not a point guess.
Which two drill-downs carry the demo, and what does each prove?
Balancing - the gap is a specific skill short at a specific interval, not a net total (beats a spreadsheet FTE number). What-if/scenarios - changing one assumption shows how sensitive the requirement is, quantifying the risk.
What limitation must the rep state out loud, and why?
That it runs on seeded data and the output is only as good as the real inputs (volume, standards, shrinkage); a scenario is simulated not executed, a forecast is a projection, accuracy is backtested not guaranteed, and the method/source is confirm-with-product. Stating it is what makes the rest credible.
A prospect says 'we already have a WFM tool.' How do you position before the demo?
Qualify what the incumbent actually does for skills balancing and scenario sensitivity before positioning - do not assume it does neither. Lead with explicit, testable assumptions and skills-in-intervals as the differentiators if the incumbent lacks them.
How do you keep the value claim honest when a freed-FTE number appears?
Keep capacity value separate from cash. A freed-FTE figure is an opportunity the customer decides to realise, not money the plan delivers; never present it as a saving.
Verified vs demo. All five screens are live in the demo on seeded data; the requirement-vs-available model, balancing, scenarios/what-if and accuracy views demonstrate the model's logic. A customer's real volume source, forecasting method, measured standards, shrinkage and the accuracy metric are confirm-with-product and must not be asserted in the demo.