18项客户支持质量保证检查清单

快速答案

打开Transcript前先定义目的与样本。只评可观察证据，允许“Not Scorable”，把Critical Failure与Weighted Coaching Item分开，并保留Source、Reviewer与Decision Trail。让Reviewer用同一案例校准。分别分析QA、CSAT与运营速度，再分配纠正工作并验证Customer-Visible Outcome是否改善。

评分对象Interaction、System、Policy与最终Customer-Visible State中实际发生的内容。

允许弃权语境缺失不是零分；记录无法评分的原因。

闭合循环把重复失败转为有Owner的行动，并验证效果。

Reviewer可辩护的评分方法

评分前定义

为每个Criterion、Evidence Rule、Weight、Critical-Failure Rule、Scorable Population与Review Period设版本；不能看到某团队/Agent得分低后再调Rubric。

使用四种结果

使用Pass、Fail、Partial与Not Scorable，并给Criterion-Specific Anchor。缺失Transcript Segment不等于已观察失败；保留Reviewer Confidence与Evidence Link。

区分闸门与辅导

Security、Privacy、Unauthorized Financial Action与Fabricated Information可设为Mandatory Failure，即使加权分高也不放行；Coaching Item用于改进，但不能把不安全会话判为可接受。

最低复核记录

review_id · purpose · population · sampling_method · conversation_id · channel · locale · human_or_ai · rubric_version · criterion_id · outcome · evidence_pointer · reviewer · confidence · critical_failure · disagreement · calibration_set · appeal · corrective_action · owner · due_date · effectiveness_check

18项客户支持QA检查清单

每项控制都说明检查对象、可支持评分的证据及不通过条件。应按服务调整Anchor，不要把每句话机械转换成等权重Checkbox。

范围与抽样有效

评分前确认Channel、Queue、Language、Product、Customer Tier、Human/AI Participation、Review Window、Eligibility Rule与Sampling Method。仅抽取Escalation的方便样本不能代表团队质量。

评分证据: 可重现Population与Ticket ID；Exclusion；Random/Stratified Selection；Reviewer Assignment；Comparison Dimension。
不通过条件: 若样本被挑选、重复项被隐藏，或结论外推到定义总体之外，则不通过。

监控透明且数据最小化

记录质量监控目的；在要求时通知员工和客户；Reviewer/Model只接收该目的所需字段。Credential、Payment、Health、Secret与Restricted Investigation须分离。

评分证据: Notice/Purpose；适用的Lawful/Contractual Basis；Field Inventory；Access Role；Retention/Deletion；Redaction Test。
不通过条件: 秘密监控、过度收集、未经复核改变用途，或把不必要敏感叙述发送给AI，均不通过。

记录保留完整交互语境

复核Customer Message、Prior Thread、Channel、Timestamp、Attachment、Automation Event、Ownership Change与Final State。不能把一句Agent回复当作完整Interaction评分。

评分证据: Immutable Transcript/Recording Reference；Event Timeline；Actor Type；Edit；Missing Segment；Channel Constraint；Final State。
不通过条件: 语境缺失却仍推断Intent、Fault、Response Time或Resolution时不通过；应标记Not Scorable。

识别客户需求与期望结果

用可链接证据写明Customer Task、Affected Object、Expected/Observed Result、Urgency与Requested Outcome；当表面请求与底层问题不同时须分开。

评分证据: Quoted/Timestamped Evidence；Normalized Issue；Affected Account/Order/Workspace；Desired Outcome；Uncertainty；Competing Interpretation。
不通过条件: 编造目标、把多个Issue压成一个，或用Sentiment代替Problem Definition时不通过。

事实与操作指引准确且有依据

核对回复时有效的Product Behavior、Account State、Policy Version、Knowledge Version与Tool Result；区分Verified Fact、Reasonable Hypothesis与Unknown。

评分证据: Source Link/Version；Account/Tool Evidence；Retrieval Time；Quoted Policy；Calculation Input；Confidence；Correction Trail。
不通过条件: 捏造功能、过期步骤、无依据因果、虚构Tool Result，或证据不可用仍确定回答，均不通过。

