Schedule adherence
Objective. Define schedule adherence, show how it is measured against the published schedule, and keep it distinct from work adherence and output adherence.
A dictionary entry. Schedule adherence measures how closely an employee's actual on/off-schedule activity matched the schedule they were given - the first of three adherence layers, and the one that says least about whether useful work was produced.
See it in the demo
What it is
Schedule adherence answers: did the person do the planned activity at the planned time - on shift when scheduled on, in the right state (available, meeting, break, training) when the schedule said so? It is a conformance measure against the published schedule. It is the first and most basic of the three adherence layers in Real-Time Adherence; work adherence (MET-15) and output adherence (MET-16) sit above it.
How it is calculated
At app-logic level: for a period, the time an employee's actual activity state matched the scheduled state is compared against the scheduled time, usually expressed as a percentage, with grace rules that forgive small timing differences. Included: the activity-to-schedule-state mapping and the published schedule in force. Excluded or adjusted: short deviations inside the grace window, and approved exceptions. The exact grace rules, the activity-state mapping, time zone handling and which schedule version counts are configurable - confirm with product. A wrong activity mapping, an unpublished or old schedule, or a time-zone mismatch will distort adherence before any employee behaviour does.
How to read it and the common misread
Read schedule adherence as 'did they follow the plan', not 'did they do good work'. Low adherence flags a planning, timing or exception issue worth a conversation; the target is the customer's own agreed level, not a universal number. The common misread is the central RTA trap: treating schedule adherence as proof of performance. An employee can be fully schedule-adherent and active yet still below the output standard - adherence to the plan and adequacy of the output are different questions answered by different layers. A second misread is reading adherence off an imported schedule that was never published or is in the wrong time zone.
Where it appears
In Real-Time Adherence: the control room, the live adherence view and the exceptions and analytics screens, where it sits alongside work and output adherence so the three can be read together. Demo figures are seeded illustrations.
Interpretation check
Schedule adherence shows whether the plan was followed, not whether useful work or enough output was produced. It is one of three separate adherence layers.
Practical task
In the RTA demo, pick an agent with high schedule adherence and check their output adherence in the same view. Write one sentence explaining why both numbers are needed to judge the agent fairly, and note which schedule version the adherence is measured against.
Self-check
What exactly does schedule adherence measure?
How closely an employee's actual activity states matched the scheduled states over a period - whether they did the planned activity at the planned time, within grace rules.
Why is high schedule adherence not proof of good performance?
An employee can follow the schedule and be active yet still fall below the output standard. Schedule adherence answers 'did they follow the plan', not 'did they produce the required output'.
Name two setup issues that can distort schedule adherence before behaviour does.
A wrong activity-state mapping or an unpublished/old schedule; also a time-zone mismatch and mis-set grace rules. These must be validated before interpreting the number.
What should you confirm with product about schedule adherence?
The grace rules, the activity-to-schedule-state mapping, the time zone handling and which schedule version is the basis - all configurable per instance.
Verified vs demo. The demo shows adherence on seeded schedules and activity. A customer's schedule adherence depends on their activity mapping, grace rules, published schedule version and time zones, which must be validated in their instance.