- Score five dimensions — Intent, Action, Escalation, Resolution, Dialog — each with four written anchors: 100, 95, 70, 50.
- Every score below 100 needs an evidence note pointing to the message that caused it.
- Auto-fail items — a missed RG signal, wrong financial information, a bonus promised outside the terms — fail a conversation regardless of its average.
- Gate on every dimension (for example 85%+ for two consecutive weeks), not on the average, and set rollback floors.
- Calibrate reviewers on a shared set before trusting the numbers, and use the same scorecard for human agents and AI.
Most customer support QA scorecard templates are written for retail or SaaS: greeting used, name spelled correctly, empathy statement present. In iGaming those boxes miss the failures that actually cost money and licences — a missed responsible-gambling signal, a wrong withdrawal date, a bonus promised that the terms don't allow. This article gives you an iGaming support QA scorecard you can use from Monday: five dimensions, four anchor scores with definitions, auto-fail items, and a free CSV template.
It is the same rubric we describe in our guide to iGaming support quality control software, unpacked into a working tool. It scores human agents and AI agents on the same scale, on purpose.
Download the scorecard template (CSV) — one row per conversation, opens in any spreadsheet.
Four design principles
- Few dimensions, each catching a different failure. Five is enough. Every extra dimension lowers agreement between reviewers and adds time to every review.
- Anchors, not sliders. Four fixed scores — 100, 95, 70, 50 — with written definitions. Two reviewers asked "was this a 70 or a 95?" agree far more often than two reviewers asked to pick a number between 1 and 100.
- Evidence for every deduction. Anything below 100 needs a note pointing to the message that caused it. No note, no deduction.
- One scale for humans and AI. If you are automating Tier-1, the only comparison that means anything is like-for-like.
The five dimensions and their anchors
Each dimension answers one question. The anchors below are the definitions we hand to reviewers; adapt the wording to your own protocol, but keep the four levels.
| Dimension | 100 — perfect | 95 — minor issue | 70 — real problem | 50 — failure |
|---|---|---|---|---|
| Intent Was the request understood? | Understood first time, including the implied question | Understood after one unnecessary clarifying question | Partly understood; answered a neighbouring question | Answered a different question entirely |
| Action Right checks and actions — or correctly none? | All required account checks done; actions correct and within policy | Correct outcome, one check done late or in the wrong order | A required check skipped, e.g. terms quoted without checking open bets | Wrong action taken, or an action outside policy |
| Escalation Neither over- nor under-escalated? | Handed off exactly when required, with full context | Correct handoff, context incomplete | Unnecessary handoff of a simple case | Required handoff missed |
| Resolution Solved, or correctly handed off? | Resolved, or correct handoff with an honest timeline | Resolved, but the player had to ask for the next step | No clear outcome; the player is likely to write again | Unresolved, or the player was misinformed |
| Dialog Tone, register, language quality | Natural, correct register for the market and the brand | Small slips: repeated phrase, slightly stiff wording | Wrong formality, robotic or overfamiliar | Rude, dismissive, or in the wrong language |
The overall score is the simple mean of the five. Don't add hidden weights at this stage: the gates below do the job that weights usually try to do, and they are easier to explain to agents.
Scoring real iGaming contacts
Anchors only work if reviewers see them applied. Three typical cases:
Withdrawal status, answered well but generically
The player asks where their withdrawal is. The agent checks the request, confirms it is within the processing window, and replies with the published timing but no expected date. Intent 100, Action 100, Escalation 100, Resolution 95, Dialog 100. Evidence for Resolution: "no expected date given; player had to ask 'so when?'". For the full anatomy of this contact, see automating withdrawal and KYC questions.
Bonus question, terms quoted without a check
The player asks why their bonus balance can't be withdrawn. The agent pastes the wagering terms correctly but doesn't check that an open bet is holding the requirement. The player writes again the next day. Intent 100, Action 70, Escalation 100, Resolution 70, Dialog 100. Overall 88 — a respectable average that hides two real problems, which is exactly why the gates are per dimension.
Deposit complaint with a distress signal
"My deposit didn't arrive, I have nothing left, I need it back today." The agent handles the deposit query competently and stays polite. It does not route the conversation to the senior queue. Escalation 50, and the conversation fails outright on an auto-fail item regardless of its average. The detection side of this case is covered in responsible gambling signals in support chats.
Auto-fail items
Some failures are serious enough that no average should hide them. Mark these as a separate yes/no field; any "yes" fails the conversation and goes to the weekly review:
- Responsible-gambling signal missed — distress, loss-chasing, self-exclusion requests or requests to lift one, not routed to the right people.
- Wrong financial information — incorrect amount, balance, withdrawal date or fee stated as fact.
- A bonus or outcome promised that the terms don't allow, or any promise of a timeline nobody has committed to.
- VIP handled outside their agreed route.
- Personal data disclosed to someone who wasn't verified as the account holder.
- A compliance hold explained — telling a player why their account or payout is under review.
An auto-fail is not a low score. It is a separate signal, and it is reviewed by a person every time.
Gates, not weights
The common target is 85% as the minimum acceptable score and 85–90% as good. Apply it per dimension, not to the average: a team averaging 88% with Escalation at 72% does not pass. A practical set of gates:
- Release or sign-off gate: every dimension at 85% or above for two consecutive weeks, overall trending towards 90%, zero auto-fails.
- Rollback floor: any dimension below 80% on the weekly sample sends the affected topic back to humans (for AI) or into coaching (for a team) until the cause is found.
- Stricter bars on risky topics. Responsible-gambling-adjacent and payment topics can require more than password resets do, because the cost of a wrong answer isn't the same.
This scorecard, applied to 100% of conversations.
PlayerDesk encodes your own QA protocol and grades every chat, email and call — AI and human — calibrated against your QA lead first.
Calibrating reviewers
A scorecard is only as good as the agreement between the people using it. Before you trust any number it produces, run a calibration round:
- Pick a shared set of conversations that covers your main topics and languages, including a few difficult ones.
- Score independently. Every reviewer scores every conversation without seeing the others' scores.
- Measure agreement per dimension — how often reviewers land on the same anchor, or a chance-corrected statistic such as Cohen's kappa if you want rigour.
- Discuss the disagreements, not the agreements. Most come from an ambiguous anchor definition; rewrite it and add the disputed conversation as a worked example.
- Repeat until agreement is stable, then re-run calibration every quarter and whenever a new reviewer joins.
The same procedure validates an automated grader. Treat it as one more reviewer: it only earns trust once its agreement with your QA lead is measured on a hand-scored set. A rubric two humans can't agree on can't be automated either.
Sample sizes that support a claim
Manual QA typically reviews around 2% of conversations, which is enough for coaching individuals and not enough for anything else. Rough rules of thumb:
- Twenty conversations is an anecdote. It cannot support a claim about a language, a topic or an agent.
- Slice before you sample. If you want to compare Spanish with German, or AI with humans, sample enough in each slice; a large overall sample can still be tiny per slice.
- Oversample risk. Responsible-gambling and complaint conversations are rare; a random sample will mostly miss them, so pull them deliberately.
- Read what the data flags — low scores, auto-fails, long conversations, repeat contacts within 24 hours — rather than a purely random set.
Once every conversation is scored automatically, sampling stops being about coverage and becomes about auditing the grader — a much better use of a QA team's week. See our measurement page for how we report it.
Using the CSV template
The template has one row per conversation and these columns:
| Column | What goes in it |
|---|---|
| conversation_id, date, channel | Your helpdesk reference; chat, email or voice |
| language, brand | Detected language, not the helpdesk's language field |
| agent_type | human or ai — the same rubric for both |
| topic | Your intent label, e.g. withdrawal_status, bonus_wagering |
| intent … dialog | One anchor per dimension: 100, 95, 70 or 50 |
| overall | Mean of the five |
| auto_fail, auto_fail_reason | yes/no plus the item from the list above |
| evidence_note | Required for every score below 100, with the message number |
| reviewer | Who scored it — needed for calibration |
Three example rows are included. A pivot table by topic, language and agent type gives you the per-dimension view the gates need.
The short version
A good iGaming QA scorecard is short and strict: five dimensions, four anchors with written definitions, evidence for every deduction, auto-fail items for the failures that matter in this industry, and gates applied per dimension. Calibrate reviewers before trusting the numbers, size samples per slice, and use one scale for people and AI. When you're ready to apply it to every conversation instead of a sample, read our guide to quality control software, or start from the pillar on AI player support for iGaming operators.
Frequently asked questions
What should an iGaming customer support QA scorecard include?
A small number of dimensions that each catch a different failure: whether the request was understood, whether the right account checks and actions were done, whether escalation was correct, whether the issue was resolved, and tone and language quality. Add written anchor definitions, a required evidence note for deductions, and auto-fail items for responsible gambling and financial errors.
Why use anchor scores instead of a 1 to 10 or 1 to 100 scale?
Fixed anchors with written definitions, such as 100, 95, 70 and 50, make reviewers agree far more often than a free numeric scale, because each choice corresponds to a described situation rather than a feeling. Higher agreement makes the scores usable for coaching, release gates and automated grading.
What are auto-fail items in support QA?
Failures serious enough that a good average should never hide them. In iGaming they typically include a missed responsible-gambling signal, wrong financial information stated as fact, a bonus or outcome promised outside the terms, a VIP handled outside their route, personal data disclosed to an unverified person, and explaining a compliance hold.
Can the same QA scorecard be used for AI and human agents?
Yes, and it should be. Scoring both on the same rubric and scale is the only way to compare them like-for-like, decide which topics an AI agent can handle, and detect when quality drifts on either side.
How many conversations should be reviewed for QA?
Enough per slice you want to make a claim about. Twenty conversations cannot support a statement about a language, topic or agent. Sample each slice separately, oversample rare high-risk topics such as responsible gambling and complaints, and prioritise conversations flagged by low scores or repeat contacts.
Last reviewed 9 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.
