Intraday Management data and setup - what IDM needs before its reforecast and what-if can be trusted
Objective. Map the signals, configuration and upstream dependencies IDM relies on to produce a correct same-day picture, and give a CSM a clear list of what to validate before trusting any reforecast, staffing gap or what-if, and what to escalate to the implementation specialist.
IDM is a same-day control tower, and every figure it shows is only as good as the live feeds and the rules behind it. A stale actuals feed, a wrong skill map or an unvalidated cost rule corrupts the reforecast, the staffing gap and every simulation with no visible symptom on the day-of screens. This reference lists what IDM depends on, the setup it needs, where it inherits from Capacity Planning and Scheduling, and the CSM validation and escalation line.
See it in the demo
The data and signals IDM depends on
IDM reforecasts the day by comparing a plan against live reality, so it needs both sides fresh:
- A live actuals / arrival feed - what volume actually arrived and what the queues are doing, interval by interval. This is the single most load-bearing input; if it lags, the reforecast and every what-if are wrong at the root.
- A current staffing picture - who is actually present, on what, right now, so 'available' reflects reality rather than the published roster.
- The plan to compare against - the volume forecast and required-capacity assumptions that IDM measures drift from.
- The published schedule / roster - the baseline of who was expected where, so staffing can compute a gap by interval and skill.
- A skill map - which people can genuinely work which queue, so 'available' and any simulated skill move are real.
- Cost and policy rules - the rates and constraints that make what-if costs and allowed actions meaningful.
Treat actuals freshness as the first question in any accuracy conversation. The exact feed mechanism, latency and refresh cadence are production-dependent - confirm with product and the customer's own integration setup.
Setup and configuration required
Described at app-logic level - confirm specifics with product and the implementation specialist:
- Hierarchy and skills must reflect the real operational structure and who can work which queue. This is the silent foundation: a stale skill map makes 'available', the staffing gap and every what-if wrong with no symptom on the day-of screens.
- Business rules - alert thresholds, cost assumptions and policy constraints (overtime limits, VTO rules) - must match the customer's actual policy and rates. Every alert, what-if cost and allowed action downstream is 'true given these rules', so wrong defaults silently distort what managers see and decide.
- Scope and time zone - views must be scoped to the right teams and the operation's time zone, or intervals and 'today' misalign.
- Entitlement-dependent features - alerting, Copilot and what IDM can execute directly versus hand off are packaging- and production-dependent. Do not assume; confirm what a given customer's plan includes.
Dependencies on other applications
IDM is the 'now what' layer of workforce management and inherits from the apps upstream of it:
- Capacity Planning sets the volume forecast and required-capacity assumptions IDM measures drift against. If the plan was built on weak forecasting or wrong handling standards, IDM's 'drift' is partly drift from a bad plan - confirm the plan is sound before blaming the day.
- Scheduling provides the published roster that staffing compares available against required. A reforecast read against a stale or superseded schedule version misstates the gap.
- Real-Time Adherence is the adjacent live view - whether people are doing the planned activity. IDM asks the next question: given where the day is heading, what should we change. Keep the two distinct: adherence is 'are they on plan', IDM is 'is the plan still viable and what fix protects delivery'.
These are app-logic dependencies; the exact integration and data-sharing specifics are production-dependent - confirm with product.
What a CSM validates, and what to escalate
Validate before trusting any IDM number:
- Actuals / arrival feed freshness - is it live and complete, and what is its latency? This gates everything.
- Staffing picture currency - does 'available' reflect who is actually present now, not the planned roster.
- Skill map accuracy - are the right people marked able to work each queue (test one simulated skill move against reality).
- Plan and schedule version - is IDM reading against the current forecast and the published, not superseded, roster.
- Business rules realism - do alert thresholds avoid noise and real-miss, and do cost assumptions and policy constraints match the customer's actual rates and rules.
- Scope and time zone - correct teams, correct day boundary.
Escalate to the implementation specialist / product: feed latency or integration behaviour, how skills are modelled and how changes propagate, exact cost-model fields and whether policy is enforced or advisory, entitlement of alerting and Copilot, and anything about what IDM can trigger directly versus hand off. Never guess on integration, execution boundaries or entitlement - confirm or escalate.
Interpretation check
Every IDM figure is 'true given fresh feeds and these configured rules' - a stale actuals feed, a wrong skill map or an unvalidated cost rule corrupts the reforecast, staffing gap and every what-if with no visible symptom on the day-of screens. Validate the inputs before trusting or defending any number.
In the field
KnackGlobal (RCM, ~6,000 seats): at that scale an out-of-date payer-skill map makes every staffing gap and skill-move simulation unreliable, so validating the skill structure and the actuals feed is the first CSM job before any reforecast is trusted - not an afterthought.
Practical task
For a real or seeded account, write the IDM pre-trust validation checklist: for each of the six validation items (actuals freshness, staffing currency, skill-map accuracy, plan/schedule version, business-rules realism, scope/time zone) write the one question you would ask the customer or specialist and the symptom you would expect if it were wrong. Mark clearly which three items you cannot answer yourself and would escalate.
Self-check
Which single input is the most load-bearing for IDM's accuracy, and why?
The live actuals / arrival feed. IDM reforecasts by comparing plan against live reality; if actuals lag or are incomplete, the reforecast and every what-if built on it are wrong at the root, and the day-of screens show no symptom of the lag.
A customer's staffing screen shows a skill as covered, but the fix fails in reality. What setup dependency likely broke, and is it visible on the day-of screen?
The skill map - someone marked able to work the queue who is not. It is silent: the staffing and what-if screens show no symptom, so the figure looks trustworthy while being wrong. It is validated in hierarchy and skills, not on the day-of view.
IDM is flagging large 'drift' against plan. Before concluding the day went wrong, what upstream dependency should you check?
Capacity Planning's forecast and handling standards. If the plan was weak, part of the 'drift' is drift from a bad plan, not a bad day. Confirm the plan is sound, and that IDM is reading the current forecast and published schedule version, before interpreting the gap.
A what-if shows overtime costing a specific amount. What must a CSM validate before treating that as the real cost?
The cost assumptions in business rules against the customer's actual rates. The figure is 'true given the configured cost model'; if the rates differ it is wrong. Cost-model fields and whether policy is enforced or advisory are escalation items - confirm with product.
Name two things a CSM must escalate rather than answer, and the rule behind the line.
Any two of: feed latency / integration behaviour, how skills are modelled and propagate, exact cost-model fields, enforced-vs-advisory policy, alerting or Copilot entitlement, and what IDM can trigger directly versus hand off. The rule: never guess on integration, execution boundaries or entitlement - confirm or escalate.
Verified vs demo. The staffing, business-rules, hierarchy-and-skills and forecast screens are demo-shown on seeded data at idm.demo.timechamp.io. Feed mechanism and latency, how skills are modelled and propagate, exact cost-model fields, enforced-vs-advisory policy, and alerting / Copilot / direct-execution entitlement are production-dependent - confirm with product and the implementation specialist.