Scheduling - Troubleshooting and Escalation
Objective. Give a CSM a symptom-first guide to the common Scheduling problems - numbers that look wrong, coverage gaps, and disputed figures - with the likely cause, the first checks to run, and the line where it escalates.
When a schedule looks wrong, the cause is almost always an input or a boundary, not a broken screen: the draft is on a stale forecast, the rules or time zone are misconfigured, a plan is being read as actual, or a draft is being treated as published. This guide works symptom by symptom - likely cause, first checks, when to escalate - at app-logic level, with no invented error messages or UI paths.
See it in the demo
First, the triage reflex
Before diagnosing any specific symptom, establish two facts about the schedule in front of you, because they change what every number means:
- Which forecast version is this draft bound to - live or stale? Coverage is planned against the forecast, so a stale version is the single most common root cause of 'the schedule looks wrong'.
- Is this a draft or a published schedule? A draft carries no commitment; a published one does and is still subject to real-world change.
Also confirm the scope (team, period) and the time zone you are reading in. Most 'wrong number' tickets resolve at this step, before you look at anything else. Keep capacity/plan readings separate from any cash claim - Scheduling does not produce cash figures.
Symptom - numbers look wrong or missing
Likely causes: the draft is bound to a stale or wrong forecast version; rules or skills are misconfigured so violations and coverage read against the wrong policy; the time zone is wrong so coverage windows are shifted; the roster/forecast import is incomplete or stale; or a planned figure is being compared against an actual one from RTA.
First checks (in order): confirm the forecast version is live; confirm the configured labour rules and skill requirements match the customer's policy; confirm the time zone for the team/site; confirm scope (team and period); confirm the data import is current. Re-read the figure with those confirmed.
Escalate when: the forecast or roster/skills integration is returning stale or incomplete data after a refresh; a required labour rule is not in the supported set; or the numbers remain inconsistent after forecast, rules, time zone and scope are all confirmed. Route to the implementation specialist / product - do not guess at an integration or a rule capability.
Symptom - coverage gaps (or surprise shortages)
Likely causes: the gap is real and the draft genuinely under-covers a peak; the manager is reading the daily total instead of interval coverage; headcount is covered but a skill the interval needs is not; an approved request became a constraint that opened a shortage; or the gap is measured against a stale forecast so it is wrong in either direction.
First checks: read coverage by interval, not by day total, and name the short interval; check whether the shortage is a skill gap rather than a headcount gap; check recently approved requests, time-off and open-shift/VTO activity for the period; confirm the forecast version. If the draft genuinely under-covers, that is a planning problem to solve with optimization, open shifts or a scenario - not a data fault.
Escalate when: coverage cannot be met within the customer's rules and available workforce (a capacity problem, not a scheduling one - loop in Capacity Planning), or when the gap persists despite a correct forecast and valid configuration.
Symptom - a customer disputes a figure
Likely causes: a planned figure is being read as an actual result ('coverage was green but we missed SLA'); a draft is being treated as the published commitment; two parties are comparing schedules on different forecast versions or periods; or 'zero violations' is being read as 'compliant' when the rules configured are not the customer's full policy.
First checks: establish planned-versus-actual explicitly - if the dispute is about what happened on the day, that is Real-Time Adherence and Work Output, not Scheduling; confirm whether the figure in dispute is from a draft or a published version; align both parties on the same forecast version and period; and confirm what rule set 'zero violations' was measured against. Write the reconciliation down (definition, scope, forecast version, draft-or-published) as an escalation packet if needed.
Escalate when: the dispute turns on a compliance, contractual or security specific - never assert those; route to product/security. Also escalate if reconciliation shows a genuine data or integration fault rather than a reading difference.
Symptom - change and version confusion after publication
Likely cause: change after publication is unowned - edits appear with no named owner, multiple versions circulate, and employees do not know which schedule is live or have not acknowledged.
First checks: confirm there is a single named publication owner; confirm change is routed through requests/open-shifts/VTO rather than private edits; check acknowledgment is flowing; check schedule stability (how much the published version has churned). Heavy churn usually points back to a weak forecast or an unowned process, not a product fault.
Escalate when: the publication/notice/republication controls the customer needs are unclear or appear not to match their governance - confirm the supported controls with product rather than describing behaviour you have not verified. This is an adoption and ownership fix first; see the adoption playbook.
Interpretation check
Most Scheduling problems are input or boundary problems, not broken screens. Before diagnosing, fix the two facts that change every number: which forecast version the draft is bound to, and whether it is a draft or published. Escalate integration, unsupported-rule, compliance and security questions - never guess them.
In the field
A multi-site RCM operation raised a 'coverage looks wrong' ticket; triage found two sites being compared on different forecast versions and one read in the wrong time zone - a reading and configuration fix, not a product fault, resolved before it reached an SLA dispute.
Practical task
Take one seeded 'wrong-looking' schedule in the demo. Run the triage reflex (forecast version, draft-or-published, scope, time zone), classify the symptom, list the first checks you ran and the outcome, and state explicitly whether it resolves as a reading issue, a planning issue, a capacity issue, or an escalation to the implementation specialist / product.
Self-check
A customer says 'the schedule numbers are wrong.' What are your first two checks?
Which forecast version the draft is bound to (live or stale), and whether it is a draft or published - plus scope and time zone. A stale forecast is the single most common root cause.
A manager reports a surprise shortage. How do you tell a reading error from a real gap?
Read coverage by interval not by daily total, and check whether it is a skill gap rather than a headcount gap. If the draft genuinely under-covers within valid rules and workforce, it is a real planning problem; if coverage cannot be met at all, it is a capacity problem to escalate.
A customer disputes 'coverage was green but we missed SLA.' Where does this belong?
That is planned-versus-actual. Green coverage is the plan; what happened on the day is Real-Time Adherence and Work Output. Reconcile by separating the plan from delivery, not by debating the coverage figure.
When does a disputed figure escalate rather than reconcile?
When it turns on a compliance, contractual or security specific, or when reconciliation reveals a genuine data/integration fault - route to product/security and never assert those specifics yourself.
Edits and versions are confusing employees after publication. Is this a product bug?
Usually not - it is unowned change. Confirm a single publication owner, route change through requests/open-shifts, check acknowledgment and stability. Escalate only if the needed publication controls are unclear versus the customer's governance.
Verified vs demo. Coverage, configuration, planner and the change/audit view are demo-shown on seeded data; exact controls, labels and figures are SME-validation-pending. Integration behaviour, the supported labour-rule set, time-zone handling and publication controls for a specific customer are confirm-with-product.