我們公司怎麼跑出 20+ AI 流程？系列第 3 篇：客戶服務分流自動化 SOP，3 層分流、4 個信心分數、2 條人類接手紅線

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

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

為什麼客戶服務分流是中小企業 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 自己發明路由規則。

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，但人類一看就知道這是預警訊號，當天就主動加開了同步會議。

分類層改用 Jev：三層問題一次呼叫問完，門檻要重新畫

2026 年 9 月更新。上面三層在寫這篇的時候全靠 LLM 吐 JSON，每封信三次 prompt、三份 JSON、三次解析。TypeSafe 在 9 月 15 日發表的 Jev 模型是專門做這種判斷的決策模型：它不生成文字，你給它一封信加幾個答案範圍固定的問題，它一次回你每個選項的機率與信心分數。我們把三層對著它的 API 重新對過一遍，結論是這一層可以整個換掉，但門檻不能直接搬。

先講換掉之後長什麼樣。三層變成一次呼叫裡的四個問題，程式再依答案分流：

對應的請求，state 放信件正文加程式先撈好的客戶等級與上一張工單摘要，questions 長這樣：

{
  "state": {
    "email": "<信件正文，去掉簽名檔與引用>",
    "customer_tier": "VIP",
    "last_ticket": "3 天前關閉：報價單改版第 2 輪"
  },
  "model": "jev-1.13.0",
  "questions": {
    "is_for_us": {
      "type": "choice",
      "instructions": "這封信跟我們公司的業務有沒有關係",
      "criteria": {
        "customer": "現有或潛在客戶談報價、進度、問題回報、一般詢問",
        "partner": "合作提案、媒體採訪、廠商推銷",
        "noise": "垃圾信、電子報、私人信件"
      }
    },
    "business_type": {
      "type": "choice",
      "instructions": "客戶這封信主要在講哪一件事",
      "criteria": {
        "quote": "詢價、報價單內容、價格談判",
        "progress": "問專案進度、交期、下一步",
        "bug": "系統錯誤、功能異常、串接失敗",
        "general": "其他一般詢問"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "這件事需要多快處理",
      "criteria": ["這週內回覆即可", "今天內要有人回", "現在就要有人處理，客戶已受影響"]
    },
    "is_complaint": { "type": "noul", "instructions": "信中出現抱怨、失望或考慮換廠商的訊號" },
    "mentions_contract": { "type": "noul", "instructions": "信中提到合約、法務、個資或金額爭議" }
  }
}

三件事跟原本不一樣，第三件最容易踩。第一，路由表本來就寫死在 config（見上面那段棱角 POV），換模型後更是如此：Jev 只回「這封信是 bug 類、信心 0.82」，「bug 類送給誰」永遠是程式的事。第二，兩條人類紅線變成兩個 Noul 直接問，mentions_contract 只要高於門檻就整封進人工 queue，不管其他答案信心多高。第三，上面那條 0.7 的複審線不能直接搬過去用。LLM 的 confidence 是我們請它在 JSON 裡自報的數字，Jev 的 confidence 是從機率分佈算出來的統計量（全壓在一個選項是 1.0、平均分散是 0），兩者根本不是同一種量。正確做法是先跑影子模式：Jev 的答案與機率只寫 log、原流程照跑，兩到四週後把 log 跟主管實際指派的結果對起來，畫出「信心高於 X 時的正確率」，門檻從那張圖讀出來。

繁體中文是另一個要自己驗的點。官方明講英文最準、CJK 能處理但不等同，我們的客服信裡「不好意思想請問一下」通常是詢價、「我要客訴」通常真的是客訴，這些台灣講話習慣要直接寫進 criteria 的選項定義，不要期待模型自己懂。成本方面不用算太細：一封信加五題大約 600 個 token，每百萬 token 0.042 美元，一個月三千封信不到台幣三塊錢。三種問題型態各回傳什麼、信心分數的公式、官方自己列的 9 個弱點、以及接進 n8n 的節點怎麼排，都寫在 Jev 模型技術解析 那篇，這裡不重複。

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

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

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