客服 Agent 落地劇本:分流、草擬回覆到升級真人的三段式設計與成效指標

上季我們接了一個電商客服的案子。客戶已經上了一套會自動回覆的機器人,後台儀表板漂亮,主管很滿意。我調出真實對話一看:機器人接了七成的訊息,但其中超過一半在三輪內就被客人一句「我要真人」打斷,然後轉進一個沒人看的信箱躺著。表面上自動化率很高,實際上它在製造延遲。

問題不在模型笨。問題在於這套系統只有「一個動作」——收到訊息就生成一段話丟回去。而真實的客服工作,從來不是一個動作。

客服 agent 應用,先拆成三段而不是一坨

我們落地客服 agent 的做法,是把它拆成三個職責分明的階段:分流、草擬回覆、升級真人。這三段各自有明確的輸入、輸出和退場條件,而不是讓一個大模型從頭包到尾。這樣做的理由很現實:你要能分別量測每一段的成效,才知道要修哪裡;把它們糊成一團,壞掉的時候你只會得到一個「整體滿意度下降」的黑盒子。

第一段是分流。 agent 收到訊息的第一件事不是回答,是判斷。這則訊息屬於哪個意圖類別(退貨、物流查詢、帳務爭議、產品諮詢)?緊急程度多高?情緒是不是已經在爆炸邊緣?需不需要調帳號、訂單這些私有資料?分流階段的產出,是一張結構化的標籤,決定這則訊息走哪條路。我們踩過的雷是:早期把分流也交給生成式模型自由發揮,結果它把「我下週要出國,包裹來得及嗎」判成一般諮詢,漏掉了時效壓力。後來我們在分流層加了明確的規則護欄與信心分數,信心低於門檻的一律當作高風險往上送,誤判就少了一大截。

第二段是草擬回覆,不是直接發送。 這是我們最堅持的一條線。對於可自動處理的類別,agent 用 RAG 從知識庫、退換貨政策、這位客人的歷史訂單裡拉出依據,生成一段有出處的回覆草稿。低風險、高信心的,可以直接送出;只要碰到金額、承諾、例外處理,就先進真人的一鍵確認佇列。真人看一眼、按送出,而不是從空白畫面開始打字。這個設計把客服的角色從「作者」變成「編輯」,單則處理時間我們實測從平均四分多鐘壓到一分鐘上下,而且回覆品質更穩,因為草稿都帶著知識庫的引用,不會亂承諾。

第三段是升級真人,而且要交接得乾淨。 升級不是把對話甩給客服然後消失。好的升級要帶著完整脈絡過去:agent 已經問到哪、客人的情緒標籤、它判斷卡住的原因、建議的下一步。我們設了幾條硬性升級條件——客人明確要求真人、同一問題重試兩次未解、偵測到投訴或退費字眼、信心分數過低——命中任一條就升級,絕不硬撐。硬撐著假裝自己能解決,是客服 agent 最傷品牌的失敗模式。

每一段都要對得上一個可量測的指標

三段式設計真正的好處,是每一段都掛得上一個你敢對老闆報的數字:

這裡有個容易被忽略的取捨:升級率不是愈低愈好。有些團隊拚命壓低升級率,結果 CSAT 崩了,因為 agent 在硬接它接不住的案子。我們反而把「該升級卻沒升級」當成比誤升級更嚴重的錯誤來監控。分流率、AHT、CSAT 三個數字要一起看,單獨優化任何一個都會把系統帶歪。

還有一件上線後才會浮現的事:知識庫會過期。退換貨政策改了、促銷結束了,草稿階段就會開始一本正經地引用錯的規則。所以我們把知識庫的更新流程和 agent 綁在一起維運,而不是交付完就走。

回到開頭那個案子。我們沒有換掉它的模型,是把那一坨「收到就回」拆成分流、草擬、升級三段,加上護欄和交接。真人的時間從打字轉去審草稿和接硬案子。這件事對我們來說一直是同一個標準:Demo 上機器人回得很順不算數,要客人真的在幾分鐘內把問題解決、而且沒被系統甩掉,才算真的上線。