客戶服務分流自動化 SOP：3 層分流、4 信心分數、2 條人類接手紅線（系列 3）

早上九點打開信箱，我們公司常常一晚累積 30 ~ 50 封客戶來信：有人問報價、有人催進度、有人回報網站 bug、還有人寄合作邀約。過去這些信全部塞在一個 inbox，輪到誰先開誰就先處理，一週要燒兩個人總共 12 小時光在分類、轉信、找上下文。

我們在內部 AI 流程系列第 3 篇要拆的，就是這條客戶服務分流自動化 SOP，客戶服務分流接的是「能不能讓 AI 把信先分對人、把關鍵上下文一併丟給對的工程師或業務」這件事，而非接「能不能讓 AI 直接回客戶」的問題。這是我們落到 production 第 7 個月、踩過 2 次重大誤判（一次把催款信判成廣告、一次把 bug 報告路由給業務）才收斂出來的版本。

ℹ️這是我們系列的第 3 篇

第 1 篇我們拆的是「內部報價自動化 SOP」（#916）：報價單怎麼從業務聊天紀錄自動生成。

第 2 篇拆的是「排程治理 SOP」（#921）：20+ 個 AI cron 怎麼做時間表、重試、報警、版本管控。

這篇接「客戶服務分流」，是我們公司內部承載最大流量的單一 AI 節點（一天約 60-90 封信通過）。先看完前兩篇再讀這篇邏輯會更順。

為什麼客戶服務分流是中小企業 AI 落地最高 ROI 的單一節點

中小企業老闆最常問我們的一句話是：「公司 AI 從哪裡開始導入最划算？」，我們的答案連續 14 個月沒變過：客戶服務分流。理由是這條流程同時打中三個槓桿，它每天都跑、它有明確的對錯訊號、而且它的失敗成本可控（最壞情況就是人類重新分一次）。

舉個我們內部數字：客服分流節點上線前，每天約有 1.5-2 小時花在「這封信該給誰」這個決定上；上線 90 天後，這個時間降到 15-20 分鐘（只剩處理 AI 信心分數 < 0.7 的邊緣案例）。換算下來，一年省下約 380 小時，這個數字背後是 AI 把「決定誰回」這件低價值決策從 SOP 裡抽掉，而非 AI 替代了人。

三層分流架構：意圖 → 業務分類 → 緊急度

我們的客服分流不是一個 LLM 一次決定所有事，這是 v1 版本踩的雷。v1 把「分類 + 緊急度 + 摘要 + 建議回覆」全部包成一個 prompt，結果 LLM 經常把「緊急 bug」誤判為「一般詢價」（因為摘要邏輯吃掉了緊急訊號）。v2 拆成三層獨立判斷後，誤判率從 12% 降到 3.4%。

第一層：意圖分類（is_this_for_us）

第一層 LLM 只做一件事：判斷這封信「跟我們公司有沒有關係」。輸出三選一：客戶業務（quote / progress / bug / general）、外部合作（partnership / media / vendor_pitch）、雜訊（spam / newsletter / personal）。第一層 90% 的決策只在三個 token 之間選，所以我們用 Claude Haiku 跑，單封信成本 < $0.001。

第二層：業務分類 + 上下文撈取

第二層只在第一層判定「客戶業務」時觸發。這層做兩件事：(a) 細分業務類型（報價 / 進度 / bug / 合約 / 一般詢問），(b) 從 CRM 撈出該客戶過去 60 天的互動紀錄、現有專案狀態、最近三次對話摘要。這層的 prompt 會把撈到的上下文壓縮成 200 字以內塞進 system message，再由 Sonnet 做業務分類。

第三層：緊急度 + 路由決策

第三層是我們最謹慎的一層，它決定「這封信現在送給誰」。輸出三個欄位：urgency_score（0-1）、route_to（具體人員 email）、confidence（0-1）。這層必須在 prompt 裡明確列出 routing rules（譬如「合約相關 → 業務 lead + 法務 cc」「P0 bug → 工程主管 + on-call 工程師」），不能讓 LLM 自己發明路由規則。

⚠️棱角 POV：不要讓 LLM 自己決定路由表

我們在 v2.3 試過讓 LLM「根據職務說明書推斷該送給誰」，結果在試行第 4 天它把一封涉及 GDPR 個資的客戶回報送給實習生（因為實習生的職務說明書寫了「協助處理客戶詢問」）。

教訓：路由表是業務規則、不是 LLM 知識。寫死在 config、做 unit test、有 PR review。LLM 只負責把信「對到」路由表上的某個分類，它不該定義分類。

4 個信心分數：把分流的不確定性數位化

我們在三層裡都有信心分數，但真正進入 dashboard 觀測的只有 4 個：意圖信心（is_for_us_confidence）、業務分類信心（business_type_confidence）、緊急度信心（urgency_confidence）、路由信心（route_confidence）。每天早上 9:00 我們會看一張表，昨晚有哪些信 4 個分數中任一個低於 0.7。

