网易智企·云商

导语

AI客服规模化后，最先暴露的往往不是入口不够，而是问题进入后，没人清楚该转给谁、由谁推进、什么时候算解决。

用户先在小程序里咨询售后进度，机器人完成初步接待；同一用户又通过电话补充情况，形成新的沟通记录；运营团队在企业微信里收到反馈后发现，这并不是普通咨询，而是需要售后、仓配或产品团队一起处理的问题。

入口都接住了。但如果没有统一的问题分类、分派规则、升级条件和追踪口径，问题很容易停在“已响应”，很难走到“已解决”。

这也是很多客服团队在规模化阶段会遇到的矛盾：网易智企·云商可以通过AI客服识别和回答高频标准问题，在线客服处理需要人工判断的即时沟通，电话渠道承接语音场景下的复杂确认。可一旦工单流转和运营协同没有跟上，前端接待越充分，后端积压越明显。

从产品配置看，“接得住”只是第一步。更关键的是提前写清楚：

  • 问题类型怎么分；
  • 责任团队是谁；
  • 处理时限怎么设；
  • 哪些情况要转人工；
  • 哪些情况要生成工单；
  • 哪些异常要升级给业务负责人；
  • 哪些问题需要沉淀回知识库。

这些规则清楚后，AI客服、在线客服、电话渠道与工单系统才不是几套并列工具，而是一条从接待到解决的服务链路。

入口越多，越要先定义问题类型

全渠道客服的配置，不建议从“还能接哪些入口”开始。更应该先问：不同入口进来的问题，应该停在哪一层处理。

比较稳妥的做法，是先把咨询分成四类：标准问题、需人工判断的问题、需跨团队处理的问题、需持续跟进的问题。分类清楚后，再决定由机器人、人工坐席、电话沟通还是工单承接。

标准问题：先交给机器人，但要建设知识库

标准问题适合由AI客服优先处理，例如规则说明、流程查询、常见操作指引等。

这里不是让机器人回答所有问题，而是先把知识库组织好。客服机器人的知识通常以“问题-答案对”的形式沉淀，形成可被识别和调用的知识库。知识库的分类体系是否合理、覆盖范围是否足够，会直接影响机器人能否匹配到用户问题。

机器人效果不能只看“有没有回复”，更要看两个核心指标：

  • 问题匹配率：用户的问法能否命中知识库中的问题或相似问法；
  • 问题解决率：机器人给出答案后，用户问题是否真正被解决。

尤其是中文表达里，同一含义可能有多种问法。运营团队需要围绕真实会话补充相似问法，而不是只录入一条标准问题。例如同一个售后规则，用户可能会问“怎么退”“能不能撤”“什么时候到账”“还没处理怎么办”。如果相似问法缺失，机器人就可能出现“有答案但匹配不到”的情况。

需人工判断的问题：不要强留在机器人环节

需人工判断的问题，不宜强行留在机器人环节。

例如用户描述不完整，需要结合订单上下文；用户情绪明显，需要先安抚再处理；问题涉及协商、例外判断或责任归属。这类问题应转到在线客服，由坐席补问关键信息、判断责任团队，并决定是否需要继续升级。

在线客服的价值不是重复知识库答案，而是处理上下文、情绪和判断。

需电话确认的问题：要把通话结果接回流程

语音沟通也要单独设计。用户不方便打字、问题需要快速核实、需要主动回访或紧急确认时，电话渠道更合适。

但电话解决不了的事项，不应只停在通话记录里。坐席完成沟通后，需要把处理结论、待补材料、责任团队和下一步动作写回后续流程。否则通话虽然完成，问题仍然没有闭环。

跨团队和持续跟进问题：一开始就要定义责任

最容易卡住的是后两类：需跨团队处理、需持续跟进。

