Intraday Management adoption playbook - from reforecast curiosity to a logged, reviewed daily decision loop
Objective. Give a CSM a runnable plan to take a customer from first login to a standing intraday routine, where duty managers detect drift early, simulate options before acting, log the decision and review it against actual at end of day. Adoption here is a behaviour loop, not a feature tour.
IDM is only adopted when the detect - decide - act - review loop becomes a daily habit with a memory. This playbook stages that from a single pilot team to the floor, names the milestone at each stage, calls out the adoption risks specific to a same-day control tower, and ties progress to the measures IDM itself exposes - time to detect and respond, action completion, forecast drift and the service/backlog outcome the customer owns.
See it in the demo
The adoption goal and what 'adopted' looks like
Adopted is not 'managers have logged in'. Adopted is: when the day drifts, a duty manager opens forecast vs actual to confirm it is real and sustained, simulates two options in the what-if, decides, records the decision in the action log with its projection and owner, and comes back at end of day to compare projection against actual. The loop runs without you prompting it, and the end-of-day review is a standing event, not a demo party trick.
The tell that it is working: the customer starts referring to the action log in their own operational meetings - 'we tried the skill move on Tuesday, here is what actually happened'. That means the decision loop now has a memory. The tell that it is not working: managers look at the tower, feel reassured by a green summary, and never move to the decision screens - the classic 'on plan at noon' trap that gives false comfort and no behaviour change.
Staged rollout - pilot, team, scale
Stage 1 - Pilot (one team, one duty manager, 1-2 weeks). Validate inputs first (see the data-setup reference) so the reforecast is trustworthy, then sit with one duty manager through a few live-ish windows. Milestone: at least three real shortages taken through the full loop - detected, two options simulated, decision logged, reviewed at end of day - with the manager, not you, driving by the end.
Stage 2 - Team (the whole team / shift, 2-4 weeks). Make the end-of-day review a standing event owned by the team lead, paired with the action log. Milestone: the review happens on days you are not present, and the log is complete enough (shortage, option, projection, owner) to drive it rather than a scatter of half-entries.
Stage 3 - Scale (multiple teams / the operation, ongoing). Roll the routine to other duty managers using the pilot team's logged history as the teaching material. Milestone: a weekly learning conversation where the operation reviews which interventions actually held across teams, and business rules get tuned (thresholds, cost assumptions) to match reality. Scale is reached when new managers learn the loop from the customer's own logged decisions, not from you.
Top adoption risks and how to counter them
False comfort from the tower. A green summary at noon feels like success and kills the habit of moving to the decision screens. Counter: teach the tower as the detect step only, and make the behaviour you reward 'confirmed on forecast vs actual', never 'looked green'.
Simulation treated as a result. Managers quote a what-if '+5 percent' as if delivered, then lose trust when the day finishes under. Counter: from day one, label every projection as a projection and make the end-of-day review the proof point, so projections are checked rather than believed.
The log goes stale. If logging is optional it decays into half-entries and the review becomes impossible. Counter: make logging the non-negotiable last step of every decision in the pilot, so the habit is set before scale.
Stale feeds silently poisoning trust. If actuals or the staffing picture lag, every screen is wrong with no visible symptom and the customer concludes 'IDM is inaccurate'. Counter: validate feed freshness before go-live and re-check it whenever a manager disputes a figure - the problem is usually the input, not the model.
Attributing the service number to IDM. Overclaiming that IDM delivered the SLA invites a hard question you cannot win. Counter: hold the honest line - IDM improves decision quality and speed and makes it auditable; the service result is the customer's to realise and must be baselined.
Success metrics and review cadence
Watch the measures IDM is designed around, baselined against the customer's own starting point:
- Time to detect and respond - from drift appearing to a decided action. The primary adoption signal; it should fall as the loop becomes habit.
- Action completion - were logged decisions actually carried out (execution is in the customer's systems; the log makes intent visible, the review confirms execution).
- 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, never attributed to IDM alone.
Cadence: daily end-of-day review (team-owned), weekly learning conversation (which interventions held, rule tuning), and a monthly or QBR-level look at the trend in time-to-respond and drift. Keep capacity and decision-quality value separate from any cash claim - confirm with product what, if anything, IDM executes directly versus hands off before you frame completion.
Interpretation check
Adoption of IDM is the detect - decide - act - review loop becoming a daily habit with a memory, not feature usage. A manager who feels reassured by a green tower and never reaches the decision screens is not adopting - and no adoption milestone claims IDM delivered the service number, which the customer owns and must baseline.
In the field
KnackGlobal (RCM, ~6,000 seats): adoption is reached when duty managers on time-sensitive claim queues run the loop themselves - simulate 'overtime vs pull a skill vs hold', log the choice, and review at end of day whether filing deadlines were protected - and the operation's weekly meeting cites the action log, not a promised SLA, as the evidence of what works.
Practical task
Pick one real customer account this month. Write a one-page staged adoption plan for IDM: the pilot team and duty manager, the input-validation checks you will run before go-live, the milestone for each of the three stages, the two adoption risks you judge most likely for this customer and your counter to each, and the baseline you will capture for time-to-respond and the customer-owned service outcome. Name the standing cadence (daily review, weekly learning conversation) and who owns it on the customer side.
Self-check
A customer's managers log in daily and watch the control tower, but never open the what-if or log a decision. Are they adopting IDM?
No. That is the 'on plan at noon' false-comfort trap. Adoption is the full detect - decide - act - review loop becoming habit. Watching the tower is only the detect step; the behaviour that matters is confirming drift, simulating options, logging the decision and reviewing it against actual.
What is the milestone that tells you the pilot stage is complete?
At least a few real shortages taken through the entire loop - detected, two options simulated, decision logged with projection and owner, reviewed at end of day - with the duty manager driving it themselves, not the CSM.
A manager says 'IDM's numbers are wrong, I don't trust it' three weeks in. What is the most likely cause and your first move?
Most likely a stale actuals or staffing feed, or a wrong skill map or cost rule - the model is usually fine, the input is not. First move: re-validate feed freshness and the rule or skill map behind the disputed figure before defending or doubting the number.
Which success measure is the primary signal that the loop is becoming habit, and what must you never attribute to IDM?
Time to detect and respond falling is the primary adoption signal. Never attribute the service or backlog outcome itself to IDM - that is the customer's to realise and must be baselined; IDM improves and evidences the decision, it does not deliver the number.
Why make logging the non-negotiable last step of every decision during the pilot specifically?
Because if logging is optional it decays into half-entries and the end-of-day review becomes impossible. Setting the habit before scale means the log is complete enough to drive learning when the routine spreads to more managers.
Verified vs demo. The detect - decide - act - review screens (tower, forecast vs actual, staffing, what-if, action log, end-of-day review) are demo-shown on seeded data at idm.demo.timechamp.io. What IDM can execute directly versus hand to the customer's systems, alerting entitlement, Copilot scope and actuals-feed latency are production-dependent - confirm with product. Treat every projected figure in the demo as SME-validation-pending.