What makes a good support QA check?

A good support QA check is specific enough that two reviewers reading the same conversation reach the same answer. It has a short name, a plain-language definition, an exact fail condition, and worked examples of a pass, a fail and an edge case. It also says when it applies, so it isn't scored on unrelated conversations.

Can AI build a QA rubric from your SOPs?

AI can help draft checks from a sample of past conversations and your existing QA guidelines, and it can refine a check's wording against a policy or SOP document. Your team should still review, edit and approve every check before it's used, and test each one on real past conversations to confirm it matches how you want quality judged.

How do you update a QA rubric when a policy changes?

Link every check to the policy and section it came from, and name an owner for each. When a policy changes, the owner updates the check's definition, adds an example that reflects the new rule, and tests it on past conversations before it goes live. Note the date and reason beside the policy.

How do you QA steps that happen outside the conversation, like refunds?

Grade what the agent said about the step, such as confirming the refund amount, payment method and timeline, against your policy. Write the check around those statements so reviewers can confirm it from the transcript. Confirm that the refund itself was processed through your billing or operations reporting.

How many checks should a support QA rubric have?

Start with the checks for your highest-risk policies and your core competencies, and add more only when a review shows a gap. A rubric reviewers can keep in their heads is easier to apply consistently. Use not-applicable rules so each conversation is scored only on the checks that fit it.

How to turn your SOPs and policies into a support QA rubric

Last updated October 8, 2026. Written by unitQ, which makes unitQ Support QA, an independent grader for support conversations. This is a vendor-neutral, practical how-to; it names no QA vendors.

To turn SOPs and policies into a support QA rubric, break each document into the specific behaviors a support conversation can show, then write each behavior as a check with a plain-language definition, a clear fail condition and worked examples. Mark when each check applies, group and weight the checks, and try them on real past conversations before you grade anyone. Keep every check linked to the policy it came from, so the rubric changes when the policy does.

Quick answer

Start from the documents your agents already follow: SOPs, policies, knowledge base articles and compliance rules.
Pull out only the behaviors a conversation can show.
Write each one as a check with a definition, a fail condition and examples.
Say when each check applies, and leave it out of the score when it doesn’t.
Test checks on past conversations, then keep each one tied to its source policy.

What you need before you start

Gather the documents that define good support today, and name an owner for each one. You’ll need:

Standard operating procedures for each contact type, such as refunds, cancellations, account changes and outages.
Policies that set limits, such as refund windows, credit limits, identity requirements and privacy handling.
Knowledge base articles that agents and AI agents use to answer questions.
Compliance requirements from legal or risk, including required disclosures.
Brand and tone guidelines, if you have them.

If two documents disagree, settle it before you write checks. A rubric built on conflicting policies will fail agents for following one of them.

Step 1: Prioritize the policies that show up in conversations

Start with the policies that customers and agents touch most often and the ones where a miss is most costly. Put regulated steps such as identity verification and required disclosures first, followed by the processes behind your highest-volume contact reasons.

Leave internal-only procedures for later. A policy about how agents file tickets internally won’t show up in the conversation the customer sees.

Step 2: Extract behaviors a conversation can show

Read each SOP and pull out the behaviors that would be visible in a transcript. A QA rubric grades the conversation, so every check has to be something a reviewer can confirm or reject by reading it.

Some SOP steps happen in another system, such as issuing a refund in a billing tool. For those steps, grade what the agent said about the action: did they confirm the amount, the method and the timeline, and did that match the policy?

Rewrite vague SOP language into observable behavior:

SOP language	Observable behavior to check
“Verify the customer’s identity before account changes.”	The agent confirmed identity using an approved method before making or promising any account change.
“Set clear expectations on refund timing.”	The agent stated the refund amount, method and expected timeline, consistent with the refund policy.
“Escalate safety concerns immediately.”	When the customer mentioned a safety issue, the agent escalated using the defined path in the same conversation.
“Be empathetic.”	The agent acknowledged the customer’s problem in their own words before moving to the fix.

Step 3: Write each behavior as a check

Write every check so two reviewers reading the same conversation reach the same answer. A good check has four parts:

Name. Short and specific, such as “Refund timeline stated.”
Definition. One or two plain-language sentences describing what a pass looks like.
Fail condition. Exactly what counts as a fail, including common near-misses.
Worked examples. At least one pass, one fail and one edge case, quoted from real conversations with customer details removed.

Pay special attention to edge cases. If your refund policy allows exceptions for damaged items, include an example where the agent correctly applied the exception, so reviewers don’t mark it as a fail.

Step 4: Decide when each check applies

Not every check belongs in every conversation. For each check, write down when it applies, for example by contact reason or by a trigger in the conversation, such as an account change or a mention of a safety issue.

