Quality and Call QA: Sampling
Objective. Open Sampling and read every QA score downstream as an estimate over a sample - judging coverage and representativeness before generalising to the whole operation.
Sampling decides which interactions get reviewed. This screen answers 'what are we choosing to look at, and does it represent the whole?' - the single most important guard against over-reading a QA number.
See it in the demo
What this screen answers
Sampling defines how interactions are selected for review - how many, from whom, by what rule. It answers 'is what we review a fair picture of what actually happens?' A CSM uses it to validate that the sample is representative before trusting any aggregate; Sales uses it to explain honestly that QA is an estimate over a sample and that the sampling design is what makes the estimate trustworthy.
The task
Review the sampling rule for the scope in question: the volume, the basis (random, risk-weighted, agent-balanced) and the resulting coverage. The task is to judge representativeness - are all agents, shifts, work types and channels fairly represented, or does the rule over-sample easy or recent interactions - and to state the coverage level that the downstream scores actually rest on.
How to read it
The foundational guardrail: a QA score is a sample, not a census. Whatever coverage percent you see, scores generalise to the whole population only as far as the sample is representative. The classic misread is treating an aggregate QA number as if every interaction were reviewed. It was not. A biased sample - over-weighting one shift, one channel or recent calls - produces a confident number that does not describe the operation. Read coverage and representativeness together: high coverage of a skewed sample is still skewed, and low coverage can be fine if it is genuinely random and sized for the claim being made.
Honest limits
Sampling design governs representativeness but not scoring accuracy - a perfect sample scored on an uncalibrated rubric is still inconsistent. This screen cannot tell you the hidden quality in unreviewed interactions, only how fairly you are peeking at them. Confirm with product which sampling methods, volumes and risk-weighting rules are entitled; the demo shows the mechanism on seeded data.
Interpretation check
A QA score is a sample, not a census - it generalises to the whole operation only as far as the sample is representative, so a biased sample produces a confident number that does not describe reality.
In the field
KnackGlobal (RCM): risk hides in the 98 percent of interactions nobody reviews, so a sampling rule that over-weights easy cases would leave compliance exposure unseen while the headline score looks healthy.
Practical task
Open the Sampling screen, read the current rule, and write a representativeness check: coverage level, whether all agents/shifts/channels are fairly included, and one sampling bias you would test for - then write the one sentence you would use to caveat the resulting QA number to a customer.
Self-check
A customer says '12 percent of calls reviewed, score 91.' What is the first thing to check?
Representativeness of that 12 percent - which agents, shifts, channels and work types it covers. The score generalises only as far as the sample is fair, regardless of the percentage.
Is high coverage always better than low coverage?
No. High coverage of a skewed sample is still skewed, while a smaller genuinely random sample can support a fair estimate. Representativeness matters as much as volume.
Does a well-designed sample make the scores accurate?
No. Sampling governs representativeness; accuracy comes from the rubric and calibration. A fair sample scored inconsistently is still inconsistent.
What can sampling never tell you?
The quality hidden in the interactions nobody reviewed. It governs how fairly you peek at the population, not what is in the unseen remainder.
Verified vs demo. Screen is live in the demo at /#/review/sampling; exact controls and figures are SME-validation-pending.