Scheduling: Scenarios
Objective. Build and compare scheduling scenarios (for example with and without overtime, or on an alternative forecast) and read the trade-off without treating the winning scenario as an achieved outcome.
Scenarios answer: what if demand, rules or staffing change - how do the options compare before we commit? The key read is that scenarios are simulated comparisons of drafts on stated assumptions, not executed results, and are only comparable when built on the same basis.
See it in the demo
What this screen answers
A Sales or CSM person opens scenarios to answer: before committing, how do alternative plans compare - for example overtime versus open shifts to cover a peak, or the plan under a higher-demand forecast? It supports the 'show one scenario with its assumptions' sales move and the CSM's option review.
The task
Build or open two or more scenarios for the same team and period and compare their trade-offs: coverage of the shortage window, overtime cost, rule exceptions. Name the assumption that distinguishes each one (which forecast, which rule, which lever) so the comparison is honest.
How to read it
Scenarios are simulated comparisons of drafts, not executed outcomes. Each is bound to its own assumptions - forecast version, rules, levers. The disciplined read: compare scenarios only when they share the same forecast version and period, otherwise you are comparing apples to oranges. A 'winning' scenario is a better plan on stated assumptions, not a result you have achieved or published.
Honest limits
A scenario proves nothing about delivery - it is a plan. Picking a scenario does not publish it or make it happen; execution and actual outcome are separate (publication, then RTA and intraday). Confirm with product which assumptions a customer's scenarios can actually vary; the demo uses seeded data.
Interpretation check
A winning scenario is a simulated plan on stated assumptions, not an achieved outcome - and scenarios are only comparable when forecast version and period match.
In the field
A contact centre weighing overtime against posting open shifts to cover a peak: scenarios show the cost/coverage trade-off side by side, on the same forecast, before anyone commits.
Practical task
On the demo, compare two scenarios for one shortage window and write the trade-off in one line, explicitly naming the single assumption that differs between them.
Self-check
Scenario B beats scenario A on coverage. Have we improved service?
No. We have a better plan on B's assumptions. It is not achieved until published and worked; service is confirmed later in RTA and intraday.
When is a comparison between two scenarios misleading?
When they are built on different forecast versions or periods. Then you are comparing apples to oranges - align the basis before comparing.
What must you always name when presenting a scenario?
Its assumptions - which forecast, which rules, which levers. A scenario without its assumptions stated is not an honest comparison.
Verified vs demo. Screen is live in the demo at /#/scenarios; exact controls, labels and figures are SME-validation-pending.