Real-Time Adherence - CSM adoption playbook
Objective. Give a CSM a runnable plan to take Real-Time Adherence (RTA) from entitled to genuinely adopted: a named owner watching the live room during the shift, exceptions reviewed within an agreed response time, and the three adherence layers read as three separate questions rather than one presence score.
RTA only pays off intraday. The adoption risk is not that nobody logs in - it is that the Control Room becomes a wall display nobody acts on, or that a lead reads a green schedule board as proof the work is getting done. This playbook stages rollout from a single pilot team to the floor, fixes the plumbing before the numbers are trusted, and defines what 'adopted' actually looks like.
See it in the demo
The adoption goal and what 'adopted' looks like
Adopted is not 'the room is on a screen'. Adopted is a behaviour loop that runs every shift:
- A named owner per team or queue is watching the live Control Room during the shift, not reading it tomorrow.
- Raised exceptions get a decision - actioned or dismissed with a reason - inside an agreed response time, not left to pile up.
- Leads read the three layers as three questions: schedule adherence (are they on plan), work adherence (is that time becoming work), output adherence (is the work meeting standard). A green schedule board is never treated as proof of productivity.
- A red state triggers a look, not a verdict - the lead checks for a legitimate reassignment or harder work items before acting.
If those four behaviours are present, RTA is adopted even if the dashboards look modest. If they are absent, a beautiful dashboard is not adoption.
Staged rollout: pilot -> team -> scale
Stage 1 - Pilot (one team or queue, 1-2 weeks). Validate the plumbing first (see the data-setup reference): activity mapping, the currently published schedule version, grace rules, time zone and data freshness. Then sit with one real team lead for a full shift, work the exception queue with them, and agree a response-time target. Milestone: the pilot lead can walk the three layers unaided and has dispositioned a shift's exceptions live.
Stage 2 - Team (the whole department, 2-4 weeks). Roll the validated rules and the exception routine to every lead in the department. Introduce the weekly analytics review so recurring patterns go to Scheduling or a manager routine rather than being firefought daily. Milestone: every lead has a named ownership window and the weekly review is running.
Stage 3 - Scale (multi-site / whole floor). Standardise rules across sites, with time zone and published-schedule-version checks per site (this is exactly where a multi-site operation gets adherence wrong). Milestone: a floor-wide response-time target is being met and reviewed exceptions are trending up as a share of raised.
Top adoption risks and how to counter them
- The wallboard trap - the room is displayed but nobody acts on it live. Counter: assign a named live owner and a response-time target before go-live; audit reviewed-exception share weekly. A room nobody watches is an after-the-fact report.
- Green-means-good - a lead reads schedule adherence as proof the work is done. Counter: train every lead to name which layer a number reports before reacting, and show them the 'on-schedule but below output' case on the demo.
- Policing presence - leads chase the agent two minutes late from break while the schedule-perfect, below-output agent goes unnoticed. Counter: anchor coaching to the output and work layers, and make 'look before you judge' (reassignment, harder items, weak standard) the house rule.
- Alert fatigue - thresholds too tight, queue too noisy, so leads ignore it. Counter: tune grace windows and thresholds in the rules screen; measure health by review rate and response time, not alert volume.
- Untrusted output layer - standards or capture coverage are thin, so the output numbers get argued over. Counter: be explicit that the output layer is directional until the standard and capture are validated; do not let it drive write-ups until then.
The success metric to watch and the review cadence
Use RTA's own candidate measures from grounding, baselined to the customer's starting point - never a headline percentage we cannot substantiate:
- Exception response time - minutes from an off-plan or below-output signal to a lead acting. Shrinking this is the whole point of RTA.
- Reviewed exceptions - the share of raised exceptions that actually get looked at and dispositioned versus ignored.
- The three adherences measured separately - schedule, work and output tracked as distinct numbers so the customer stops conflating presence with productivity.
Tie these to a business outcome the customer already owns (SLA attainment, abandon rate, same-day backlog cleared) but do not promise a specific movement in those - RTA shortens the loop; the customer's action closes it.
Cadence. Daily: the live ownership window per shift. Weekly: a 30-minute review of reviewed-exception share and response time, plus any recurring pattern from analytics. Monthly / QBR: trend the three adherences separately, carry structural patterns to Scheduling or Capacity Planning, and re-baseline.
Run it this month - the first-90-days checklist
A concrete sequence a CSM can start with a real account now:
- Week 1 - validate the four plumbing checks (activity mapping, published-schedule version, grace rules/time zone, freshness). Do not quote any adherence number until these pass.
- Week 1-2 - pilot one team: shadow one lead for a shift, work the exception queue together, agree the response-time target and the named owner.
- Week 3-4 - confirm the lead can walk the three layers unaided; roll the routine to the rest of the department.
- Week 5-8 - start the weekly analytics review; route the first recurring pattern to a schedule or routine change rather than a daily firefight.
- Week 9-12 - standardise across sites with per-site time zone and schedule-version checks; set and review a floor-wide response-time target.
Escalate advanced rule configuration and new integration wiring to the implementation specialist - treat it as a specialist area, not a CSM toggle.
Interpretation check
Adoption is a live behaviour loop, not a dashboard. The adopted state is a named owner watching the room during the shift, every exception getting a decision within an agreed response time, and leads reading schedule, work and output as three separate questions - with a red state treated as a prompt to look, never an automatic verdict.
In the field
KnackGlobal (RCM, ~6,000 seats, multi-site): staged rollout matters most here - per-site time zone and published-schedule-version checks are exactly where a large multi-site operation mis-defines adherence, and shrinking exception response time on time-sensitive claim queues has a direct revenue-cycle cost (missed filing/appeal windows). OVO (contact centre): the effort-to-outcome thesis is the adoption message - the win is leads acting on the work and output layers intraday, not policing presence.
Practical task
Pick a real or seeded account and draft its RTA adoption plan on one page: (1) the four plumbing checks with who validates each and which escalate to a specialist; (2) the pilot team, its named live owner and the agreed exception response-time target; (3) the three adoption metrics with the customer's own baseline left blank to fill; (4) the daily/weekly/QBR cadence. Then write the one sentence you would use to stop a lead who is treating a green schedule board as proof the work is getting done.
Self-check
A customer says 'RTA is live, the room is on a screen in the team area, so we've adopted it.' Why is that not adoption yet?
A displayed room nobody acts on live is an after-the-fact report. Adoption is the behaviour loop: a named owner watching during the shift, exceptions dispositioned within an agreed response time, and the three layers read as three questions. Check for the loop, not the screen.
What are the four plumbing checks you run before quoting any adherence number for a real account?
Activity mapping is correct, the schedule is the currently published version (not a stale import), grace rules and time zone are right, and the data is fresh. A definition error at the source makes every downstream screen wrong in a way no floor review can fix.
Which single metric most directly captures whether RTA is delivering its value, and why not a headline SLA improvement?
Exception response time - minutes from signal to action - because RTA shortens the intervention loop; that is its mechanism. SLA, abandon rate and backlog are the customer's outcomes, which their action closes; we do not promise a specific movement in those.
A lead is writing up agents who show red schedule states. What adoption risk is this, and how do you counter it?
Policing presence / treating red as a verdict. Counter by making 'look before you judge' the house rule - a red state can be a legitimate reassignment to a hotter queue or harder work items - and anchor coaching to the work and output layers, not the login.
The exception queue is being ignored because it is too noisy. Is that a floor problem or a configuration problem first?
Configuration first. Tune grace windows and thresholds in the rules screen; a high alert count usually means thresholds are too tight, not that the floor is failing. Measure health by reviewed-exception share and response time, not raw volume.
Verified vs demo. The Control Room, exceptions queue and analytics are demo-shown at rta.demo.timechamp.io on seeded data and support rehearsing this playbook. Real-time latency, which schedule/activity integrations are wired, available alert routing, and the strength of a customer's output standard are production and entitlement dependent - confirm with product and treat advanced configuration as specialist escalation.