Real-Time Adherence: Exceptions and alerts
Objective. Work the exception queue - review each raised signal, decide action versus dismissal with a reason, and treat dispositioning as the behaviour that makes RTA worth adopting.
Exceptions and alerts answers 'what has the room flagged that needs a human decision, and did someone make it?' - the working queue that converts live signals into reviewed, dispositioned actions instead of ignored noise.
See it in the demo
What this screen answers
The customer question is: of everything happening on the floor, what crosses the threshold that a lead should look at, and what happened to each one? A Sales person uses it to show RTA as a managed workflow, not an alarm that fires and is ignored. A CSM uses it as the heart of adoption: the goal is not more alerts, it is that raised exceptions get reviewed and dispositioned within an agreed response time by a named owner.
The task
Scope to the team and work the queue item by item: open an exception, read the agent and timeline context behind it, then either action it (reassign, message, adjust) or dismiss it with a stated reason. The discipline is that every exception gets a decision, not that every exception gets a fix. Tune the alerting threshold with the rules screen if the queue is too noisy or too quiet. Exact queue columns, alert-type labels and disposition controls are SME-validation-pending.
How to read it
The classic misread is treating an alert as a problem by definition. Many exceptions are legitimate - a sanctioned reassignment, an absorbed break overrun, a known system outage - and the correct disposition is to dismiss with a reason. A high alert count is not a measure of a bad floor; it may mean the thresholds are too tight. Read the queue as decisions-pending, and measure health by the share of exceptions reviewed and the response time, not by how many fired.
Honest limits
This screen shows the exception model on seeded demo data. Which conditions raise an alert, grace windows, and routing all depend on configured rules and on the schedule and activity feeds being correct - a stale schedule or a capture gap produces false exceptions. Confirm with product the available alert types, delivery channels and whether alerts can route to external tools. The queue surfaces signals; it does not prove the underlying data is trustworthy. Do not quote alert latency as fact.
Interpretation check
An alert is a decision-pending item, not a confirmed problem. Many exceptions are legitimate and the right disposition is to dismiss with a reason; health is measured by review rate and response time, not by alert volume.
In the field
KnackGlobal (RCM): on time-sensitive claim queues, the measure that matters is exception response time - minutes from a below-coverage or below-output signal to a lead acting - because a slow disposition is where a filing or appeal window is missed.
Practical task
On the demo, work three exceptions end to end: for each, write the context you checked and your disposition (action or reasoned dismissal), then state the response-time target and named owner you would agree with the customer for this queue.
Self-check
A customer worries the exception queue is 'too noisy.' Is a high count a bad sign?
Not by itself. A high count often means thresholds are too tight, not that the floor is failing. Tune the rules and measure the share of exceptions reviewed and the response time instead of the raw count.
What is the single behaviour that tells a CSM RTA is actually adopted here?
Raised exceptions get reviewed and dispositioned - actioned or dismissed with a reason - within an agreed response time by a named owner. Ignored alerts mean no adoption regardless of the dashboard.
An exception fires for an agent who was reassigned to a hotter queue. What is the correct handling?
Dismiss it with a reason noting the reassignment. The signal was valid to raise but the behaviour was correct, so the disposition is a reasoned dismissal, not an intervention.
Verified vs demo. Exceptions and alerts is live in the demo at /#/exceptions on seeded data. Exact queue columns, alert-type labels, disposition controls, delivery channels and routing options are SME-validation-pending; confirm with product.