Intraday Management - is today's plan still viable, and which fix best protects delivery?
Objective. Teach the customer value of Intraday Management (IDM): a control tower that reforecasts the day as actuals diverge from plan and lets a manager simulate corrective actions before committing to one. Learn to explain the line between a simulated improvement and an executed, achieved result.
IDM is the 'now what' layer of workforce management. Capacity Planning set the plan and Scheduling built the roster, but the day never behaves. IDM detects the drift, reforecasts the rest of the day, and lets a manager test fixes - move a break, open VTO, pull a skill - as what-if scenarios, so the chosen intervention is evidence-based rather than a panic reaction.
The customer problem
By mid-morning the plan is already wrong. Arrivals came in heavier than forecast, an outage spiked a queue, or absence ran above shrinkage assumptions. The manager on the floor knows something is off but is working from a static forecast built days ago and a gut feel about what to do. Should they hold overtime, push a skill group, delay a meeting, open voluntary time off, or just ride it out?
In an RCM operation like KnackGlobal or a contact centre like OVO, every one of those choices has a different cost and a different effect on backlog and service level - and the manager cannot see any of them in advance. They pick one, hope, and find out at end of day whether it worked. The problem is not a lack of effort; it is deciding blind, under time pressure, with no way to compare options.
Business impact
Deciding blind is expensive in both directions. Over-react - mass overtime, pull everyone to the hot queue - and you burn cost and strand the queues you drained. Under-react and the backlog compounds into tomorrow's problem, SLA penalties, and in RCM, touches that slip past time-sensitive deadlines.
There is also an accountability cost. Without a record of what was projected, what action was taken and what actually happened, every bad day becomes an argument. Managers cannot learn which interventions work because nothing is logged against outcome. The business keeps paying for the same mistakes because the day-of decision loop - detect, decide, act, review - has no memory and no evidence behind the 'decide' step.
How Time Champ addresses it
IDM is a Control Tower (https://idm.demo.timechamp.io/#/tower) that keeps the day live. Forecast vs actual (https://idm.demo.timechamp.io/#/forecast) shows where today has diverged from plan and reforecasts the remaining intervals. Staffing (https://idm.demo.timechamp.io/#/staffing) shows the resulting gap or surplus by interval and skill.
The core of IDM is the what-if: before acting, the manager simulates a corrective action and sees its projected effect on coverage, backlog and cost. Options can be compared rather than guessed. Alerts flag drift early; an action log captures what was decided and by whom; an end-of-day review closes the loop by comparing the projected effect against the actual outcome. A Copilot assists the read. Confirm with product which alerting, action-execution and Copilot capabilities are entitled for a given customer - the demo shows the decision model end to end on seeded data.
What to say / do
Sales - projected shortage, then a simulated fix. Open the Control Tower and let the shortage show itself on Forecast vs actual. Ask: 'When the day goes sideways, how does your duty manager decide between overtime, VTO, skill moves or holding? And how do they know, before they commit, which one protects service best?' Then run a what-if and show the projected effect of two different actions side by side. Be explicit about the boundary: 'This simulates and recommends - executing the staffing change still happens in your systems and within your policy.' That honesty is what makes the capability credible.
CSM - run a real intraday review. Validate the inputs first: is the arrival/actuals feed fresh, is the staffing picture current, which skills are genuinely available, and what cost and policy rules constrain the options. Then sit with a duty manager during a live-ish window, simulate two or three options on a real shortage, document the chosen action in the action log, and - the step that builds trust - come back at end of day to compare projected versus actual. Make the action log plus the end-of-day review the customer's standing routine.
Measurable value
Value is a faster, evidenced decision loop. Measures to agree and baseline:
- Time to detect and respond - from drift appearing to a decided action. IDM is designed to shorten this.
- Action completion - were the decided actions actually carried out (the log makes this visible).
- Forecast drift - how far actual ran from plan, and whether reforecasting caught it earlier over time.
- Service/backlog outcome - the business result the customer owns, tracked against the end-of-day review.
The honest framing: IDM improves the quality and speed of the decision and makes it auditable. It does not by itself deliver the service number - the customer's execution does. The value you can stand behind is 'better decisions, made earlier, with a record' - the service improvement is the customer's to realise and must be baselined, not promised.
Objections and honest limits
'We already reforecast in a spreadsheet.' Ask how long it takes, whether it compares options before acting, and whether anyone can reconstruct later what was decided and whether it worked. The spreadsheet gives a number; IDM gives a compared, logged, reviewed decision.
'Does it automatically fix the day?' No - and say so plainly. IDM simulates and recommends; the actual staffing change executes in the customer's systems within their cost and policy rules. Overstating this is the fastest way to lose credibility.
Honest limit - the interpretation check: a simulated improvement is not an executed action, and an executed action is not an achieved service result. A what-if showing '+4 percent coverage' is a projection on current assumptions. Treat it as decision support, not an outcome. Confirm with product what, if anything, IDM can trigger directly versus hand off, and the freshness of the actuals feed.
Interpretation check
A simulated improvement is not an executed action, and an executed action is not an achieved service result. The what-if projection is decision support on current assumptions - never present a simulated '+X percent' to a customer as a delivered outcome.
In the field
KnackGlobal (RCM, ~6,000 seats): an intraday spike on a time-sensitive claim queue is exactly where simulating 'overtime vs pull a skill vs hold' before committing protects both cost and filing deadlines. OVO (contact centre): arrival volatility during the day is the classic IDM case - comparing corrective options beats the duty manager's gut call.
Practical task
On the demo, find a shortage on Forecast vs actual, simulate two different corrective actions (for example overtime vs a skill move), and write a one-page intraday decision note: the detected drift, the two options with their projected effects, the option you would choose and why, the explicit boundary on execution, and the end-of-day review you would run to check the projection. Label every projected number as a projection.
Self-check
A manager runs a what-if that projects +5 percent coverage if they open overtime. What have they proven, and what have they not?
They have a projection on current assumptions that overtime should help coverage - decision support. They have not executed the action, and they have not achieved a service result. Both of those come after, and must be reviewed against actual.
Where does Intraday Management sit relative to Capacity Planning and Scheduling?
Capacity Planning sets the plan, Scheduling builds the roster, IDM manages the day when reality diverges from both - detect drift, reforecast the rest of the day, simulate and decide the corrective action.
Why does the action log plus end-of-day review matter more than the simulation itself?
They give the decision loop a memory - what was decided, by whom, and whether the projection held. Without them managers cannot learn which interventions actually work, so the business keeps repeating the same bad days.
A prospect asks 'so it runs the day for us automatically?' What is the honest answer?
No. IDM detects, reforecasts, simulates and recommends; the actual staffing change executes in the customer's systems within their policy and cost rules. Confirm with product exactly what it can trigger versus hand off.
What inputs must a CSM validate before IDM's reforecast is trustworthy?
Freshness of the arrival/actuals feed, currency of the staffing picture, which skills are actually available, and the cost/policy rules that constrain the options. Stale actuals make the reforecast and every what-if wrong.
Verified vs demo. The control tower, forecast-vs-actual reforecasting, staffing gap view, what-if simulation, action log and end-of-day review are demo-shown on seeded data. What IDM can execute directly versus hand to the customer's systems, alerting specifics, Copilot behaviour and actuals-feed latency are production-dependent - confirm with product.