Scheduling - Evidence-Led Sales Demo
Objective. Run a live, evidence-led Scheduling demo on the five-beat pattern - show a shortage window, then planning, optimization and publication as distinct steps - so the prospect sees that a schedule is a plan against a forecast, not a promise of a perfect day.
This is the runnable demo script for Scheduling. It follows the five-beat pattern (question, screen, evidence, interpretation, next step), shows a concrete shortage window and then separates planning, optimization and publication as distinct steps, and states the one limitation out loud so the story stays honest. It is built to run live on schedules.demo.timechamp.io against the seeded W42 week.
The story arc
The arc proves one thing: Scheduling turns a staffing requirement into interval-level coverage you can trust, built within the customer's rules and published as one acknowledged version - and it is honest about where the plan ends and reality begins.
Open with the business question, not the tool: 'Having the right total headcount does not mean the right people are on at the right time. How do you build the roster today, and when do you find out about coverage gaps?' Then walk the three distinct steps - plan, optimise, publish - landing each on evidence and one interpretation. Close by handing the live day to Real-Time Adherence and Intraday Management, which is the honest boundary and the natural expansion conversation.
Keep the spine explicit throughout: a schedule is a plan against a forecast; the coverage you show is planned, not actual; Generate/Optimise produces a draft bound by the rules you set; a published schedule is a commitment still subject to real-world change.
The screens in order, with the one value point each
Run these in sequence. One value point per screen - resist touring every feature.
- Overview (https://schedules.demo.timechamp.io/#/home) - frame the question and the W42 week. Value point: 'This is a plan against a forecast; let me show you where the plan breaks.'
- Schedule planner (https://schedules.demo.timechamp.io/#/planner) - Beat 1, planning. Point to a concrete shortage window - the interval where required exceeds scheduled. Value point: name the gap plainly, 'the 2pm peak is short, even though the daily total looks fine.'
- Coverage (https://schedules.demo.timechamp.io/#/coverage) - sharpen the evidence. Value point: read coverage by interval, not the daily total - the peak is where service succeeds or fails.
- Optimization (https://schedules.demo.timechamp.io/#/optimize) - Beat 2. Run it and show the before/after: shortage shrinks, overtime falls, rules respected. Value point, said out loud: 'optimization reshapes the draft against your rules and cost - it does not change the forecast underneath, and the result is still a draft.'
- Publication (https://schedules.demo.timechamp.io/#/publish) - Beat 3. Publish one version with an audit trail and portal acknowledgment. Value point: 'a draft is not live until it is published - now there is one version employees act on, and they acknowledge it.'
Optional, if the room asks 'what about trade-offs / change?': Scenarios (/#/scenarios) for overtime-versus-open-shifts, or the employee portal / requests for how change is owned.
The interpretation to land at each beat
Evidence without interpretation is a feature tour. At each beat, state the reading:
- After the planner/coverage: 'The gap is planned - required from the forecast versus what we have scheduled. It is interval-level, which is why a full daily total can still miss the peak.'
- After optimization: 'This is a better draft on the inputs we gave it. It respected the rules while cutting the shortage and overtime - but it is a step, not magic, and it did not touch the forecast.'
- After publication: 'Now it is a commitment - one live, acknowledged version with an audit trail. It is still subject to real-world change, which is the next conversation.'
The through-line the buyer should leave with: trustworthy coverage comes from the right forecast plus the right rules plus a clean publication, in that order - not from a clever optimiser alone.
The limitation to state out loud
State this plainly, once, and it strengthens credibility: 'What you are seeing is the plan. Coverage here is planned against the forecast - it is not a record of who actually worked or whether the work got done. That is Real-Time Adherence and, for the live day, Intraday Management. And this runs on seeded demo data; your supported labour rules, integrations, time-zone handling and publication controls we confirm with product.'
This does two jobs: it is honest, and it sets up the expansion story (Scheduling plans, RTA and Intraday manage the live day) instead of overpromising a perfect day from a scheduling tool.
The discovery questions this demo answers
Pair the demo with discovery so it lands on the prospect's actual pain:
- 'How do you build rosters today, and when do you discover coverage gaps - before the day or during it?'
- 'How do you know a schedule respects your labour rules before it goes out?'
- 'How do employees know which version is live, and how do they request changes?'
- 'Do you build against a current demand forecast, or last period's pattern?' (sets up the forecast-version point)
- 'When the day diverges from plan, who re-plans it and how?' (hands off to Intraday/RTA)
Next step to propose: a customer-owned pilot on one team and one period - build, optimise and publish against their live forecast - with success defined as coverage by interval, cleared violations, acknowledgment and publication notice. Separate any capacity/cost framing from a cash claim.
Interpretation check
The demo wins by separating three distinct steps - plan, optimise, publish - and stating the boundary: coverage is planned against a forecast, optimization reshapes a draft without changing the forecast, and a published schedule is a commitment still subject to real-world change handled by RTA and Intraday.
In the field
For an OVO-style contact centre, the demo lands on their pain directly: the planner exposes the afternoon billing-query peak a spreadsheet's daily total hid, optimization cuts the weekend overtime within rest rules, and publication gives one acknowledged version - then RTA and Intraday own the live day.
Practical task
Run the five-beat demo live on the seeded W42 week end to end in under eight minutes: frame the question, show the shortage window (planner/coverage), run optimization with the before/after, publish one acknowledged version, and state the limitation out loud. Then write the two discovery questions you would ask this specific prospect and the pilot next step you would propose.
Self-check
What is Beat 1 and what single thing must you show?
Planning, on the schedule planner - a concrete shortage window where required exceeds scheduled at an interval. Name the gap plainly rather than touring the planner.
What must you say out loud when you run optimization?
That it reshapes the draft against the rules and cost you set, does not change the forecast underneath, and leaves a draft - a step, not magic.
What is the one limitation to state during the demo?
Coverage is planned against the forecast, not a record of actual delivery - adherence is RTA and the live day is Intraday - and the demo runs on seeded data with customer rules/integrations confirmed with product.
Why show coverage by interval rather than the daily total?
Because demand is not flat - a full daily total can still miss the peak interval, which is exactly where service breaks. The interval view is the sharpest evidence of the problem.
What next step does this demo set up?
A customer-owned pilot on one team/period against their live forecast, with success measured as coverage by interval, cleared violations, acknowledgment and publication notice - capacity framing kept separate from cash.
Verified vs demo. The overview, planner, coverage, optimization, publication, scenarios and portal are live in the demo on seeded data; exact controls, labels and figures are SME-validation-pending. Supported labour rules, integrations, time-zone handling and publication controls for a customer are confirm-with-product.