Intraday Management troubleshooting - when the numbers look wrong, coverage seems off, or a customer disputes a figure
Objective. Give a CSM a symptom-first diagnosis guide for IDM: the likely cause of each common problem, the first checks to run, and the line where you stop and escalate to the implementation specialist or product rather than guess.
Most IDM problems are input problems wearing a model's clothes. A same-day control tower is only as good as its live feeds and configured rules, and the dangerous failures are silent - a stale skill map or a lagging actuals feed shows no symptom on the day-of screens while corrupting every figure. This guide works symptom by symptom: numbers look wrong, coverage gaps, a disputed figure - each with likely cause, first checks and escalation line.
See it in the demo
Symptom: numbers look wrong or missing
Likely causes (in order of probability):
- A stale or incomplete actuals / arrival feed - the single most common root cause. The reforecast and every what-if inherit it, with no visible symptom of the lag.
- A stale staffing picture - 'available' reflects the planned roster, not who is actually present.
- IDM reading against the wrong plan or a superseded schedule version.
- Scope or time-zone misconfiguration - intervals or 'today' misaligned, so figures look wrong because they describe the wrong window.
First checks a CSM runs: confirm the actuals feed is live and complete and ask its latency; confirm the staffing picture is current; confirm IDM is reading the current forecast and the published (not superseded) roster; confirm scope and time zone. Re-check the figure after each - the symptom usually clears once the feed or scope is corrected.
Escalate when: the feed is confirmed fresh and scope is correct but the figure is still wrong, or the issue is feed latency / integration behaviour itself. Feed mechanism and latency are production-dependent - escalate to the implementation specialist, do not guess.
Symptom: coverage gaps the customer did not expect (or expected and does not see)
Likely causes:
- Reading coverage as a net total - a balanced shift total hides a severe interval or skill shortage next to an idle surplus. This is a reading error, not a system fault.
- A stale or wrong skill map - people marked able to work a queue who are not, so 'available' and 'covered' are overstated with no symptom on the day-of screen.
- Required derived from a weak upstream plan - if Capacity Planning's forecast or handling standards were off, the required figure is off.
First checks: read the gap by interval and by skill, never as a single total; test one 'covered' skill against reality (can those people actually work that queue now); confirm the skill map is current; sanity-check the required figure against the upstream plan.
Escalate when: the skill map's modelling or propagation is in question, or the upstream forecast needs rework. How skills are modelled and how changes propagate are production-dependent - escalate. A silent skill-map error is more dangerous than a visible one precisely because the day-of screens look clean, so treat 'coverage looks fine but reality disagrees' as a skill-map check first.
Symptom: a customer disputes a figure (a cost, an alert, a projection)
Likely causes:
- A configured business rule that does not match the customer's reality - a cost assumption using the wrong rate, or an alert threshold set too tight or too loose. Every alert and what-if cost is 'true given these rules'.
- A projection being read as a result - the customer expected the what-if '+X percent' to have happened and it did not, because it was never a delivered figure.
- Alert noise - the customer sees more or fewer alerts than they expect because of how thresholds are configured, not because the day differed.
First checks: before defending any disputed number, check the rule behind it - the cost assumption or threshold in business rules against the customer's actual rates and policy; confirm the figure in dispute is a projection or a configured value and label it as such; if it is a projection, point to the end-of-day review as where it is checked against actual.
Escalate when: the dispute is about the cost-model fields themselves, whether policy is enforced or advisory, entitlement of alerting, or what IDM can execute directly versus hand off. Never assert on cost-model internals, enforcement behaviour or entitlement - confirm with product.
Symptom: the customer thinks IDM 'isn't doing anything' or 'should have fixed it'
Likely causes - usually an expectation mismatch, not a fault:
- The customer expected IDM to execute actions automatically. It does not - it detects, reforecasts, simulates, recommends and logs; execution happens in the customer's systems within their policy.
- Managers are stopping at the tower (false comfort from a green summary) and never reaching the decision screens, so the loop is not being run.
- The loop is being run but not logged or reviewed, so there is no visible evidence of value.
First checks: re-establish the execution boundary explicitly with the customer; confirm managers are moving from the tower into forecast vs actual, staffing and the what-if, not just watching the tower; confirm decisions are being logged and reviewed at end of day so the value is visible.
Escalate / reset expectations when: the customer was sold an automation IDM does not perform - involve the account owner and confirm with product exactly what executes directly versus hands off, then reset the framing honestly: IDM improves and evidences the decision; the service result is the customer's to realise and must be baselined.
Interpretation check
Most IDM problems are input or configuration problems, and the dangerous ones are silent - a stale actuals feed or wrong skill map corrupts every figure with no symptom on the day-of screens. Diagnose the inputs and the rule behind a figure before doubting the model, and never assert on feed mechanism, cost-model internals, enforcement or entitlement - those escalate.
In the field
KnackGlobal (RCM, ~6,000 seats): a mid-rollout 'IDM's numbers are wrong' complaint traced to a payer-skill map that had drifted out of date - the staffing and what-if figures looked clean but were built on a wrong 'available'. The fix was a skill-map validation, not a model change, which is why the skill map is the first check when coverage looks right but reality disagrees.
Practical task
Take one seeded or real 'the numbers look wrong' complaint and write the diagnosis path: the two or three most likely causes in order, the exact first checks you would run for each, the point at which you would stop and escalate, and who you would escalate to (implementation specialist vs product). State explicitly which parts you must not assert on yourself.
Self-check
A customer says IDM's reforecast is 'just wrong' all week. What is your first check and why?
The actuals / arrival feed freshness and completeness. It is the most load-bearing input and its lag is silent - the reforecast inherits any staleness with no visible symptom. Confirm the feed is live and ask its latency before doubting the model.
Coverage looks fine on the staffing screen but the floor keeps falling short on one queue. What do you check first?
First read the gap by interval and skill rather than as a net total, then test the skill map - are the people marked able to work that queue actually able to now. A silent, stale skill map overstates 'covered' with no symptom on the day-of screen.
A customer disputes a what-if's overtime cost. Before defending the number, what do you do, and when do you escalate?
Check the cost assumption in business rules against the customer's actual rates - the figure is 'true given these rules' and the rule may be wrong. Escalate if the dispute is about the cost-model fields themselves, enforcement behaviour or entitlement; never assert on cost-model internals.
A customer complains IDM 'should have fixed the day automatically'. Is this a fault, and what do you do?
Usually an expectation mismatch, not a fault - IDM detects, simulates, recommends and logs; execution happens in the customer's systems within policy. Re-establish the execution boundary, confirm managers are running and logging the loop, and if it was mis-sold, involve the account owner and reset the framing honestly.
Why treat 'the day-of screens look clean but reality disagrees' as a skill-map or feed check first?
Because those are the silent failures - a stale feed or wrong skill map shows no symptom on the day-of screens, so a clean-looking screen that contradicts reality points to a corrupted input rather than a visible model error. Silent errors get believed; that is what makes them dangerous.
Verified vs demo. The diagnostic screens (forecast vs actual, staffing, business rules, hierarchy and skills) are demo-shown on seeded data at idm.demo.timechamp.io. Feed mechanism and latency, how skills are modelled and propagate, cost-model internals, enforced-vs-advisory policy, alerting entitlement and what IDM can execute directly versus hand off are production-dependent - confirm with product and the implementation specialist. No error messages or UI paths are asserted here.