它们一开始就要定义责任团队、处理时限和升级条件。例如：

  • 售后、仓配、产品、财务等团队分别处理什么问题；
  • 什么情况下由坐席继续跟进；
  • 什么情况下必须生成工单；
  • 超过约定时限后提醒谁；
  • 哪些情况需要升级给业务负责人；
  • 用户确认解决、系统状态完成还是运营复核后才允许关闭。

入口越多，这套分层越要提前写清楚。否则前端响应会越来越快，后端流转却越来越慢。

转人工不能只看“用户要求”，还要看对话阶段

如果转人工规则只写成“用户要求人工就进入人工池”，规模一大，坐席很快会被二次转接拖住。

售前咨询、售中履约、售后处理看起来都叫“转人工”，但背后的责任团队、响应优先级和处理方式并不一样。统一进入一个人工池，短期能接起会话，后续却容易变成“先接待的人不负责解决，真正负责的人拿不到上下文”。

更合适的做法，是让机器人在转人工前先完成一次场景判断。

在网易智企·云商的在线机器人中，Agent机器人支持按对话阶段转入对应分流组。运营团队可以在“在线机器人——转人工规则”中配置“指定参数转人工”策略，包括策略名称、识别参数、引导语和目标分流组。机器人识别到会话属于售前、售中、售后等不同场景后，再按预设规则转入对应分流组，减少人工二次转接。

配置时要注意几个细节：

  • 分流组从在线客服已有分流组中选择，不能只停留在概念设计；
  • 引导语开启后需要填写内容，避免用户不知道已进入人工处理；
  • 删除策略时需要谨慎确认，避免误删影响线上分流；
  • 转人工规则上线后，要结合真实会话持续复盘识别是否准确。

这里的“识别”不能理解为自动覆盖所有复杂问题。它依赖知识库建设、参数配置和持续运营维护。

例如：

  • 售前阶段可关注商品、活动、价格、资质咨询；
  • 售中阶段可关注订单、支付、发货、预约；
  • 售后阶段可关注退款、维修、投诉、进度查询。

不同业务还需要结合自己的字段、标签和用户问法沉淀，不适合照搬一套固定规则。

分流组也不建议只按渠道来源配置。来自小程序、网页、电话或企业微信的用户，都可能问同一个售后问题。如果只按渠道分组，同类问题会被分散到不同团队，复盘时也难以判断问题集中在哪个环节。

更可控的方式，是围绕问题类型、责任团队、处理时限和用户状态设计分流规则：

分流维度配置重点典型检查问题
问题类型咨询、履约、售后、投诉、财务等这类问题应由谁处理？
责任团队客服、运营、售后、仓配、产品等哪个团队能推动结果？
处理时限即时处理、限时跟进、需升级多久没有进展要提醒？
用户状态新用户、成交用户、活跃用户、风险用户等是否需要更高优先级或专人跟进？

这样配置后，转人工不再只是“从机器人交给人”，而是把会话送到更接近解决问题的位置。

运营团队后续复盘也会更清楚：哪些阶段最容易转人工，哪些分流组承压，哪些问题需要补知识库，哪些问题应进入工单闭环。

工单系统要承接“不能当场解决”的问题

会话适合处理“当场能判断、当场能答复”的问题。一旦需要跨部门处理、等待结果、补充材料或持续跟进，就不应继续停留在聊天窗口里。

否则坐席看似接住了用户，实际只是把问题挂在个人记忆、聊天记录或临时备注里，后续很难提醒、追踪和复盘。

工单系统要承接的是结果管理。它不只是把会话转成一条记录，而要把责任人、处理时限、升级规则、回访动作和关闭条件写清楚。

典型流程可以拆成五步：

1. 机器人前置识别：优先处理高频标准问题，无法解决时按规则转人工；2. 人工补充判断：坐席确认用户诉求、补问关键信息、判断责任归属；3. 生成工单：对不能当场解决的问题，记录问题类型、责任团队、材料要求和处理时限；4. 责任团队处理：由对应团队推进核验、处理、反馈或补充说明；5. 回访与关闭：根据用户确认、系统状态或运营复核结果关闭，并沉淀复盘结论。

