Real-Time Adherence - data and setup requirements
Objective. Know what Real-Time Adherence needs to produce correct numbers: the signals it consumes, the configuration and feeds that must be wired, the upstream apps it depends on, and the specific checks a CSM runs before trusting any adherence figure - described at app-logic level, with specifics flagged 'confirm with product'.
Every adherence verdict is computed from three inputs - a published schedule, live activity capture, and a set of rules that define what counts as adherent - plus, for the output layer, a trusted output standard. If any of those is wrong, stale or missing, every screen downstream is wrong in a way no floor review can fix. This reference lists what to wire and what to validate first.
See it in the demo
The signals RTA depends on
RTA does not generate data; it compares existing signals against each other in real time. It depends on:
- A published schedule - the roster of who should be in which state in which interval. This is the plan everything is measured against. It must be the currently published version, not a stale import or a draft on an old forecast.
- Live activity capture - the stream that says what an agent is actually doing right now (state, whether scheduled time is going into work). This feeds schedule adherence and work adherence.
- An output signal plus an output standard - a count of work produced in the interval and the expected standard for it. This feeds output adherence, and is only as trustworthy as the standard behind it.
- Adherence rules - grace windows, state mappings, exception thresholds and time zone that turn the raw signals into an adherent / non-adherent verdict.
Which specific activity sources, schedule feeds and output sources are supported for a given customer is entitlement dependent - confirm with product; the demo shows the model, not a named integration.
The setup and configuration required
At app-logic level, standing RTA up for an account means wiring and tuning four things (exact setting names, defaults and edit permissions are SME-validation-pending - confirm with product):
- Schedule feed - connect the currently published schedule so the plan RTA measures against is the live one. A draft on an old forecast can look valid while failing the current coverage requirement.
- Activity mapping - map the customer's real aux and work states to RTA's state model so 'on work' and 'off-agent' mean what the customer means.
- Adherence rules - set grace windows to the customer's policy (so a 90-second overrun is not a violation), exception thresholds so the queue is useful rather than noisy, and the correct time zone (critical for multi-site).
- Output standard and source - connect the output signal and set the expected standard per interval/work type. Until this is validated, treat the output layer as directional.
Advanced configuration and new integrations are a specialist-escalation area, not a CSM toggle.
Dependencies on other apps
RTA sits downstream of the WFM chain and alongside the capture and output apps:
- Scheduling - produces the published schedule RTA measures against. If the schedule is wrong, late or an old version, adherence is wrong at the source.
- Capacity Planning - supplies the forecast / staffing requirement behind the coverage view's 'required' line. A thin interval is measured against this requirement.
- Employee Monitoring - the activity-capture layer behind work adherence, and the app where capture policy, access scope and employee communication are agreed. Agent-level live adherence is the sharpest edge of the surveillance concern, so this must be settled before production use.
- Work Output - defines completed work, complexity, standards and quality; the output standard RTA's output layer compares against is only as trusted as what Work Output establishes.
RTA can run on schedule adherence alone, but the work and output layers - its whole differentiator - depend on these feeds being wired and trusted.
What a CSM validates before trusting the numbers
Run these checks before quoting any adherence figure for a real account. These are the same four plumbing checks the control-room and rules workflows call out:
- Activity mapping - do the customer's real states map correctly, so 'on work' and 'off-agent' are accurate?
- Published-schedule version - is RTA reading the currently published schedule, not a stale import or a draft on an old forecast?
- Grace rules and exception thresholds - do grace windows match the customer's policy and are thresholds set so the exception queue is useful, not noise?
- Time zone and freshness - is the time zone correct for every site, and how fresh is the live data? Confirm latency with product rather than quoting a refresh interval.
For the output layer specifically, also validate that the output standard is trusted and activity capture coverage is sufficient. If either is thin, say plainly that the output layer is directional, not definitive.
What to escalate to the implementation specialist
Hold the line between CSM validation and specialist setup. Escalate rather than guess on:
- New or changed integrations - wiring a schedule feed, activity source or output source, or changing which sources are connected.
- Advanced rule configuration - complex state-mapping, interacting thresholds, or multi-site rule standardisation beyond confirming the basics.
- Data-pipeline or freshness problems - if the live data is stale or a feed has dropped, this is an implementation/product matter, not a floor issue.
- Any security, access-scope or data-residency specifics - never assert these; route to product/security.
The CSM owns validating that the configured inputs reflect how the customer works and that the numbers can be trusted; the specialist owns the plumbing that produces them.
Interpretation check
RTA produces no data of its own - it compares a published schedule, live activity capture and an output standard using configurable rules. A correct rule set makes the data trustworthy but cannot create data: if the schedule is stale, capture is thin or the standard is unvalidated, the output is wrong or directional no matter how the floor is run.
In the field
KnackGlobal (RCM, multi-site, ~6,000 seats): time zone and published-schedule-version are the two settings a multi-site operation most often gets wrong, which is why those two validation checks come before any number is trusted at scale. OVO (contact centre): the Salesforce case + AgentWork effort-to-outcome POC is precisely the activity-and-output-source wiring that makes RTA's work and output layers meaningful - confirm with product which sources are in scope.
Practical task
For a sample account, write the RTA readiness checklist: list each input (schedule, activity capture, output signal+standard, rules) with the upstream app that feeds it, the one validation question a CSM asks for each, and whether a problem with it is CSM-validated or specialist-escalated. Finish with the sentence you would say to a customer who asks you to confirm their exact data-refresh latency.
Self-check
Name the three inputs RTA computes an adherence verdict from, plus the extra one the output layer needs.
A published schedule, live activity capture, and adherence rules (grace, state mappings, thresholds, time zone). The output layer additionally needs an output signal and a trusted output standard.
Which upstream apps feed RTA, and what does each provide?
Scheduling provides the published schedule RTA measures against; Capacity Planning provides the forecast/requirement behind the coverage 'required' line; Employee Monitoring provides activity capture and is where capture policy is agreed; Work Output defines the output standard the output layer compares against.
A CSM is asked for an adherence figure on a new account. What four checks come first, and why?
Activity mapping, published-schedule version, grace rules/thresholds, and time zone plus freshness. A definition or feed error at the source makes every downstream screen wrong in a way no floor review can fix, so the plumbing is validated before any number is quoted.
The output-adherence layer looks low for a real customer. Before treating it as a performance issue, what two data conditions must you confirm?
That activity capture coverage is sufficient for the people/interval, and that the output standard is validated and trusted. If either is thin, the output layer is directional, not definitive - say so.
A customer asks you to confirm the exact real-time data latency and that their Salesforce schedule feed is supported. What do you do?
Do not assert either. Latency and which specific schedule/activity/output integrations are supported are production and entitlement dependent - confirm with product. The demo shows the model, not a named integration.
Verified vs demo. The configuration model (rules, coverage, output layer) is demo-shown at rta.demo.timechamp.io on clean seeded data. Which activity/schedule/output sources are supported, exact setting names and defaults, edit permissions, data latency and freshness are production and entitlement dependent - confirm with product. Treat new integrations and advanced configuration as specialist escalation.