Time and Activity: Exception queue
Objective. Work the exception queue: read why a case is flagged against agreed rules, drill it, and explain why an exception is a prompt to investigate, not a verdict.
The exception queue is where value concentrates: instead of reading every timeline, a manager is routed to the days and people that fall outside agreed rules. It answers 'where should I spend my limited review time today?'
See it in the demo
What this screen answers
Manager attention is finite. This screen answers the highest-leverage question in the app: of everything that happened, which few cases fall outside the agreed rules and deserve a human look? It replaces reading every person's day with a routed, prioritised list - the engine of the whole adoption routine.
The task
Open the queue scoped to the manager's teams, read why each case was flagged (which rule and threshold it breached), drill the top ones to their timeline, and log a decision - reviewed, actioned, or dismissed as expected. The task is a repeatable routine: work the queue, not the raw data. Adoption is this loop running on a cadence with a named owner.
How to read it
An exception is a flag against a configured rule, not a verdict on a person. It means 'this fell outside the threshold we agreed', which is a prompt to investigate, not a finding of fault. Coverage gaps can produce false positives (someone with no signal flagged as absent), and the thresholds decide what appears at all. The misread is treating the queue as a list of wrongdoers rather than a list of things to check against rules the customer set.
Honest limits
The queue is only as meaningful as the rules and thresholds behind it, which must be agreed with the customer against their policy rather than taken from demo defaults - otherwise flags are disputable. It routes attention; it does not resolve cases or prove cause. Its value shows up only when reviewed exceptions lead to logged actions - measure follow-through, not flag volume.
Interpretation check
An exception is a case that broke an agreed rule or threshold - a prompt to investigate, not a verdict of fault. Coverage gaps cause false positives, and thresholds are customer-set; work it as a check-list against agreed rules, not a list of wrongdoers.
In the field
KnackGlobal (~6,000 seats): the queue is what makes daily review feasible at scale - leads act on a routed handful rather than thousands of timelines - and the KPI that matters is follow-through, not flag count.
Practical task
On the demo exception queue, take the top case, state which rule/threshold it appears to breach and what you would check on the drill, and write the decision you would log - framed as investigation, not verdict.
Self-check
A manager treats the queue as a list of people who did wrong. How do you reframe it?
Each item only means a case fell outside a configured threshold. It is a prompt to investigate against agreed rules; cause and fault are decided after the drill, not by the flag.
What can cause a false positive in the queue?
Data coverage gaps - someone with no activity signal can be flagged as absent or idle. That is why thresholds and coverage must be validated with the customer.
What should you measure to show the queue is working?
Exception review rate and manager follow-through - reviewed cases that lead to a logged action - not the raw number of flags.
Verified vs demo. Screen is live in the demo at /#/exceptions; exact controls and figures are SME-validation-pending.