重大假设前先澄清

当Identity、Product Version、Jurisdiction、Account State、Date、Scope或Desired Remedy会改变答案时，行动前只问最少必要问题；已有数据不要重复索取。

评分证据: Decision-Changing Ambiguity；Question；Available Context Check；Answer；Safe Temporary Path；No-Response Handling。
不通过条件: 基于重大假设行动，或提出不影响Routing/Resolution的无关问题造成摩擦时不通过。

正确应用政策、资格与例外

使用适用于该Customer、Event Date、Region、Plan与Request的Policy/Product Terms；说明关键条件，并路由Exception，而不是静默拒绝或批准。

评分证据: Policy ID/Version/Effective Date；Eligibility Input；Exception Path；Decision Owner；Customer Explanation；Conflict Record。
不通过条件: 把通用规则套到错误日期/地区、编造例外，或把Policy Language当法律意见时不通过。

控制身份、权限与敏感操作

只做必要级别的Identity Verification，使用批准Channel并遵守Role Permission；Refund、Deletion、Credential Change或Irreversible Action需要额外授权；不得在Free Text索取Secret。

评分证据: Verification Method/Result；Actor/Role；Permission Check；Action Preview；Approval；Idempotency Key；Audit Event；Rollback。
不通过条件: 过度验证、收集Secret、提权、未批准执行、重复执行或跨客户泄露数据时不通过。

严重度、优先级与路由符合证据

根据Impact、Urgency、Affected User、Workaround、Security/Privacy Signal、Service State与Contractual Commitment分类；保留不确定性并使用当前Routing Matrix。

评分证据: Severity Input；Priority Rule/Version；Affected Scope；Incident Link；Specialist Queue；SLA Target；Override/Approver。
不通过条件: 仅因语气激烈提高Severity、因语气平静漏掉严重Incident，或用AI Confidence替代Specialist Review时不通过。

回复首先给出直接可执行的下一步

开头给出Answer、Current State或Next Required Action；Prerequisite放在Command前，步骤有序，明确谁执行，并区分Required/Optional。

评分证据: First-Response Answer；Ordered Step；Prerequisite；Owner；Expected Observable Result；Stop Condition；Alternative Path。
不通过条件: 客户需在长前言中寻找动作、指令顺序错误，或成功状态不可观察时不通过。

语气尊重、具体且不表演

承认具体Inconvenience/Risk，但不虚构感受、责任、确定性或亲密关系；匹配Urgency/Channel，同时保持专业和包容。

评分证据: Customer Impact Acknowledged；Neutral Ownership；有事实基础的Apology；No Blame；No Manipulative Reassurance。
不通过条件: 套话式共情拖延帮助、无法兑现承诺、与客户争辩，或带有刻板印象/羞辱的语言时不通过。

语言清晰、可访问且本地化正确

使用短句、描述性Link、有意义Heading、Text Alternative与受众熟悉术语；翻译Task/Policy含义而非逐词替换，并保留Locale特定Date、Currency与Support Route。

评分证据: 适合受众的Reading Level；Glossary；Locale Reviewer；Link Purpose；Attachment Alternative；Date/Timezone；Accessible Channel。
不通过条件: 术语遮蔽动作、机翻改变资格/安全含义，或必要信息只存在于不可访问图片/音频时不通过。

责任与交接保持连续

明确Current Owner、Destination Team、Reason、Evidence Package、Expected Response与Fallback；已授权传递的信息不让客户重复。

评分证据: From/To Owner；Transfer Time；Reason；Evidence/Permission；Receiving Acknowledgment；Customer Notice；Fallback/Escalation Timer。
不通过条件: 盲转、无人Ticket、循环路由、冲突承诺，或向接收角色暴露非必要数据时不通过。

时间与状态预期真实

给出可衡量的Next-Update Time/Event及Timezone，并区分Internal Target与Contractual Commitment；错过期限前更新并解释假设变化。