比如用户提交售后材料后，由哪个团队审核；超过约定时间没有进展，提醒谁；需要补充信息时，由坐席联系用户还是由责任团队处理；用户确认解决、系统状态完成，还是运营复核后才允许关闭。这些规则如果不提前定义，工单会变成另一个堆积池。

在AI客服、在线客服、电话渠道与工单系统协同时，链路可以拆得更明确：

  • 机器人优先解决标准问题；
  • 人工坐席补充判断、安抚情绪、确认关键信息；
  • 电话用于紧急确认、主动回访或复杂沟通；
  • 工单负责把不能当场解决的问题推进到闭环。

工单闭环的价值不在于多建一条记录，而是让每个无法即时解决的问题都有下一步。

运营负责人需要关注的也不只是响应速度，还要看问题有没有被分派到正确团队，是否按时推进，用户是否重复咨询，同类问题是否在持续增加。

规模推广阶段，先验收流程，不要只验收接入率

AI客服进入规模推广后，接入率容易被过度使用。它能说明入口有没有承接住用户，但不能单独代表问题是否被解决。

接得快、排队少，只是接待侧结果。用户反复追问、会话多次升级、工单长期未关闭，才是运营侧真正要处理的压力。

接待侧指标可以保留，但要看清适用边界。以已有口径为例：

  • 实际接入率 = 接入成功 /（接入会话 + 排队失败的未接入会话 + 排队转留言）
  • 接入率 = 接入成功 /（接入会话 + 未接入会话）

这类口径适合评估在线客服入口、排队和承接情况，不能直接推导出服务质量，也不能替代问题解决结果。

规模化上线前，建议把验收表从“能不能接入”扩展到“能不能闭环”。一条完整链路至少要跑通：

1. 机器人能回答标准问题；2. 无法解决时能按规则转人工；3. 转人工时能进入对应分流组；4. 人工能看到必要上下文并确认责任归属；5. 不能当场解决的问题能生成工单；6. 工单有责任人、处理时限、升级条件和关闭标准；7. 处理完成后能回访或确认结果；8. 复盘时能把高频问题、错误回答、缺失知识沉淀回知识库。

复盘指标也要跟着调整。除了接入率、响应时长，还应持续看问题解决率、重复咨询、升级率、转人工原因、工单超时和知识库缺口。

尤其是转人工原因和知识库缺口，能帮助产品和运营判断：哪些问题本该由机器人解决但没有命中，哪些问题不适合继续堆给坐席，哪些流程需要业务团队重新定义责任和时限。

从上线验收看，规模推广不是把入口铺开就结束。更可控的做法，是先证明每类问题都有去向，每次转接都有上下文，每张工单都有责任人和关闭条件。这样，AI客服接住的流量才不会在后段变成新的运营堆积。

配置落地时，运营团队先检查这几件事

配置不是把入口接上、把机器人打开就结束。规模化之前，运营团队最好先做一次“问题去向”检查，确认每类咨询从进入、识别、转接到关闭都有明确规则。

1. 检查知识库：是否能支撑真实问法

先看知识库。高频问题要有标准答案，答案不能只写给机器人看，也要让坐席和后续处理团队理解一致。

同时要检查相似问法覆盖是否充分。同一个业务规则，用户可能用完全不同的表达提问。如果知识库只覆盖内部标准说法，机器人就可能在真实会话中匹配失败。

知识库还需要明确维护责任：

  • 规则变化后由哪个团队更新；
  • 谁审核答案口径；
  • 过期内容如何下线；
  • 错误回答如何回收复盘；
  • 高频未命中问题如何补充。

否则机器人命中率看似不低，实际仍可能把用户带到错误路径。

2. 检查转人工：是否都进了同一个队列

再看转人工。Agent机器人支持按识别结果和预设规则转入对应分流组，适合把售前、售中、售后等不同阶段的问题交给更合适的人工团队处理。

