客服工单怎么接入 AI？从来信分流到回复草稿的六步工作流

本文目录

客服团队第一次接入 AI，最容易从“自动回复客户”开始。这个目标看起来直接，却把分类、查订单、找政策、判断例外和对外发送压在了同一个黑盒里。一旦回复错了，团队很难判断问题出在知识、权限、模型，还是流程规则。

更稳妥的第一版，是先让 AI 完成来信理解与回复准备，把外发决定留给客服人员。这样既能减少查找和整理，也能从人工修改中得到真实的评测样本。

开始前先备齐四类材料

先想清楚底料，再谈模型。

不要只给模型一份 FAQ。可运行的客服工作流至少需要：

工单字段：客户、订单、产品、问题类型、优先级、当前状态、负责人和处理记录；
知识材料：产品说明、服务政策、标准话术、故障排查步骤，以及每份材料的版本与生效时间；
分流规则：哪些问题进入普通队列，哪些需要技术、财务、法务或主管处理；
动作边界：哪些信息只读，哪些字段可以写入，退款、改价、账号变更和对外承诺由谁批准。

Google Cloud 的客服生成式 AI 参考架构采用了客户问题、知识检索、基于材料生成解决方案的路径。这个结构可以作为底座，但企业落地时还要补上工单系统、权限、人工确认和异常队列。

第一步：接收并标准化来信

入口的格式千差万别，先统一。

邮件、网页表单、企业微信和电话转写的格式不同，先统一成一份内部工单对象。渠道接入、重复消息合并、附件类型校验、客户身份匹配和时间戳记录，优先使用确定性程序完成，不要让模型猜。

原始内容必须保留。清理签名、历史引用或格式噪声时，把处理后的文本与原文关联起来，方便客服复核。附件无法解析、身份无法确认或内容为空时，直接进入异常队列，不继续生成回复。

第二步：分类、提取与风险分流

读懂来信之后，下一步是结构化。

AI 适合从非结构化来信中识别意图、产品、订单号候选、故障现象和情绪信号，但它的输出应是结构化字段，不是直接决定后续动作。Microsoft 的客服邮件分类文档也把分类结果用于是否创建工单、如何路由以及是否触发后续自动化。

第一版可以要求模型返回类似下面的对象：

{
  "intent": "delivery_status",
  "priority": "normal",
  "entities": {
    "order_id": "candidate-value",
    "product": "candidate-value"
  },
  "missing_fields": [],
  "risk_flags": [],
  "recommended_action": "draft_reply"
}

这里的字段值仍需规则校验。例如，订单号必须符合系统格式并能查到记录；“紧急”不能只凭客户用了感叹号，而要结合服务等级、故障范围和业务规则判断。

高风险分流应独立于普通意图分类。涉及退款例外、价格承诺、账号与权限变更、隐私投诉、人身安全或法律争议时，即使模型认为自己能够回答，也应进入指定人工队列。

第三步：查询客户与业务上下文

分类只是标签，事实才是回答的原料。

模型理解了来信，不代表已经拥有回答所需的事实。工作流需要通过受控工具查询订单状态、历史工单、合同服务等级或设备信息。

这个阶段建议默认只读，并限制查询范围：

先用已验证的客户与工单标识取数，不让模型自由拼接查询；
工具只返回回答当前问题所需的字段；
查询失败、数据冲突或关键字段缺失时，停止草拟结论，改为请求补充信息或转人工；
将工具名称、参数摘要、返回状态和数据版本写入运行轨迹。

上下文查询与知识检索要分开。订单是否发货属于实时业务事实，退换货条件属于政策知识；两者的来源、更新频率和授权方式不同。

第四步：检索可引用的知识

有事实，还要有政策依据。

知识库不是”把所有文档塞进向量库”。客服人员需要的是当前有效、与问题匹配、能够追溯到原文的材料。

每条检索结果至少应带回文档标识、标题、适用范围、版本或生效时间、命中的具体段落。生成回复时只允许使用这些材料和已验证的业务数据；没有足够证据，就明确进入“需补充信息”或“转人工”，不要用常识补齐企业政策。

如果知识材料本身过期、互相冲突或缺少责任人，先修知识治理。站内的 RAG 知识库指南详细说明了文档清理、切分、权限、引用和更新机制。

第五步：生成回复草稿，而不是自由发挥

前四步的成果，在这一步组装。

给模型一个固定输出协议，比要求“专业、友好地回复”更可靠。草稿可以包含：对问题的简短确认、已核实的事实、根据政策给出的处理步骤、仍需客户提供的信息，以及必要的升级说明。

同时设置几条硬限制：

不引用未检索到的政策，不虚构订单或处理进度；
不承诺超出授权范围的退款、时间或补偿；
证据不足时不强行给结论；
内部备注、风险标签和系统字段不得进入客户可见正文；
每个关键结论保留内部来源，供客服一键查看。

草稿之外，再返回建议动作与原因。客服需要知道系统为什么建议回复、追问或升级，而不是只看到一段看似流畅的文字。

第六步：人工确认、发送与写回

草稿完成，最后一关是人。

第一版应由客服检查客户身份、事实、政策引用、语气和下一步动作，再决定发送。人工修改不能只覆盖原稿，应记录“接受、轻微修改、大幅修改、拒绝、转人工”以及原因。

Microsoft 的 Case Management Agent 文档展示了类似的分级方式：系统可以自动处理，也可以生成邮件草稿后由客服审核发送，并在缺少信息时建议追问。对多数刚起步的团队，先采用“草稿 + 人工发送”更容易建立质量基线。

发送成功后，再由确定性程序把分类、来源、最终回复、处理状态和负责人写回工单系统。发送与写回任一步失败，都要保留可重试状态，不能因为模型已经生成草稿就把工单标记为完成。

不同风险的工单，自动化程度应该不同

一张表看清边界。

工单类型	AI 可以做什么	人工责任
常规信息查询	分类、检索、生成带来源的草稿	抽查或确认后发送
订单状态与标准政策	查询只读数据、生成处理建议	核对身份与事实，确认发送
信息不全或材料冲突	指出缺口、草拟追问	决定追问或升级
退款例外、价格承诺、账号变更	整理事实与相关政策	授权人员判断并执行
投诉、隐私、安全或法律争议	风险识别、完整转交上下文	指定专岗接管，AI 不给终局结论

人工确认点不是固定不变的。某类任务经过持续评测，结果稳定、错误可恢复且责任边界清楚后，可以逐步减少复核；风险或输入发生变化时，也要能退回更保守的模式。NIST AI RMF Playbook建议根据使用情境定义、评估并记录人工监督流程，而不是简单地在界面上加一个确认按钮。

验收不要只看”回复像不像人”

自然度不是质量的全部。

离线样本与试运行阶段至少观察五组结果：

分流质量：高风险工单是否漏分，普通工单是否被大量误转；
事实与证据：订单字段是否正确，关键结论是否由有效材料支持；
草稿可用性：直接接受、轻微修改、大幅修改和拒绝分别占多少；
业务结果：首次解决、处理周期、积压和重复来信是否改善；
运行成本：每个合格工单的模型、工具、人工复核与返工成本。

尤其不要用总体分类准确率掩盖高风险漏分。普通咨询错分一次与隐私投诉没有进入专门队列，后果并不相同。验收标准应按类别和风险拆开。