- A typical iGaming QA process reviews about 2% of conversations by hand; CSAT surveys get a single-digit response rate. Most of what happens is never measured.
- Good iGaming support quality control software encodes the scorecard your QA team already uses and applies it to 100% of chats, emails and calls.
- Score humans and AI on the same rubric — intent, action, escalation, resolution, dialog — so the comparison is real.
- Gate on every dimension, not the average: 88% overall with 72% on escalation is a fail.
- Before trusting the grader, measure its agreement with your QA leads on a hand-labelled set. Self-graded scores are almost always inflated.
iGaming support quality control software exists to answer a question most operators cannot answer today: how good was support this week, across every conversation, in every language? Not "how did the dozen chats our QA manager read on Tuesday go", and not "what did the few players who filled in the survey feel" — but how every conversation measured up against the standard your team already agreed on.
This guide covers what that software should do, the rubric that works for human agents and AI alike, the gates that stop a good average from hiding a dangerous weakness, and the step most vendors skip: proving the automated grader actually agrees with your QA lead.
The problem with manual QA in iGaming
The setup is remarkably similar across operators: one quality manager or a small QA team, a scorecard in a spreadsheet, and a sample of conversations read by hand each week. The criteria are sensible — correct information, resolution with minimal back-and-forth, satisfaction, tone and personalisation. The coverage is not. A QA team realistically reads around 2% of conversations; the other 98% are never looked at.
That matters more in iGaming than in most industries, because the rare conversations are the risky ones. A mishandled responsible-gambling signal, a wrong answer about a withdrawal, a bonus promised that the terms don't allow — each is below 1% of volume and very likely to fall outside a 2% random sample.
Why CSAT doesn't close the gap
The end-of-chat survey looks like coverage but isn't. Response rates are typically in the single digits; unhappy players often skip it and complain to their VIP manager or by email instead. And CSAT measures emotion, not correctness: in iGaming the player's mood is dominated by things support doesn't control — a losing session, a KYC document rejected again, a deposit limit doing exactly its job. We go deeper into this on our measurement page.
What quality control software should actually do
- Encode your rubric, not the vendor's. Every operator already has a QA protocol. The software should turn that scorecard into a structured evaluation, so there's no new definition of "good" to negotiate internally.
- Score 100% of conversations — chat, email and voice transcripts — instead of a sample.
- Score human agents and AI on the same scale. If you are automating Tier-1, the only meaningful comparison is like-for-like.
- Require evidence. Every score below the top anchor comes with a note pointing to the message that caused it, so coaching is specific and disputes are short.
- Slice everything by topic, language, brand, agent and shift.
- Surface the conversations a human should read — low scores, risk topics, disagreement between graders — rather than a random sample.
- Feed releases and rollbacks. For AI support, the quality score is the release gate per topic and the trigger for rolling one back.
A five-dimension rubric for humans and AI
This is the rubric we built together with an operator's quality manager. It is deliberately short, it applies equally to a human agent and an AI agent, and each dimension maps to a different kind of failure:
| Dimension | The question it answers | Typical failure it catches |
|---|---|---|
| Intent | Was the request understood? | Answering the bonus question when the player was asking about a withdrawal |
| Action | Were the right account checks and actions done — or correctly none? | Quoting terms without checking open bets; crediting a bonus the player wasn't eligible for |
| Escalation | Was it neither over- nor under-escalated? | Missing an RG signal; handing off a simple status question |
| Resolution | Was the issue solved, or correctly handed off? | Polite chat, no outcome; same player back within 24 hours |
| Dialog | Tone, register and language quality in the brand's voice | Wrong formality for the market; robotic or overfamiliar replies |
Use an anchor scale, not a slider. Four anchors — 100, 95, 70, 50 — are enough to separate "perfect", "minor issue", "real problem" and "failure", and they make two reviewers far more likely to agree than a 1–100 free choice. The overall score is a simple mean; anything below 100 requires an evidence note.
Keep the roles separate. The person scoring quality should not be the person approving the AI's actions. In practice: administrators, supervisors who approve, and QC reviewers who score but cannot approve.
Gate on every dimension, not the average
Operators commonly set 85% as the minimum acceptable score and 85–90% as good. The trap is applying that to the average.
A system averaging 88% but scoring 72% on escalation does not pass.
An average can be lifted by excellent tone while a dangerous weakness hides in one dimension. So the release gate is per dimension — for example, at least 85% on every dimension for two consecutive weeks with the overall score trending towards 90% — and the bar can be stricter on responsible-gambling-adjacent topics than on password resets, because the cost of a wrong answer isn't the same.
Gates also need floors for rollback: if any single dimension drops below, say, 80% on the weekly sample, the affected topic goes back to humans until the cause is found.
Who grades the grader?
An automated evaluator is only worth what its agreement with your QA team is worth. This is the step that separates quality control software from a dashboard of flattering numbers — and we learned it the hard way.
An early automated scorer we built reported almost 99% quality. It was an artefact. It was effectively comparing the bot with itself: tone was checked against the bot's own template phrases, and some measurements were hard-coded. Once it was rebuilt to score against real operator transcripts, the honest figure at that stage was in the low 70s. Same system, same conversations — the only change was what the grader was compared to.
The rules we adopted afterwards apply to any QC software you evaluate:
- Always score against a human baseline. Your QA team hand-scores a set of real conversations first; the automated grader's agreement with them is measured and reported before it is trusted with anything.
- Never use string similarity on response text as a quality measure — two correct answers can share few words, and a wrong one can share many.
- Never score tone by counting template keywords. It rewards the bot for sounding like itself.
- Separate safety passes from under-service. When the AI correctly refuses an action a human agent took against policy, that is a pass, not a mismatch.
- Measure inter-rater agreement between your own reviewers too. A rubric two humans can't agree on can't be automated.
- Size samples honestly. Twenty conversations cannot support a per-language claim.
The hand-labelled set that comes out of this calibration is valuable. It should stay with the operator and become a regression test that every future model, prompt or knowledge-base change must pass.
Building the evaluation set
For AI support, quality control also needs an offline test set to run before anything ships. A good one has four properties:
- Stratified by intent, language, resolution type (resolved, pending, escalated) and period — using detected language, not the export's language field.
- Oversampled on risk. Responsible-gambling and complaint cases are rare but false negatives there are expensive, so they get more than their share.
- Full action chains, not Q&A pairs. Each case records the expected account reads, rule checks and writes alongside the expected reply, so "said the right thing but did the wrong thing" is caught.
- Multiple checks per run: key-content coverage, factual correctness judged against policy, consistency across repeat runs, and latency.
A set in the low thousands of conversations, re-run on every change with slice-level reporting, catches the regressions that a weekly manual sample never would.
Auto quality control, built on your scorecard.
Every conversation — AI and human — graded against your own QA protocol, calibrated against your QA lead first.
Drift: caught, not discovered
Quality changes over time even when nobody touches the AI. A knowledge-base edit quietly breaks an answer; a new promotion introduces terms the agent hasn't seen; player behaviour shifts after a product change. With 100% scoring broken down by topic, language and shift, these show up within the week as a drop in one slice — instead of three months later as a complaint trend.
It also answers the question every board asks after the third month: is this still as good as when we bought it? Without continuous quality control, the honest answer is a shrug and a CSAT score almost nobody filled in.
Buyer's checklist for QC software
| Ask | Good answer | Red flag |
|---|---|---|
| Whose rubric is scored? | Yours, encoded from your existing scorecard | A fixed vendor rubric you can't change |
| How is the grader validated? | Agreement with your hand-labelled set, reported before go-live | "Our model is very accurate" |
| Are humans and AI scored the same way? | Same rubric, same scale, same reports | Separate metrics for AI |
| Is the release gate per dimension? | Yes, with rollback floors per topic | One overall score |
| Is every low score explained? | Evidence note linked to the message | A number without a reason |
| Can I break it down? | Topic, language, brand, agent, shift | Global averages only |
| What do I keep at contract end? | The labelled set, in a usable format | "Proprietary benchmark" |
Our free buyer's guide extends this into twelve questions for any support-AI vendor — including us.
The short version
Quality control software for iGaming support should do one thing well: apply the standard your QA team already trusts to every conversation, and prove that it applies it the way your QA team would. Coverage goes from about 2% to 100%; human agents and AI are measured on one scale; releases and rollbacks follow the numbers. It is the foundation that makes automating iGaming customer support safe, and a core part of AI player support for iGaming operators done properly.
Frequently asked questions
What is support quality control software?
Support quality control software evaluates customer conversations against a quality rubric, either by assisting human reviewers or by scoring conversations automatically. In iGaming, the useful kind encodes the operator's own QA scorecard and applies it to every chat, email and call, for both human agents and AI, with results broken down by topic, language, agent and shift.
What percentage of support conversations should be QA-reviewed?
Manual programmes typically review between 1% and 3% of conversations because human reviewers are expensive. Automated scoring makes 100% coverage practical, with humans reviewing a calibration sample and the low-scoring or high-risk conversations the system surfaces.
Is CSAT enough to measure support quality?
No. CSAT measures emotion rather than correctness, reflects outcomes support doesn't control (losing sessions, KYC rejections, RG limits working as intended) and usually has a single-digit response rate dominated by very happy and very unhappy players. Track it, but don't build quality evaluation on it.
Can an AI grade support conversations accurately?
Yes, if it is calibrated. An LLM grader should be checked against a set of conversations scored by hand by your QA team, with its agreement rate reported before it is trusted. Without that step, automated scores tend to be inflated, especially if the system is effectively grading itself.
What should be on an iGaming support QA scorecard?
At minimum: whether the request was understood, whether the right account checks and actions were taken, whether the escalation decision was correct, whether the issue was resolved or properly handed off, and tone and language quality in the brand's voice. Operators often add identity verification, correct policy quotation and responsible-gambling handling as explicit items.
Last reviewed 8 October 2026. Figures marked as industry ranges are ranges, not Arctura claims; operator-specific numbers are only quoted after validation on the operator's own baseline.