运营团队要重点检查一个风险：复杂问题是否都被丢进同一个队列。

如果所有“机器人答不了”的问题都进入通用人工组，坐席还要二次判断、二次转接，排队压力会从机器人后面重新出现。

更建议检查：

  • 是否已区分售前、售中、售后等阶段；
  • 是否配置了识别参数；
  • 是否配置了目标分流组；
  • 是否需要开启引导语；
  • 分流组是否能对应真实责任团队；
  • 转人工后的会话上下文是否足够人工判断。

3. 检查工单：是否有责任、时限和关闭标准

然后看工单。工单模板里至少要写清问题分类、责任团队、处理时限、升级路径和关闭标准。

分类太粗，后续复盘只能看到“售后问题很多”；分类太细，一线又难以稳定选择。

更稳妥的做法，是先围绕真实处理责任拆分：谁能解决，就按谁来归类；谁需要补充材料，就把材料要求写进工单字段；谁负责回访，就在流程里提前定义。

4. 检查运营协同：复盘口径是否一致

还要看运营协同。客服、运营、客户成功和业务团队要共用同一套复盘口径，避免客服只看响应时长，运营只看活动转化，客户成功只看投诉升级，业务团队只看处理量。

规模化后的复盘，应把问题解决率、重复咨询、升级率、转人工原因、工单超时和知识库缺口放在同一张问题清单里看。这样才能判断是机器人知识不足、分流规则不准、工单责任不清，还是业务流程本身需要调整。

FAQ

AI客服规模化后，为什么仍然会出现排队和转接混乱？

排队不一定来自入口不足，也可能来自后段规则不清。

机器人接住了大量咨询，但如果“答不了就转人工”只有一个默认队列，坐席仍要重新判断问题类型、责任团队和处理优先级，排队会在转人工环节重新出现。

转接混乱通常还和上下文缺失有关。用户已经说明过的问题、机器人已识别的意图、需要补充的材料，如果没有随会话一起传递，人工接手后只能重复询问。

哪些问题适合机器人处理，哪些必须转人工或进工单？

适合机器人处理的，是规则稳定、答案明确、可通过知识库标准化回答的问题，比如查询类、流程说明类、常见售前售后规则类咨询。

需要转人工的，通常是用户意图不清、情绪明显、涉及判断和协商的问题。

需要进入工单的，是人工无法当场解决、必须由其他责任团队处理的问题，例如需要核验、补充材料、跨团队确认或后续回访的事项。

运营团队不要只按“难不难”判断，更要看“是否能当场关闭”。

转人工规则应该怎么开始配置？

可以先从对话阶段入手，而不是一开始就设计过细的规则。

例如先区分售前、售中、售后，再为不同阶段配置识别参数、引导语和目标分流组。Agent机器人识别到会话所属阶段后，按预设规则转给对应人工团队。

上线后再结合转人工原因、坐席反馈和会话复盘，逐步补充识别参数和知识库内容。

全渠道客服上线后，运营团队应该先看哪些指标？

接入率和响应时长仍然要看，但不能只看这两项。

全渠道客服上线后，更应同步关注问题解决率、重复咨询、升级率、转人工原因、工单超时和知识库缺口。

接入指标说明入口承接情况，重复咨询和升级率能反映用户是否真正得到处理，工单超时则能暴露责任团队和处理时限是否清楚。复盘时把这些指标放到同一条链路里看，比单独追求“接得快”更有价值。

结语

把“接得住”升级为“转得动、追得到、复盘得清”，不需要一开始就设计复杂体系。更可落地的起点，是先完成四件事：

1. 按问题类型分层，明确机器人、人工和工单的边界；2. 配置转人工规则，减少通用队列里的二次判断；3. 把工单责任、时限和关闭条件写清楚；4. 用解决率、重复咨询、升级率和知识库缺口做持续复盘。

入口接住流量只是开始。后段能闭环，AI客服规模化才不会变成新的运营积压。

网易智企