评分证据: SLA/Target Source；Due Time/Timezone；Dependency；Current State；Next Update；Breach Warning；Revised Commitment/Owner。
不通过条件: 只说“很快”无检查点、无权限保证解决日期、静默错过期限，或错误暂停SLA计时时不通过。

解决完整并依据原始需求验证

确认Requested Outcome或Agreed Alternative已实现，而不是仅有Agent Reply或Tool Success；验证Customer-Visible State并覆盖每个Issue Unit。

评分证据: Action Result；Before/After State；Customer-Visible Verification；Unresolved Issue List；Acceptance Evidence；Reopen Path。
不通过条件: 把Backend Success当客户成功、忽略多个问题之一，或在必要Propagation/Confirmation前关闭时不通过。

临时方案与升级安全且有边界

说明Workaround改变什么、谁可使用、期限、副作用、Monitoring与Reversal；Security、Privacy、Legal、Financial、Health、Safety或Irreversible Case走批准的Specialist Route。

评分证据: Risk Classification；Allowed Audience；Expiry；Side Effect；Monitoring；Rollback；Specialist Acceptance；Emergency Stop。
不通过条件: Workaround绕过控制、未经复核变永久、掩盖Incident，或诱导超越Agent权限的不安全操作时不通过。

AI参与、不确定性与人工权限可见

识别哪些Reply、Summary、Score、Tag或Action来自Automation；对重大用途保留Model/Version、Input、Evidence Link、Confidence/Abstention、Reviewer Decision与Override Reason。

评分证据: Actor Type；适用的Model/Prompt/Workflow Version；Retrieved Source；Proposed Score；Human Decision；Override；Incident/Rollback。
不通过条件: 把AI Output当已验证证据、同一模型无独立复核自评，或自动化越过批准边界执行重大动作时不通过。

关闭、反馈与学习形成受控闭环

总结What Changed、What Remains、Reopen/Escalate方式及Feedback时间；只向Eligible Interaction发送CSAT，并把Response Rate/Selection Bias与QA分开；重复失败转为有Owner的Coaching、Content、Product或Control Work。

评分证据: Closure Summary；Unresolved Item；Reopen Route；Survey Eligibility/Time；Response Denominator；Action Owner；Due Date；Effectiveness Check。
不通过条件: 关闭掩盖未解决工作、把Survey Score当全部事实、脱离语境惩罚性使用反馈，或改进行动无Owner/Verification时不通过。

校准案例：两位Reviewer基于合理原因产生分歧

本假设案例用于说明方法，不是OpenMax结果。客户要求撤销重复订阅扣款。Agent确认问题、通过批准方式验证账户、发现两笔已Capture扣款并提交一笔Refund，但称“明天到账”；实际Payment Rail提供的是多日预计时间，且未记录Follow-Up Owner。

Reviewer A：基本解决。 请求的Financial Action已授权并仅执行一次；Identity、Evidence与Idempotency通过，Tone与Directness也通过。
Reviewer B：预期管理失败。 “明天”无依据，遗漏Payment Rail Estimate，且没有Owner/Checkpoint。因此Time/Status与Closure失败，Operational Record为Partial。
校准决定。 两个观察都保留，不把Interaction折成一个模糊平均分。Scorecard记录Refund成功、错误时间承诺、缺失Follow-Up Control及仍需完成的Customer-Visible Verification。
纠正行动。 更新Response Template以插入Rail-Specific Estimate，要求Next-Check Date与Owner，并抽样后续案例验证新控制，而不只记录“已安排培训”。

运营QA体系，而不只是清单

校准并衡量分歧

使用稳定的Ordinary、Edge与High-Risk Case集合；独立复核、比较Criterion-Level Decision、裁决分歧、前瞻性调整Anchor，并监控Human-Human与Human-AI Agreement。Agreement不等于Correctness，需保留Expert Ground Truth与Appeal。

报告分母与不确定性

报告Eligible、Sampled、Scorable、Not Scorable、各Criterion的Pass/Partial/Fail、Critical Failure、Reviewer Disagreement、Appeal、Corrective Action与Verified Follow-Up。按Channel、Locale、Product与Human/AI Participation谨慎分段，避免给小样本排名。