實務上低於 0.7 的信約佔 8-12%。這些信不會被自動路由，它們會被丟到一個「人類複審」queue，當班的客服主管會花 10 分鐘掃過去手動指派。這個設計救過我們兩次：一次是客戶用了非常委婉的方式抱怨「進度太慢但理解你們忙」，LLM 的緊急度給 0.4，但人類一看就知道這是預警訊號，當天就主動加開了同步會議。

2 條人類接手紅線：什麼情況下絕對不讓 AI 自動走

導入 AI 分流流程的中小企業最常問的問題是「我可以讓 AI 走多遠？」，我們公司的答案是兩條死線：合約 / 法務相關（confidence 再高都人類複審）、客戶情緒分數 < -0.3（信件出現抱怨、失望、威脅換廠商的訊號）。這兩種信不管 LLM 多有把握都先 hold 30 分鐘等人類確認。

理由很簡單：合約信的成本是錯一封可能丟一年的合約；情緒信的成本是錯一封可能丟一個客戶口碑。這兩種失敗都不可逆，而 AI 在這兩種情境的判斷力，根據我們 6 個月的 audit data，比經驗 2 年以上的人類客服平均低 18%。AI 對「禮貌但生氣」「客氣但堅決」的訊號讀不出來。

ℹ️我們怎麼看：客戶服務分流的下一波會是「主動干預」

現在 SaaS 客服工具（Intercom / Drift / Zendesk）大多停在「分流 + 建議回覆」這層；但我們觀察到，2026 下半年起，會有一批工具開始往「主動干預」走，AI 不等客戶來信，而是觀察客戶在你的產品內的行為訊號（卡關、停滯、報錯），主動發起 outreach。

這對中小企業的意義是：你的客服 AI 流程不該只接 inbox、要接 product analytics + CRM + email send，這 3 條資料線要打通才能跑下一代的工作流。我們現在內部的客服分流節點已經在預備這層整合（連到 PostHog + HubSpot），但還沒上線。3 年後贏的會是把「客服」當作「主動成長引擎」而非「被動回覆窗口」的團隊。

想把客戶服務分流也接成一條 AI 流程？

我們把這條 SOP 跑了 7 個月、踩過 2 次重大誤判、收斂出 4 個信心分數 + 2 條紅線的版本。30 分鐘免費對齊：你的 inbox 量、現有 CRM、團隊規模適合走哪一條路徑。

預約 AI 顧問 30 分鐘對齊會議 →

Q客戶服務分流自動化最低需要哪些工具？

三層架構最精簡的版本：Inbox（Gmail / Outlook API）+ LLM（Claude Haiku + Sonnet 混搭）+ CRM（HubSpot / Salesforce / Pipedrive 任一）+ 通知（Slack / Teams）。第三層的路由表寫成 YAML 就夠了。月成本約 NT$2,000-4,000 LLM 費用 + SaaS 訂閱。

QAI 分流會不會把客戶信件「漏掉」？

會。我們在 v1 漏過 3 封信（被 spam filter 誤判）。v2 起所有信件都進 audit log，LLM 判定 spam 的不刪、不丟、只標 tag，每週由人類 sample 50 封覆核。這個 audit 設計是我們從週報 D-1 mag_dl 退回 0 那個教訓學到的：埋點失效不可怕，可怕的是你以為它在 work。

Q客戶服務分流跟「企業聊天機器人採購」差在哪？

差很大。聊天機器人（Intercom / Drift / Tidio）主要面對的是『新訪客』、答案在 FAQ 或產品文件裡。客戶服務分流面對的是『既有客戶』、答案藏在過去 60 天的合約、會議紀錄、CRM 對話裡。前者買 SaaS 就夠了，後者通常要客製化開發（或至少要把 SaaS 接到內部資料）。

Q誤判率多少算合格？

我們的內部目標是 < 5%、紅線是 > 10%。連續 3 天 > 10% 就會觸發 dashboard 警示，當週工程例會排版本回滾或 prompt 改寫。但更重要的是「誤判的型態」，把 P3 bug 判成 P2 的代價遠低於把 P0 bug 判成 P3。我們對 P0 → P1+ 漏判是 zero tolerance。

Q中小企業要不要自架 LLM 跑這個流程？

幾乎不用。客戶信件本身就會經過 Gmail / Outlook（你的資料已經在雲），跑 LLM 用 API 不會增加實質風險，除非你有金融業 / 醫療業的特殊合規。自架 LLM 的硬體 + 維運成本約 NT$30 萬起跳，對中小企業流量規模算下來單封成本反而比 API 貴 5-10 倍。

Q我們公司怎麼開始？

三個禮拜起步：第 1 週把過去 30 天的 inbox 撈出來、人工標 200 封信當訓練集；第 2 週寫第一、二層 prompt + dry-run 測誤判率；第 3 週上線只跑「建議路由」、不自動寄信，人類確認 100 封後再開自動模式。我們公司就是這樣起跑的，第 4 週才完全自動，前 3 週都是 shadow mode。