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 從來不從模型開始,而是先蹲你的話務、先把可自動化的比例算清楚、再一類一類接上生產系統,把工程師留在現場直到使用率真的長出來。這比較慢,但這是唯一會留下來的做法。