3PL 客服 AI Copilot 导入剧本:查件、改单、异常通报如何砍掉四成话务

一家做跨境 3PL 的客户,旺季那两个月客服每天接六百通电话。我们去现场蹲了三天,把每一通都贴了标签。结果很有意思:接近一半的通话,客服讲的话几乎一模一样——「帮您查一下」、「单号是多少」、「已经到分拨中心了」。人坐在那里,做的其实是一台查询机器的工作。

这就是我们做物流客服 AI 导入的起点。不是先问「AI 能做什么」,而是先问「你的话务长什么样」。因为 3PL 的客服跟一般电商客服不一样:货主(shipper)、收件人、平台三方都会打进来,问的东西高度结构化,但又卡在好几个系统之间——WMS、TMS、承运商 API、你自己的订单库。话务能不能砍,取决于这些系统能不能被一个 Copilot 串起来读写。

先别谈 AI,先把话务拆开

我们的习惯是,导入前一定先做两周的话务盘点:录音转逐字、标主题、标情绪、标「这通有没有真的需要人」。3PL 的话务通常会落在这几类,自动化的难易度差很多:

把这张表摊开,「砍四成话务」这个目标就从一句口号变成算得出来的账:光是查件这一类,只要做到八成自动化,整体话务量就先掉了三成左右;再把改单里结构清楚的那一半接走,四成就到了。这不是乐观估计,是我们在两个 3PL 案子里实际落地的量级。

查件是送分题,但送分题也会出错

查件之所以好做,是因为它是唯读的——Copilot 只要能查、能讲清楚,不会动到任何资料,风险低。我们的做法是让 Copilot 直接串三个来源:内部订单库拿到单号与品项、WMS 拿到出库状态、承运商 API 拿到最后一公里的轨迹。使用者不管从 LINE、网页还是电话进来,问「我的货到哪了」,它回的是「昨天 18:40 到桃园分拨,预计明天上午派送,司机是黑猫」。

但我们踩过一个雷,讲出来给同行避坑:承运商的轨迹有时候会延迟更新,或者状态码语义不一致(同样是「配送中」,不同承运商的定义差半天)。早期版本我们让 AI 照实念状态码,结果收件人被「已送达」误导,实际货还在车上,客诉反而变多。后来我们加了一层规则——状态时间戳超过某个阈值、或多来源打架时,Copilot 不自己下结论,改说「系统显示…,我帮您跟司机确认后回复」,同时建一张工单。宁可保守,不要自信地讲错。

改单与异常:自动化的真正分水岭

改单开始牵涉写入,这是设计上最需要小心的地方。我们的原则是用「出库节点」当红绿灯:货还没拣货,改地址、改时段让 Copilot 直接写回 TMS,秒改;一旦进入拣货或已上车,任何更动都转人工,因为这时候动一下可能牵动路线、运费甚至退运。这条线划在哪,要跟营运一起定,不是工程自己决定。

异常通报最难,但也最值得做。它难在要判责、带情绪;值得做在于,就算 AI 不能结案,它能把「立案」这件耗时的事做完——问清楚破损照片、单号、品项、期望处理方式,结构化成一张工单丢给对的人。客服接手时,前面五分钟的问答已经省掉了。我们量过,这类话务就算只自动化三到四成,平均处理时间(AHT)还是掉了两成以上。

人机分流,不是把人赶走

导入后真正决定成败的,是升级设计(escalation),而不是 AI 本身多聪明。我们给每个 3PL 案子都会定三条硬性转人工的线:一是情绪侦测到明显不满,立刻转,不让 AI 硬凹;二是同一个问题 AI 来回两轮还没解决,转;三是任何涉及金额、赔偿、合约的,直接转。转的时候要把完整对话脉络一起交棒过去,客服不必再问一遍「请问您的单号」——这个交接体验做不好,客户对整套系统的信任会瞬间崩掉。

上线一季后,那家客户的话务量掉了约四成三,客服团队没有裁员,而是把省下来的人力挪去做主动异常关怀——货延误了,主动打给货主,而不是等对方气冲冲打进来。这才是我们想看到的:AI 接走重复的,人去做只有人做得好的。

回到开头那句我们常挂在嘴边的话:Demo 很美不算数,上线且有人在用才算数。所以在 Tenten,我们导入物流客服 AI 从来不从模型开始,而是先蹲你的话务、先把可自动化的比例算清楚、再一类一类接上生产系统,把工程师留在现场直到使用率真的长出来。这比较慢,但这是唯一会留下来的做法。