客服回复起草 AI. 客服回复起草 AI 是一款「起草-审核」工具，为你的客服人员写出第一封回复。它读取待处理的工单，从你的历史回复、产品文档和政策中提取信息，用你团队的语气写出草稿。客服人员编辑后发送，真人始终把关这张工单。
你的 12 位客服人员每次回复都要从一个空白框开始写。这就是拖慢速度的地方。答案往往早就存在于以往的工单或一份物流政策 PDF 里。这周第一百次用正确的语气把它重新打一遍，才是真正吃掉整个班次时间的部分。
「起草-审核」式回复助手究竟做什么？
它写的是第一稿，不是最终回复。工单一到，助手就会读取内容，从你的历史记录和文档中找出匹配的答案，把写好的回复放进客服人员的回复框。客服人员读一遍、改掉不对的地方，然后发送。客户从头到尾都不会和模型对话，对话的对象始终是你的客服人员——只是现在他们从一份草稿出发，而不是盯着空白行发呆的光标。
客服回复起草 AI 和面向客户的聊天机器人有什么不同？
聊天机器人直接回答客户，只能寄望于自己没把政策搞错。回复助手回答的对象是你的客服人员：它写出草稿，客服人员对照账号信息核实、编辑，并以自己的名义发送。每一张工单都有真人把关，没有任何一条回复是在没人看过的情况下发出去的。
这个区别就是整个设计的核心。面向客户的机器人给出错误的退款答案，是一次公开的失误，发给的还是一个本就不满的人。而草稿里的一句错话，会在发出之前被客服人员拦下。模型负责起草，人负责决定。审核这一步不是额外负担，它本身就是产品。
首次响应时间会有什么变化？
为便于说明，假设有一支中型电商客服团队，并非真实客户。一个基于过往工单、产品文档和物流政策 PDF 起草回复的助手，对难处理的工单帮助最大，也就是客服人员过去要打开六个标签页、读完才能动笔的那种。处在这种位置的团队，会在上线前后分别衡量复杂工单的首次响应时间。
简单工单本来就很快，比如重置密码、查询订单在哪。拖慢速度的是那些需要政策特例，以及团队实际用语的复杂工单。把这第一稿先起草出来，平均值应该会动。质量也可能提高，因为草稿自带客服人员过去要去翻找的出处。
检验方法很简单：你的客服人员是否不再从空白框开始写？如果他们改为编辑后发送，这份草稿就算站稳了脚跟。
#这不就是 Zendesk AI 或 Intercom Fin 吗？
We are
我们搭建的回复助手，基于你自己的过往工单、产品文档和物流政策 PDF 起草，所以草稿里已经带着你的客服人员过去要去找的答案。
We aren't
我们交付的不是一个只会从你已经写好的固定话术里起草的建议框——难工单的答案，本来就从来不在那些固定话术里。
Zendesk AI、Intercom Fin 和 Gorgias 的建议功能，都是基于自己的固定话术和帮助中心文章起草。对付简单工单很好用，但难工单需要的是 2023 年那张已解决的工单，以及那份自一月以来没人打开过的政策 PDF。能读遍你全部历史记录的草稿工具，和只会读你话术清单的工具，是两种完全不同的东西。
搭建完成后，回复助手归谁所有？
- 代码归你所有。我们的AI落地工作交付的是这套助手和完整代码仓库，而不是一个你要永远续租的工具。
- 项目中包含培训，让你的客服团队能自己运行它、调整语气、添加新文档，不用再回头找我们。
- 它始终在客服人员背后运作，哪天你想改变回复的措辞，动手改草稿的是客服人员，而不是要等某个供应商的产品路线图。
交付的意义在于，我们离开之后这套工具不会跟着退化。你的客服人员每天都在给它输入新的工单，它也就持续从他们实际发出的回复中学习你的语气。回复助手是我们客服相关工作里多个面向客服人员的搭建项目之一，它能和检索、分诊这些同样运作在客服人员背后的功能顺畅配合。
如果你 12 人的团队正被回复量淹没，又想在不把聊天机器人摆到客户面前的情况下缩短首次响应时间，我们应该一起把它规划出来。预约一次 30 分钟摸底通话。在任何人写下第一行代码之前，我们会先看看你的工单历史、你的文档，以及「起草-审核」助手是不是适合你的方案。
