Quality and Call QA: Review Queue
Objective. Open the Review Queue and read queue depth and turnaround as workflow throughput signals, not as quality outcomes.
The Review Queue is where sampled interactions wait to be reviewed. It answers 'is evaluation keeping up, and what is waiting?' - a throughput view, distinct from whether quality is good.
See it in the demo
What this screen answers
The queue holds interactions selected for review and tracks what is pending, in progress and done. It answers 'is the review workload under control and what should a reviewer pick up next?' A CSM uses it to run the operational cadence of reviewing; Sales uses it to show that coverage is a managed process with turnaround, not an ad hoc scramble when someone has time.
The task
Filter to the team, reviewer or period, then read the queue for flow: what is waiting, how long it has waited, and whether turnaround is holding. The task is throughput management - decide what gets reviewed next and whether reviewers are keeping pace - and to notice when the queue composition reflects a sampling choice rather than a quality signal.
How to read it
The classic misread is reading a short or empty queue as 'quality is good'. Queue depth is a workflow measure - how much review work is outstanding - not a quality outcome. An empty queue can mean reviewers are keeping up, or that sampling fed in very little to review. A long queue signals a throughput or staffing problem, not necessarily a quality problem. What lands in the queue is set upstream by sampling, so the queue describes review capacity against the sampled load, nothing more.
Honest limits
The queue proves nothing about scoring accuracy, representativeness, or whether findings close into coaching. Fast turnaround on an uncalibrated rubric just produces inconsistent scores faster. Confirm with product how queue assignment, SLAs and prioritisation are configured and entitled; the demo shows the review flow on seeded interactions.
Interpretation check
Queue depth and turnaround are throughput signals - a short queue means review is keeping up with the sampled load, not that quality is good.
In the field
OVO (contact centre): a visible, SLA-managed review queue shows a voice operation that review happens on a cadence, not whenever a team lead finds a spare hour - but the queue still says nothing about whether scores are consistent.
Practical task
Open the Review Queue, scope it to one team, and write a two-line throughput read: what is waiting and whether turnaround is holding - then state explicitly why this does not tell you whether the team's quality is good.
Self-check
The queue is empty. Is quality good?
Unknown from this screen. An empty queue means review kept up with what sampling fed it, or that little was sampled. Queue depth is throughput, not a quality outcome.
What upstream screen controls what lands in the queue?
Sampling - it selects which interactions are routed for review, so the queue reflects the sampled load, not the full population.
A long queue appears. What is the most likely diagnosis?
A throughput or reviewer-capacity problem, not necessarily a quality problem - too much is waiting to be reviewed relative to reviewer time.
Why is fast turnaround not automatically good?
Because speed on an uncalibrated rubric just produces inconsistent scores faster. Turnaround is only valuable once the rubric and calibration make the scores trustworthy.
Verified vs demo. Screen is live in the demo at /#/review; exact controls and figures are SME-validation-pending.