Real-Time Adherence - common misreads and the correct reading
Objective. Carry a quick-reference catalogue of the ways people misread Real-Time Adherence, so a Sales or CSM person can correct a customer in the moment. Each entry gives the wrong reading, why it is wrong, and the correct reading - grouped by theme.
RTA's single biggest misread is reading schedule adherence (presence on plan) as proof the work is getting done. The rest follow from conflating the three layers, treating a red state as a verdict, or trusting a number without checking the rules that produced it. This is the high-value card to keep open during a demo or a customer dispute.
See it in the demo
Theme 1 - Presence vs productivity (the core guardrail)
Misread: 'We're 98 percent adherent, so the team is performing.'
- Why it is wrong: adherence here is schedule adherence - it only confirms people are logged in and in the planned state at the planned time. It says nothing about whether that time became work or met standard.
- Correct reading: schedule adherence answers 'are they on plan', not 'is the plan producing work'. Show the work and output layers for the same scope. An agent can be 98 percent schedule-adherent and below the output standard.
Misread: 'The board is green, so we're fine today.'
- Why it is wrong: green on a schedule board is presence and state only.
- Correct reading: always name which layer a number reports before reacting. Green schedule adherence with red output adherence is a real problem the green hid.
Theme 2 - Collapsing the three layers into one
Misread: treating 'adherence' as a single score.
- Why it is wrong: schedule, work and output adherence are three different questions. Schedule-adherent means present and on-state; work-adherent means that time is going into work; output-adherent means the work meets standard.
- Correct reading: keep them as three separate numbers. A team can pass the first two and fail the third, and the fix for each is different - a presence problem goes to scheduling/coaching on attendance, an output problem goes to the work itself (complexity, process, standard, Work Output).
Misread: 'Work adherence is low, so the agent is idle.'
- Why it is wrong: low work adherence can mean the agent is working in a system that is off-agent rather than doing nothing, or that activity capture coverage is thin for them.
- Correct reading: low work adherence is a prompt to check what the agent is actually doing and whether capture is complete - not proof of idleness.
Theme 3 - Red states and below-output as verdicts
Misread: 'This agent is red / non-adherent, so write them up.'
- Why it is wrong: a red schedule state can be a legitimate reassignment to protect a hotter queue - exactly the right call under pressure, showing as off-schedule.
- Correct reading: a red state is a prompt to look with context, not a verdict. Check for a sanctioned reassignment and read the timeline before acting.
Misread: 'Output adherence is below standard, so this is underperformance.'
- Why it is wrong: below-output can reflect harder or more complex work items in the interval, an upstream process blocker, or an output standard that is not yet trusted or correctly set.
- Correct reading: below-output is a prompt to examine the work and the standard, never a productivity verdict on a person. Confirm the standard is validated before treating it as a performance issue.
Theme 4 - Exceptions, volume and the rules behind the number
Misread: 'The exception queue is huge, so the floor is failing.'
- Why it is wrong: a high alert count often means thresholds are set too tight, not that the floor is badly run. Many exceptions are legitimate (sanctioned reassignment, absorbed break overrun, known outage).
- Correct reading: an alert is a decision-pending item, not a confirmed problem. Measure health by the share of exceptions reviewed and the response time, not by how many fired. Tune the rules if the queue is noisy.
Misread: debating an adherence figure without checking the rules.
- Why it is wrong: adherence is the output of configurable rules - grace windows, state mappings, thresholds, time zone. Change the grace window and the same behaviour flips between violation and non-event.
- Correct reading: if a customer disputes a figure, the rules screen is the first stop. A wrong time zone, stale schedule source or unmapped state makes every downstream screen wrong at the source.
Theme 5 - Coverage, live vs retrospective, and demo vs production
Misread: 'We have enough people today, so every interval is covered.'
- Why it is wrong: coverage is required-versus-actually-active per interval and skill. A day that nets out to 'enough people' can have a starved 10:00 interval and an overstaffed 15:00, and a skill-dependent queue uncovered while generalists sit idle. A rostered agent who is off-plan is not covering the interval.
- Correct reading: read the specific thin interval and skill, not the day's net balance, and read coverage together with the adherence layers.
Misread: running the live floor off the analytics view.
- Why it is wrong: analytics is retrospective - it shows yesterday's and last week's patterns. The live shift is fixable only in the Control Room.
- Correct reading: use analytics for recurring patterns that feed schedule or routine fixes; manage today in the Control Room.
Misread: quoting the demo's clean numbers or refresh speed as production fact.
- Why it is wrong: the demo runs on seeded data; real-time latency and supported integrations are production dependent.
- Correct reading: present the model, and say the output layer is directional until the customer's standard and capture are validated. Confirm latency and sources with product.
Interpretation check
The master misread RTA exists to stop is reading presence as productivity. Adherence is 'did the actual state match the schedule', not 'did the work get done'. Schedule, work and output adherence are three different questions; a red state can be a legitimate reassignment; and any figure is the output of configurable rules, so check the rules before you argue the number.
In the field
KnackGlobal (RCM): in a displacement deal the 'presence is not productivity' misread is the wedge - the incumbent proves schedule adherence; the work and output layers prove the presence turned into work at standard. OVO (contact centre): the effort-to-outcome POC is the lived version of 'schedule-adherent and active but below output', which is why that misread is the one to rehearse hardest.
Practical task
Build a one-page misread card for a live demo or dispute: pick the five misreads most likely for the customer in front of you, and for each write a single sentence that states the correct reading in plain language. Then, on the demo, trigger the 'green schedule but below output' case and rehearse correcting it out loud in under 20 seconds.
Self-check
A customer points at a 98 percent adherence number as proof of productivity. Give the wrong reading, why it is wrong, and the correct reading.
Wrong reading: high adherence means the team is producing. Why wrong: schedule adherence only confirms presence and state at time. Correct reading: it answers 'are they on plan', not 'is the plan producing work' - show the work and output layers, where the agent may be below standard.
A lead wants to discipline an agent showing a red schedule state. What is the misread and the correct reading?
Misread: red equals a verdict to act on. Correct reading: a red state can be a legitimate reassignment to protect a hotter queue - it is a prompt to look with context and read the timeline, not an automatic write-up.
The exception queue has a high count and the customer concludes the floor is failing. Correct them.
A high count usually means thresholds are too tight, and many exceptions are legitimate. An alert is a decision-pending item, not a confirmed problem. Measure health by reviewed-exception share and response time, and tune the rules - do not read volume as floor quality.
The day nets out to full staffing but the SLA still slipped. Which misread explains it?
Reading net headcount as coverage. Coverage is required-versus-active per interval and skill - a specific interval or skill-dependent queue can be starved while the day balances, and an off-plan rostered agent is not covering the interval. Read the thin interval, not the net.
A customer disputes a specific adherence figure. What is the first thing you check, and why is arguing the number first a misread?
Check the adherence rules first - grace windows, state mappings, thresholds, time zone, schedule source. Adherence is the output of these rules, so a wrong time zone or stale schedule makes the figure wrong at the source; no floor review fixes a definition error.
Verified vs demo. All screens cited are demo-shown at rta.demo.timechamp.io on seeded data, which is ideal for rehearsing these corrections. Exact labels, figures, refresh latency and supported integrations are SME-validation-pending - the correct readings here are about interpretation, not about asserting any specific number or control.