把发现连接到有责任人的变更

把Defect路由给Coaching、Knowledge、Policy、Product、Workflow、Staffing、Accessibility、Localization、Security或Privacy Owner；设置Acceptance Evidence与Due Date；发布后重抽可比样本，并区分Correlation与Causal Improvement。

OpenMax如何协调支持QA

OpenMax可冻结Eligible Sampling Frame、创建Minimized Review View、汇集Transcript/System Evidence、以Evidence Pointer建议Criterion Outcome、在语境不足时Abstain、把Critical Finding路由给Human、记录Override/Appeal、分配Corrective Work并监控可比Follow-Up Sample。Rubric Ownership、Worker/Privacy Decision、Specialist Judgment、Employment Consequence、Customer Remedy与Final Acceptance由人负责。

1 · 界定Purpose、Population、Sample、Notice、Rubric Version

2 · 汇集Minimized Transcript、Timeline、Policy、Tool与Outcome Evidence

3 · 建议Criterion Outcome、Evidence Pointer、Uncertainty/Abstention

4 · 复核Calibrated Human Decision、Critical Route、Override与Appeal

5 · 改进Owned Corrective Action、Acceptance Evidence与Comparable Re-sample

隐私、公平与解释边界

不得把QA作为未披露监控。监控前定义必要性/比例性、提供所需通知、适当时咨询受影响员工、最小化访问并设置Retention。
不得从Voice、Accent、Writing Style或Sentiment推断Protected Trait、Emotion、Honesty或Intent；只评Observable Service Behavior与Validated Operational Evidence。
无Comparable Population、Adequate Denominator、Calibration、Uncertainty与Appeal Route时，不对Agent、Vendor、Locale或AI System排名。Score是Decision Input，不是Ground Truth。
CSAT Response Rate、Satisfaction Score、QA Pass Rate、First Response Time、Resolution Time、Reopen Rate与Business Outcome衡量不同对象；没有适当设计不得拼成因果故事。

来源、编辑方法与限制

OpenMax编辑复核Intercom当前Conversation Rating Eligibility/Reporting Definition、NIST AI RMF关于Role/Measurement/Human Oversight/Monitoring的结果、英国ICO员工监控指南及Call Center案例，以及W3C WCAG 2.2无障碍要求；再原创综合18项控制、Evidence Anchor、Failure Condition与Calibration Case。资料于2026年9月3日复核。

范围说明 Vendor报告定义描述其自有产品；NIST AI RMF是自愿指南；ICO指南针对英国数据保护预期；WCAG针对无障碍。它们均不认证本Rubric、不制定通用Employment Policy，也不证明Business Outcome。实际部署需取得适当的Privacy、Legal、Labor、Security与Accessibility Review。

常见问题

CSAT等于质量保证吗？

不。CSAT反映符合资格且选择回应的客户反馈；QA把定义好的Rubric应用于抽样Interaction Evidence。Survey Response Denominator、QA Sample与Scorable Population要分开报告。

18项应该等权吗？

通常不应。应事先设置Criterion-Specific Anchor与Weight；选定的Security、Privacy、Accuracy或Unauthorized-Action Failure应作为Gate，不能被高Tone分平均掉。

AI能给所有会话评分吗？

可对证据充分且获准的案例提出结果；遇到Missing/Restricted Context必须Abstain，显示Evidence/Uncertainty，并把重大结论路由给经校准的Human Review，保留Override/Appeal。

应复核多少会话？

没有通用数量，取决于Decision、Volume、Variation、Risk、Desired Precision、Strata与Reviewer Capacity。应公布Eligible Population、Selection Method、Sample、Not-Scorable Count与限制，而不是把方便数字说成有代表性。

QA发现如何改进服务？

把每个重复失败分配给对应的Coaching、Knowledge、Policy、Product、Workflow、Staffing、Localization、Accessibility、Security或Privacy Owner，并定义Acceptance Evidence、Due Date与Comparable Follow-Up Sample。