When a check doesn’t apply, mark it not applicable and leave it out of the score. That keeps a password-reset conversation from earning credit for a refund check it never had to pass, and keeps scores comparable across contact types.

Step 5: Group and weight the checks

Group checks into a few categories that match how your leaders think about quality, then weight the groups. One workable structure:

Group	Example checks	How to weight it
Competency	Correct answer, clear explanation, tone	Core of the score
Process	Required steps for the contact type	Weighted by contact reason importance
Compliance	Identity verification, required disclosures, privacy handling	Reported as pass/fail on its own as well as in the score
Outcome	Issue resolved correctly under your policy	Weighted to reflect what customers care about

Report compliance checks on their own as well as inside the overall score. A strong overall score shouldn’t hide a missed disclosure.

Step 6: Test the checks on past conversations

Before you grade agents, apply the new checks to a set of real past conversations and look for disagreement. Have two reviewers, or a reviewer and your AI grader, score the same conversations, then compare results check by check.

Where results disagree, start by checking the wording. Tighten the definition, add an example for the case that caused the split, and test again. Only turn a check on when it produces results your team agrees with.

See unitQ Support QA in action

A short demo of unitQ Support QA

Get a demo

Step 7: Keep the rubric in sync with policy

Link every check to the document and section it came from, and name an owner who updates the check when the policy changes. When legal changes a disclosure or operations changes the refund window, the owner updates the check, adds a new example, and tests it again before it goes live.

Note the date and reason for each change next to the policy, so a score drop after a policy change is easy to explain.

Policies for AI agents need checks too

If an AI agent answers customers, the same policies apply to what it says. Gartner advises customer service leaders to set AI interaction policies, developing “guidelines for AI-led interactions, addressing data privacy, security, and escalation” ¹.

Turn those guidelines into checks the same way, but keep them on the AI agent’s own bot rubric. AI agents fail in different ways than people do, such as loops, dead ends and confident wrong answers, so their rubric needs checks for those failures alongside your policy checks. Our guide to what AI agent QA is covers what a bot rubric should include.

A worked example: a refund SOP becomes four checks

Here’s how a hypothetical refund SOP turns into checks:

SOP excerpt: “Refunds are available within 30 days of purchase to the original payment method. Verify the order and the customer’s identity. Damaged items qualify regardless of date. Tell the customer the refund will arrive in 5 to 10 business days.”

Identity and order verified. Pass: the agent confirmed identity with an approved method and confirmed the order before processing. Fail: the agent promised a refund before verifying. Applies: refund requests.
Eligibility applied correctly. Pass: the agent approved refunds inside 30 days or for damaged items, and declined others with the policy reason. Fail: the agent approved an ineligible refund or declined an eligible one. Edge case: a damaged item at day 45 is a pass when approved.
Original payment method stated. Pass: the agent told the customer the refund goes to the original payment method. Fail: the agent offered or implied a different method.
Timeline stated. Pass: the agent said 5 to 10 business days. Fail: the agent gave no timeline or a different one.

Checks 1, 3 and 4 go in the process group, and check 2 goes in outcome. All four are not applicable on conversations that aren’t refund requests.

When a simple checklist is enough

A full rubric isn’t always worth building. A simple checklist fits when:

You have a small team handling a narrow set of contact types with few policy rules.
Your QA team reviews by hand, and a short checklist is all reviewers can apply consistently.
You’re piloting QA on one contact reason before rolling it out more broadly.

A structured rubric built from your SOPs fits teams with many contact types, regulated steps, outsourced or BPO teams that need identical criteria, or AI agents answering customers under the same policies.

How unitQ Support QA helps

unitQ Support QA is an independent grader that scores support conversations against a rubric your team owns.

Checks in plain language. Define each quality check in plain language: what it means, which answers count as a fail, and worked examples that show the edge cases. Your team owns and edits the rubric in Tag Studio in unitQ Support QA.
Refine checks against your documents. Attach your policy or SOP document as reference material and refine a check with AI.
Suggested starting points. Not sure where to start? unitQ Support QA can suggest draft checks from a sample of your own conversations, and your existing QA guidelines if you add them. Your team reviews, edits and approves every check before it’s used.
Try before it goes live. Testbench in unitQ Support QA lets you try a check on real past conversations before it goes live. Edit and refine checks as often as you need before the changes go live.
Weighting and applicability. Weight rubric groups to match how you score quality. Write when a check applies into its definition, including a not-applicable value; checks that don’t apply to a conversation are left out of the score.
Compliance and process checks. Grade the compliance and process checks you define, such as identity verification, privacy handling or a required disclosure, as pass/fail. Flag missed steps that show up in the conversation, such as a skipped identity check, a required disclosure that wasn’t given, or an escalation that should have happened, checked against the process you define ².
Evidence and coverage. Every scored miss links back to the conversation behind it, and unitQ Support QA scores the conversations you connect, not a sample.