AI 客服何时转人工怎么定
AI 客服上线前，先写明哪些情况转给人工、工单要带上哪些前文，以及哪个时段由谁看队列。转交分成事先料到的交接，和助理对不上时的退回。草稿能不能发出，写在客服机器人那一篇；这里写对话离开助理、进入坐席队列的规则。
目录
上线前先写转交，不在对话里现编
转交规则写在上线之前：哪一类问题一定交给人、哪一类先由助理答到哪一步、人接过之后要看见哪些前文、人没有在线时顾客看到什么。规则由负责客服的人定稿，坐席主管确认队列和时段。助理上线之后才在对话里临时决定转不转，队列会在忙的时段堆满，闲的时段又没有人接敏感问题。
机器人那一篇处理的是：重复问题先分类、用已核准文本草拟、由坐席决定发不发出。权限那一篇处理的是内部助理谁可以读哪些资料。对外客服的转人工是第三件事：对话离开助理、进入坐席队列。三篇不要并成一句「都要人工看过」。分别见 AI客服机器人怎么做、企业AI助理如何设定权限。渠道怎么接到坐席每天打开的画面，见 客服、销售及语音助理。
Zendesk 要先定策略和渠道
2026年10月20日阅读的 Zendesk：为 AI 代理设定升级策略与流程 写明，询问若复杂、紧急或敏感，AI 代理有时要把查询转给人工。上线前先制定升级策略并设计升级流程，再用对话构建器里的升级区块把路径做出来。该页写明可为消息和电邮的 AI 代理建升级流程，并注明支持方案为 Team、Professional 或 Enterprise。该页没有刊登日期。
同一页把升级策略定义成：哪些查询要升级、走哪一个渠道。它写通常有消息和电邮两个渠道，并要考虑坐席人数、坐席是否在线与办公时间、该渠道的对话量、查询的复杂和紧急程度。页上的例子是：四人团队、朝九晚五、每天约 200 至 250 则对话时，若消息升级太多，坐席会过载、顾客会等很久；该例子建议把消息升级留给会直接影响收入或顾客满意的高影响问题，例如产品问题和运送失败，并在助理已无法把顾客引到自助内容时才提供升级。这是该页的例子，不是各公司都要抄的人数或通数。公司把自己的时段、人数和哪几类问题走消息、哪几类走电邮，写在策略页上。
计划内交接和对不上时的退回
2026年10月20日阅读的 IBM：连接到真人坐席 把升级定义成：助理已接上支持的服务台时，在需要时把对话转给真人。该页写明，要用这个功能，助理须以网页聊天或电话与顾客互动，而且要先加好服务台集成。该页列出的服务台包括 Genesys、NICE CXone、Salesforce、Twilio Flex、Zendesk，以及自备服务台。该页没有刊登日期。
同一页把转交分成两种。计划内升级是事先料到、一定要交给人的情况，例子包括顾客要求的服务无法只靠助理完成，以及需要人处理的敏感事项，例如丧亲福利或投诉。退回升级是顾客从助理得不到帮助的意外情况，例子包括：顾客反复提出对不上任何已定义动作的问题、反复给出无效答案、或明确要求找人。退回由内建的 Fallback 动作处理，预设就是发起转给真人。客服规则页用这两个名字分开写：哪些句子属于计划内、哪些属于退回，不要合成一个「不满意就转」。
工单要带上顾客已经讲过的话
Zendesk 设计流程一节写明，升级前可以先做这些事，让交接和后续对话更有效：收集订单编号、姓名或电邮；为既有流程加标签并更新栏位；找出适合接手的坐席。然后用范本回复设计升级流程；需要多于一条流程时，再加范本。IBM 页写明，助理发起转交时，坐席在自己的仪表板上收到通知，并能看到顾客与助理的聊天历史。规则页把「必须带上的前文」写成清单：订单或案件编号、顾客用来联络的渠道、已经收集的姓名或电邮、助理最后停在哪一题、聊天记录是否随工单走。
清单上没有的项目，不要在转交当下要求坐席回头再问一遍顾客刚刚讲过的话。Zendesk 另注明：对话里至少要有一则顾客或 AI 代理的消息，才可以升级。空对话不要开出一张没有内容的工单。标签用客服已经在用的那一套，不在助理里另起一组坐席看不懂的词。加标签和改栏位的动作写在流程上，并写明写进哪一个栏位。
谁在哪个时段看这个队列
时段和队列写在策略页，不写在单一则对话里。Zendesk 写明，可以选择只在坐席可继续对话时才用消息升级；同步渠道若已过坐席工作时间，可以改用电邮升级，并在路径开头用可用性区块，让流程先看办公时间或坐席是否在线。转给坐席时，预设进入集成 CRM 时指定的群组，也可以在详细资料里用「升级到团队」改指定；升级失败时，可以指定改走哪一段对话，例如系统回复「升级失败」。电邮升级的旧选项，该页注明已不再建议。
IBM 的转交步骤在动作的「然后」选 Connect to agent。可设定的消息包括：坐席在线时对顾客说的话（预设是 Let's send you to an available agent）、坐席不在线时对顾客说的话（预设是 There are no agents available at this time. When one becomes available, we'll connect you.）、可选的给坐席的消息，以及可选的指定队列。该页并注明：一旦转交发生，这个动作就结束，不论顾客其后有没有真的接上坐席。所以「转交已发出」和「坐席已接起」要在记录上分成两栏，不要把动作结束当成顾客已经被人接听。队列负责人的名字和时段写在策略页，请假时改的是这一页，不是某一则历史对话。
转交失败和坐席不在线分开写
坐席不在线，是策略里已经料到的时段问题：改走电邮、留下不在线的消息、或约到下一个有人的时段。Zendesk 用可用性区块做这个分支。IBM 用「坐席不在线」的回复，预设告诉顾客目前没有坐席、有人可用时再连接。两页都没有规定等待秒数或服务水平，公司自己的等待标准写在客服制度里，并注明日期，不写进这两页的引用。
转交失败是另一种情况：路径已经决定要转，但没有交到指定的团队或服务台。Zendesk 让你指定失败时改触发的对话。IBM 写明动作在转交时就完成，即使顾客没有接上坐席。规则页因此要写：失败时顾客看到哪一句、工单落在哪一个队列、谁在下一个工作时段清这个队列。没有这三行，失败的对话会停在助理已经结束、坐席还没看见的中间。电邮若设了自动化门槛，Zendesk 还提到升级后对话会带上 escalated_by_ultimate 标记、助理不再回复，工作流程要能认出状态仍是 Open 且带这个标记的工单。只有实际采用该电邮能力时，才把这个标记写进清队列的条件。
和草稿、内部权限不要混写
价格、交期、退款和投诉要不要由人确认才发送，写在客服机器人那一篇：助理可以草拟，坐席决定发不发出。那是「句子还在助理里」。这一篇是「对话要离开助理」。一则投诉可以两步都发生：先按已核准文本草拟能答的部分，再按计划内升级把人或退款交给坐席，并带上订单编号和已经讲过的话。不要因为内部知识库有权限表，就以为对外队列已经有主人。
内部助理的权限管的是员工能读哪些文件。对外转交管的是顾客对话进哪一个坐席群、在什么时段。两张表的人名可以相同，栏位不要混用。权限表没有写队列时段；策略页没有写文件目录。上线检查时分开看：坐席能不能在自己的画面看见带前文的工单，以及员工助理没有被拿来回答这张对外工单。
上线前用一则对话走通
上线前用一则计划内、一则退回，在预览或测试环境走完。IBM 写明，动作预览窗里不会真的转交，只会用 Connect to an agent 的消息确认步骤有触发；要测试真正的转交，需在已接上服务台的助理预览页进行。走测时核对：顾客看到的在线或不在线消息是否为规则页写定的那一句、坐席是否看见聊天历史或约定的栏位、失败时是否落在指定队列。走测的日期、对话编号和结果写在策略页末。
人数、等待时限和满意度目标留在公司自己的客服制度里。Zendesk 页上的四人与每日对话量只是该页例子。两份说明都没有给转交成功率或必须几秒内接起。策略页写完之前，用三件事看能不能上线：计划内和退回是否分开、工单是否带上约定的前文、每个时段是否有队列负责人。三件事都在策略页上，才让助理对顾客开放转人工。