Intraday Management: What-if
Objective. Simulate a corrective action and compare its projected effect on coverage, backlog and cost against another option - while treating every projected number as a projection, not a delivered outcome.
The what-if is the core of IDM: before acting, the manager tests a corrective action and sees its projected effect, so options can be compared on evidence rather than guessed under time pressure.
See it in the demo
What this screen answers
'Before I commit, which fix best protects delivery - and at what cost?' This is where the duty manager stops guessing. Having seen the gap and shortlisted actions, they simulate each one and read the projected effect on coverage, backlog and cost, then compare side by side to choose the intervention with the best trade-off.
The task
Scope to the shortage, simulate a first action - for example open overtime - and read its projected effect. Then simulate an alternative - for example a skill move - and compare the two on the dimensions that matter: coverage recovered, backlog impact and cost. Pick the option with the best trade-off for this operation's priorities, and carry that decision into the action log. The task is comparison, not a single blind bet.
How to read it
Every figure here is a projection on current assumptions. A what-if showing '+4 percent coverage' is what the model expects if arrivals, handling and shrinkage behave as assumed and the action is actually executed - it is not an achieved result. The three-step honesty chain: a simulated improvement is not an executed action, and an executed action is not an achieved service result. Never present a simulated number to a customer as something delivered. Stale actuals make every simulation wrong at the root.
Honest limits
The what-if simulates and recommends; it does not execute. Its projections inherit the freshness and accuracy of the feeds and the correctness of the cost and skill assumptions - confirm actuals-feed latency and the cost model with product and the customer's own rules. Exact simulation controls, the cost basis and the demo figures are SME-validation-pending.
Interpretation check
A what-if result is a projection on current assumptions - a simulated improvement is not an executed action, and an executed action is not an achieved service result. Never quote a simulated '+X percent' to a customer as delivered.
In the field
OVO (contact centre): comparing 'overtime vs skill move' in a what-if before committing beats the duty manager's gut call on a volatile afternoon - provided the result is read as a projection to be reviewed, not a promise.
Practical task
On the demo, simulate two different corrective actions for one shortage, record each option's projected coverage, backlog and cost effect, state which you would choose and why, and label every number as a projection.
Self-check
A what-if projects +5 percent coverage if overtime is opened. What has the manager proven?
Only that, on current assumptions, overtime should help coverage. It is decision support. Nothing has been executed and no service result has been achieved - both come later and must be reviewed against actual.
Why simulate two actions instead of one?
To compare trade-offs - coverage recovered, backlog impact and cost differ by option. Comparison is the whole point of the what-if; a single simulation just replaces one guess with another.
What invisibly undermines every what-if projection?
A stale or inaccurate actuals feed, plus wrong cost or skill assumptions. The simulation is only as good as its inputs - confirm feed freshness and the cost model before trusting a projection.
How should a simulated number appear in a customer-facing note?
Explicitly labelled as a projection on current assumptions, paired with the execution boundary and the end-of-day review that will check it against actual. Never as a committed or delivered figure.
Verified vs demo. Screen is live in the demo at /#/whatif; exact simulation controls, cost basis, actuals-feed latency and figures are SME-validation-pending.