Real-Time Adherence - diagnosis and escalation
Objective. Give a CSM a symptom-first guide to the problems that actually come up with Real-Time Adherence - numbers that look wrong, coverage gaps, and disputed figures - with the likely cause, the first checks to run, and the point at which it escalates to the implementation specialist or product.
Almost every RTA problem is one of three things: the inputs are wrong (stale schedule, bad time zone, unmapped state, thin capture), the rules are mis-tuned (grace/thresholds), or the number is being misread (presence taken for productivity). Diagnose at app-logic level - the four plumbing checks resolve most of it - and escalate the plumbing, never guess at it.
See it in the demo
Symptom: 'the adherence numbers look wrong or missing'
Likely causes. A stale or wrong published schedule (RTA is measuring against the wrong plan), an incorrect time zone (especially multi-site), unmapped or mis-mapped states (so 'on work' / 'off-agent' are wrong), thin or dropped activity capture, or a missing output standard leaving the output layer blank.
First checks a CSM runs - the four plumbing checks, in order:
- Is RTA reading the currently published schedule, not a draft or a stale import?
- Is the time zone correct for the site in question?
- Do the customer's real states map correctly to RTA's model?
- How fresh is the live data - is a feed delayed or dropped?
For a blank or flat output layer, also check that an output signal and a trusted standard are actually wired.
When to escalate. If a feed is delayed or dropped, if a source is not connected, or if the fix needs a data-pipeline change, escalate to the implementation specialist / product - do not guess at latency or assert a source exists. The CSM confirms the inputs reflect how the customer works; the specialist owns the plumbing.
Symptom: 'coverage gaps - the SLA slipped but we had enough people'
Likely causes. Coverage being read as net headcount rather than required-versus-active per interval and skill; agents rostered but off-plan (not actually covering their interval); a thin interval hidden inside a day that balances overall; or a skill-dependent queue uncovered while generalists sit idle. The required line itself may be wrong if the upstream forecast/requirement from Capacity Planning or the schedule from Scheduling is off.
First checks. Scope to the specific interval and skill, not the day - find where active coverage fell furthest below requirement and whether the gap was widening. Cross-check the adherence layers: a rostered-but-off-plan agent explains a gap that headcount hides. Confirm the required line's upstream feed is current.
When to escalate. If the required line looks wrong, trace it to Scheduling / Capacity Planning rather than treating it as an RTA fault. If the forecast or requirement feed is misconfigured, that is a cross-app / specialist matter.
Symptom: 'a customer disputes a specific figure'
Likely cause. Almost always the rules behind the number, not the number itself. Adherence is the output of grace windows, state mappings, thresholds and time zone - a wrong time zone, a stale schedule source or an unmapped state makes the figure wrong at the source, and no floor review fixes a definition error. The other common cause is a misread - presence being taken for productivity, or a red state assumed to be a verdict.
First checks. Go to the adherence rules first: validate grace windows match the customer's policy, state mappings reflect real states, thresholds are sensible, and time zone and published-schedule source are correct. Then confirm which layer the disputed number reports - a dispute about 'productivity' is often really about schedule adherence being read as output.
When to escalate. Advanced rule configuration, interacting thresholds and multi-site rule standardisation go to the specialist. Never assert a rule capability or a default exists - confirm with product. Record the dispute and the definition you validated as an escalation packet if it cannot be closed at the rules level.
Symptom: 'the exception queue is noise / nobody acts on it'
Likely causes. Thresholds set too tight raising trivial exceptions; grace windows too short; legitimate events (sanctioned reassignment, absorbed break overrun, known outage) being raised as alerts; or - the adoption failure - no named owner and no agreed response time, so the queue is simply ignored.
First checks. Is a high count a rules problem? Tune grace and thresholds in the rules screen before concluding the floor is failing. Is the queue being worked at all - what share of exceptions are reviewed and dispositioned, and what is the response time? Confirm a named owner and a response-time target exist.
When to escalate. Alert routing, delivery channels and whether alerts can route to external tools are entitlement dependent - confirm with product rather than promising. If the problem is adoption (no owner, no routine) it is a CSM-owned fix (see the adoption playbook), not a product escalation.
Symptom: 'output adherence is low and leads are writing people up'
Likely causes. A genuine output issue, but equally: an output standard that is not yet trusted or correctly set, harder work items in the interval, an upstream process blocker, off-agent work being read as idle, or thin capture coverage for that person.
First checks. Before any performance conclusion, confirm the output standard is validated and that activity capture coverage is sufficient for the people and interval. Read all three layers together for the agent and pull the timeline and any attached exception for context. Check whether a red schedule state was actually a legitimate reassignment.
When to escalate / redirect. If the output standard or capture is not yet validated, state plainly that the output layer is directional, not definitive, and it must not drive write-ups. A structural pattern (same team below output every week) is a Scheduling / Work Output / coaching matter surfaced via analytics, not a live-floor disciplinary one. This is a people-fairness line - capture policy and employee communication should already be agreed (see Employee Monitoring).
Interpretation check
Most RTA problems are input or rule problems, or a misread - not a broken screen. A disputed or odd number is a signal to validate the four plumbing checks and the rules behind it, not to argue the figure. And a low output layer is a prompt to check the standard and capture before anyone is treated as underperforming.
In the field
KnackGlobal (RCM, multi-site, ~6,000 seats): time zone and published-schedule-version are the two faults a multi-site rollout hits first, and a disputed figure there is nearly always a rules/definition problem rather than a real adherence gap. OVO (contact centre): low output adherence that turns out to be harder work items or an unvalidated standard is exactly the case where jumping to a write-up would damage trust - check the standard and capture first.
Practical task
Take a seeded 'numbers look wrong' case on the demo and write the diagnosis note: the symptom, the four plumbing checks you ran and what each showed, your conclusion (input error, rule mis-tuning, or misread), and the exact point at which you would escalate to the implementation specialist versus close it yourself. Include one sentence you would put in an escalation packet for a disputed figure.
Self-check
A customer says their adherence numbers 'look wrong'. What four checks do you run first and why in that order?
Published-schedule version, time zone, state mapping, and data freshness - the four plumbing checks. A definition or feed error at the source makes every downstream screen wrong, so you validate the inputs before concluding the screen or the floor is at fault.
SLA slipped but the day had enough people. Where do you look, and what is the likely cause?
Scope to the specific interval and skill, not the day's net. Likely a thin interval hidden by the net balance, or rostered-but-off-plan agents not actually covering - and possibly a wrong required line from an outdated Capacity Planning / Scheduling feed.
A customer disputes a specific figure. What is the first stop and what do you refuse to do?
The adherence rules - validate grace windows, state mappings, thresholds, time zone and schedule source. Refuse to argue the number before validating its definition, and refuse to assert a rule or default exists - confirm with product.
The exception queue is being ignored as noise. Is this always a product escalation?
No. First tune thresholds and grace in the rules screen (a high count usually means thresholds too tight). If the real problem is no named owner and no response-time target, it is a CSM-owned adoption fix, not a product escalation. Routing/channels are the part to confirm with product.
Leads are writing people up on low output adherence. What must you confirm first, and where does a persistent pattern go?
Confirm the output standard is validated and capture coverage is sufficient; if not, the layer is directional and must not drive write-ups. A persistent structural pattern goes to Scheduling / Work Output / coaching via analytics, not to live-floor discipline, with capture policy and employee communication already agreed.
Verified vs demo. The rules, coverage, exceptions and agent screens are demo-shown at rta.demo.timechamp.io on clean seeded data, so the demo will not reproduce a real stale-feed or capture-gap fault - those are production conditions. Do not invent error messages or UI paths; diagnose at app-logic level. Data latency, supported integrations, alert routing and exact settings are SME-validation-pending; confirm with product and escalate plumbing to the specialist.