Your QA team reads a sample. An agent can read every ticket.
Support QA still runs on samples because reading everything used to cost too much. A bank just showed what changes when an agent does the first read.
What happened
Microsoft's year-end post, Looking back on Microsoft's FY26, is a long list of customer results, most of them productivity numbers. One stands out for anyone who runs a support operation. Banco Popular Dominicano, the largest private bank in the Dominican Republic, used to review operational risk the way most companies review anything: periodically, and by sample.
The bank built a set of specialized agents, and Microsoft says it now monitors all of its operational risk in real time, up from roughly 40% coverage, while working through about 80,000 documents a week. Those are figures from a vendor's own blog, so hold the exact numbers loosely. The shape of the change is what's worth copying. The team stopped choosing which records to read and started reading all of them, and people now spend their hours on what the agents surface. Risk specialists built it themselves with low-code tools.
Why this matters to your business
Your support QA almost certainly works the way the bank's risk team used to. A QA lead pulls a handful of conversations per agent each week and scores them against a rubric. Everything outside the sample goes unread. That's where the wrong refund promise or the disclosure that never got said tends to sit until a customer complains or a regulator asks.
Sampling was the right call when every review cost a person's time. But it means your quality score is an estimate, your coaching rests on a few calls, and a problem with one product line can run for weeks before it lands in anyone's sample. If AI agents now answer customers alongside your people, the volume goes up and the share anyone reads goes down.
Why this is a CX-Builder use case
Checking a conversation against a written standard is work an agent does well, because the standard already exists on paper. Your QA scorecard, your refund policy and your required disclosures are documents. CX-Builder loads them into a knowledge base, so a review agent checks each transcript against your actual rules instead of a model's general idea of good service.
Your QA lead stays. The agent does the first read on every closed ticket and sorts it. Most will pass and get logged with a score. The ones that break a rule or score below a threshold go to a person, with the rule cited and the line from the transcript quoted. Your QA team spends its week on the cases that matter, and coverage goes to every ticket without adding reviewers.
The bank's other lesson applies too. Your QA lead knows what a bad conversation looks like better than any engineer does. In a visual builder, that person can shape the rubric and set the thresholds directly instead of filing a request and waiting.
What this looks like if you build it
It's one flow, run on each closed conversation from your helpdesk or as a nightly batch. A document store holds the rubric and policies, so retrieval pulls the rules that apply to this ticket's topic. The review agent returns a structured result: pass or fail on each rubric item, plus the rule and the transcript quote behind each call. A condition sends failures and low-confidence calls to a human review step and writes the rest to your reporting store.
Run it on last month's tickets before you trust it on live traffic, and compare its calls with what your QA team scored by hand. Where the two disagree, you'll usually find a rule that was never written down.
The takeaway
Count how many conversations last month's QA scores were based on, as a share of everything your team handled. If that share is small, pick your single most expensive failure, a missed cancellation or a wrong refund promise, and build a review agent that checks every ticket for that alone. Widen the rubric once its flags match what your QA lead would have caught.