电商客服工单自动流转，从消息接入到售后工单自动分派

大促当晚十一点的消息列表

大促当晚十一点，客服后台的消息列表还在往上滚。一个店铺平时一天几百条咨询，大促当天从下午开始就没停过。三个客服加上一个组长，四个人守着聊天窗口，手一直不停。

忙到什么程度。有人同时开着三个平台的会话窗，回话的时候来回切窗口，切错一次就把上一个顾客的问题答过去了。这类事故在大促当晚并不罕见，第二天的投诉里就写着客服答非所问。

更花时间的其实不在回复，在回复之后那一堆没人管的事。顾客说要退，客服回了一句好的，然后呢。退货运单号谁去生成，退款单谁去提交，仓库那边谁通知。这些动作散在聊天记录里，谁也没记下来，第二天靠翻聊天记录补。

所以很多团队做电商客服工单自动流转的时候，第一个目标定错了。他们想的是自动回复，想让机器人替人回消息。真做下来能替掉的回复很有限，卡住人的是后面那条没人认领的线。本文按这个顺序讲，先讲工单怎么建出来和派下去，再讲回复能替到什么程度，最后讲哪几种情况不值得上。

工单分类与分流规则

工单自动流转的第一件事，是把消息变成结构化工单。这一步做不实，后面全是空的。

分类规则不要一上来就上模型。务实的顺序是先人工标两三天的数据，把真实的咨询类型数出来，再决定哪些能自动判。顺序反过来做，很容易得到一个理论上很漂亮、实际天天错的分类器。

分类粒度按售后工单自动分派的需要来定，不按客服部门的习惯定。一个实用的分法大致是这样。

• 问物流。最标准化的一类。轨迹信息能从订单系统直接查到，回复内容也是模板化的。这一类适合全自动，也最先该拿下来。
• 退换货。要看订单状态。下单未发货、已发货未签收、已签收，三种情况的处理口径完全不同，规则要分开写，不能合成一条。
• 缺件与破损。必须人工。这类涉及赔付和举证，判错的成本比省下的人工高得多。
• 催单与改地址。看着像小问题，其实要看订单是否已出库。已出库的改地址要走仓储审核，直接答应会让顾客白等。
• 商品咨询与尺码推荐。适合自动，但要防止售后问题被误判成咨询。

这几类里，前两类能覆盖相当一部分日常量。剩下的分类不用急着做细，先让它们进人工。人工处理时顺手带个原因标签，一两周后标签数据自己就攒出来了，比一开始硬猜规则省事。

派单规则比分类规则简单，也更容易出问题。常见做法是按店铺和商品类目分给对应的客服组。真正要花心思的是三条兜底。第一，没人认领的工单多久升级给组长，要写具体的分钟数，别写及时。第二，一个顾客在同一时间开多张工单怎么处理，建议合并，否则同一个人被三个客服分别联系。第三，大促期间跨组支援怎么临时切，切完记得切回去。

这三条写清楚，大促那晚的混乱大半能消掉。剩下的混乱，来自工单的状态本身说不清楚。

自动回复能答到哪一步

「客服机器人自动处理」这个说法容易被理解成全托管。真正能自动处理的范围比想象中窄，窄的那部分收益倒是最大。

自动回复适合的场景有三个共同点。答案能从系统里查到，不依赖客服的主观判断；顾客问的是标准问题；答错的后果可控。三条同时满足才能全自动。

物流轨迹、发货时效、常见退换货政策，这几类满足得很彻底。它们占日常咨询的大头，而且答案没有争议。

不适合全自动的有这么几类。涉及金额判断的，涉及承诺的，比如说明天一定给你发。涉及情绪的，顾客已经很不爽了，再收到一段模板文字，火会更大。信息不全的，顾客没说订单号，机器人查不到，只能问一句，而问的那一句还要求顾客配合，多数人不会配合。

还有一类最容易被忽略。客服机器人自动处理的边界不止在于答什么，还在于答完之后要不要留在对话里。自动回复发出后，顾客接着追问，第二次就必须转人工，别继续用模板顶。顾客连着发第二条消息，这个行为本身就是信号。

什么情况必须转人工

转人工的规则建议写得越硬越好，不要留「视情况」这种空间。

有几类触发条件在实践中反复出现。

• 顾客第二次追问。第一条自动回复没解决问题，第二条就得有人。
• 情绪词命中。投诉、举报、曝光、起诉这类词直接进人工，不用先走自动回复试探。
• 金额超过阈值。赔付、退款金额超过某个数就转人工，阈值按自家毛利定，别照抄别人。
• 超时未解决。工单创建后多少分钟没解决就升级，这个时间比分类准确率更影响体验。
• 置信度低。分类模型给不出确定结果时走人工，别猜。这一条多数团队会忽略，因为人工兜底的成本看得见，猜错的成本看不见。
• VIP 与高复购客户。按客户标签直接分给固定客服或者客服主管，别进轮询池。

这六条里最该先写的是情绪词和超时升级。前者几乎没有实现成本，后者能在差评发生之前把投诉拦下来。

人工接手之后有个容易忽略的细节。工单要带着上下文转过去，包括原始聊天记录、系统已经查到的订单信息、模型给的分类建议。人工看不到这些，就要把顾客的问题重新问一遍，体验比纯人工还差。这一点做没做，从顾客第二次描述问题的详细程度就能看出来。

工单状态回写

这一段最枯燥，也最容易决定这套东西三个月后还在不在用。

工单常见的状态有新建、处理中、待顾客、已完成、已关闭。每个状态要有明确的进入条件，不能靠人点。

回写要解决两个问题。第一，订单系统那边退了款，工单系统要知道。这边不能等客服手改，等一周后出统计报表才知道，那时候已经没法复盘了。第二，顾客在聊天窗口说已经收到了，工单状态要跟着变。别小看这一句，很多工单就是卡在这里，一直挂到超时。

重复建单是另一个坑。顾客在聊天窗口催一次，系统就给他建一张新工单，两分钟后再催一次又多一张，客服那边看着像被同一个问题砸了十几遍。建单前先查该顾客近一小时内有没有同类未关闭工单，有就把新消息追加进去，别新建。

还有跨部门的状态同步。售后工单派给了仓库，仓库处理完要回写，回写了客服才看得到。这两套系统如果不同步，工单就会变成一个只能进不能出的盒子，客服每天第一件事还是去群里问仓库。

效果怎么度量

三个数就够了，多了没人看。

一是人工介入率。即最终由人处理的工单占全部工单的比例。这个数要按工单类型分开看，混在一起算的话，物流类压得很低会掩盖掉破损类的糟糕表现。

二是首次解决时长。从顾客提问到工单关闭。它比响应时长有意义，响应快但一直没解决，顾客的感受更差。

三是升级到主管的工单占比。这个数涨了，说明自动分流把不该它接的活接了过去，规则要改。掉得太快也要看一眼，可能只是一线客服硬扛着没人上报。

还有一个不算指标但必须做的事。每周抽一批被判为自动处理的工单人工看一遍，看有没有本该转人工的。这件事很枯燥，但它比任何指标都更早发现问题。

什么情况下别上

有几类场景做下来是亏的，提前说出来能省一轮人力。

• 日均咨询量太低。一天只有几十条消息，人力本身就不紧张，自动化省不下什么，倒是多了一套要维护的规则和一个没人看的工作台。
• SKU 极少的店。商品就那么几款，退换货政策也简单，客服看一眼就能答，规则写起来比回答还费事。
• 高度依赖人工判断的类目。定制家具、医美、教育这类，顾客诉求很难结构化，分类规则会一直在改，改到最后不如一开始就走人工。
• 已经有一套成熟的工单系统且用得顺的公司。现在的系统里分类、分派、超时提醒都有人维护，加这套之前先算一下是不是重复建设。

团队没有专人维护的情况最麻烦。规则要跟着业务改，业务一改规则就得改，没人改的规则半年后会错得离谱。

收尾

回到大促那晚。消息堆起来的时候，真正该被自动化的是把消息变成工单、把工单派到对的人手里这两步。回复本身能替掉一部分，替不掉大部分，硬替还会挨骂。

要动手的话先做一件事。拉出最近一周的聊天记录，人工分一下类，看看有几种。如果最多的那一类能覆盖三成以上咨询量，就从这一类开始做，一周之内能看到东西。如果各类都很碎，说明这个店的咨询还处在不稳定阶段，先别上。