客服訊息全通路分流

🎯 這條流程解決什麼

對多數電商與服務業來說，客戶不會只從一個地方找上門。同一天裡，有人在 LINE 官方帳號問「我的貨到哪了」、有人寄 Email 來抱怨收到瑕疵品、有人在官網表單留下退費申請、還有人從 FB 粉專私訊問尺寸。問題是這四個通路各有各的後台，客服得開四個分頁、輪流刷新、人工判斷「這封該誰接」，再手動複製貼上轉給對應同事。

這樣的純人工分揀有三個看得見的成本。第一是時間：以一位客服每天處理 120 則來訊估算，光是「打開、讀完、判斷、轉交」這套動作，每則平均要花 40 至 90 秒，一天就是 1.5 到 3 小時耗在分揀本身，而不是真正解決問題。第二是漏接：尖峰時段（例如檔期開賣、出貨高峰）訊息一次湧進，沒有統一佇列就會有訊息被滑過去、被忘記，等客戶第二次來催才補救，體驗已經壞了。第三是看不到全貌：主管沒有任何儀表板，無法回答「今天哪個通路量最大、哪類問題最多、誰已經滿載」，只能憑感覺調人力。

語言問題又把難度往上加一層。跨境電商或有日韓客群的品牌，常常一封日文信被分給只會中文的專員，來回翻譯又卡半天。這條流程就是要把以上痛點一次解決。

導入後的改變

導入前，客服的一天是「在四個後台之間切換、用肉眼判斷、手動轉交」，分揀佔掉約三分之一工時，尖峰漏接率憑經驗大概落在 5% 到 10%，主管調度全靠喊。

導入後，所有通路的訊息先被統一吸進同一條待處理佇列，AI 接著做兩件事：辨識語言（中、英、日）並判斷主題與急迫度，然後自動把訊息推到對應的 Slack 客服頻道與負責專員手上。實務上，分揀這段幾乎完全自動化，等於把原本一天 1.5 到 3 小時的人工分揀壓到接近零，相當於替每位客服省下約 25% 到 35% 的工時，讓他們專心回覆而非分類。

漏接率方面，因為每一則訊息都進了同一個佇列、都有狀態標記，尖峰時段「滑過去就不見」的情況可望減少七成以上。對主管而言，最有感的是即時量能統計：哪個通路爆量、哪類客訴突然變多，一眼看得到，可以在尖峰前就調度人力，而不是事後檢討。這些效益是合理估算，實際數字會依你的進單量與團隊規模而異，建議導入後用前後兩週的資料自行比對。

流程怎麼運作

這條流程對應 frontmatter 裡的五個節點，逐步說明如下：

1. 全通路匯整（📥）：在 n8n 或 Make 裡為每個通路各設一個 Webhook 或輪詢節點——LINE Official Account 的 Webhook、Gmail 的新信觸發、官網表單的 POST、Facebook Messenger 的訊息事件。四路訊息一進來就被正規化成同一個格式（來源通路、客戶識別、內文、時間），統一塞進一條待處理佇列，後面所有節點都吃這個標準格式。

2. 語言判斷（🌐）：把內文丟給 AI 分類 API，先判斷語系是中、英還是日，寫進一個 language 欄位。這一步單純為了後面能把訊息派給對應語言的專員，避免日文信落到只懂中文的人手上。

3. 主題分類（🏷️）：同一次 AI 呼叫（或第二次呼叫）判斷主題屬於訂單、帳務、技術、退換貨或客訴，並給出急迫度（高／中／低）。客訴和退費類關鍵字一律拉高急迫度。

4. 智慧派單（📤）：用一個對照表把「主題 × 語系」映射到對應的 Slack 頻道與負責專員，例如「日文 × 訂單」進 #cs-jp-order、「中文 × 客訴」進 #cs-escalation 並 @ 值班主管。訊息連同原文、來源通路與分類結果一起推過去，專員點開就有完整脈絡。

5. 量能監看（📊）：每筆派單同時寫一列到統計表，累計各通路、各主題的進單量。設一個排程節點定時彙總，當某通路或某主題在短時間內超過門檻，就主動在主管頻道示警，提醒調度人力。

需要的工具與串接重點

• LINE Official Account：透過 Messaging API 的 Webhook 接收訊息，記得在 LINE 後台關掉自動回應、開啟 Webhook，並驗證簽章避免假請求。
• Gmail：用 n8n/Make 的 Gmail 觸發節點監看特定客服信箱或標籤，建議過濾掉行銷與系統通知信，只放真正的客戶來信進佇列。
• Facebook Messenger：需要在 Meta 開發者後台設定 Webhook 與權限，注意 24 小時訊息視窗的規範。
• AI 分類 API：這是大腦。Prompt 要明確要求只輸出結構化結果（語系、主題、急迫度），方便後續節點解析；把「客訴／退費」這類敏感主題的判準寫清楚，寧可分類偏保守也要拉到真人。
• Slack：作為派單的落點，依語系與主題建好頻道，並用對照表維護「主題到頻道與專員」的映射，日後調整人力只要改這張表。

串接重點是「先正規化再分類」：四個通路格式差很多，務必在進佇列前統一欄位，否則 AI 與派單節點要為每個通路寫一套邏輯，維護成本爆增。

常見錯誤與注意事項

• 個資外流：來訊常含訂單編號、姓名、電話、地址。AI 分類只應拿來做派單標記，不要把完整個資貼到對外或非必要的頻道；Slack 頻道權限要收斂，避免無關人員看到客戶資料。
• 過度信任 AI 分類：分類是輔助，不是裁決。客訴升級、退費、爭議訂單這類訊息，務必只做「標記並轉真人」，由真人客服人工確認後再處理，不要讓系統代為承諾或回覆。
• 語言誤判：短訊息（例如只打「？」）語系判斷不準很正常，這種情況預設派到中文主線並交人工，不要硬分。
• 尖峰塞車：API 有速率限制，尖峰時要做好佇列與重試，避免訊息卡死或重複派單。

台灣中小企業情境案例

台中一家經營保健食品的電商，旺季時 LINE、蝦皮聊聊轉信、官網表單、FB 私訊每天合計約 200 則來訊，三位客服每天上午幾乎都在「分訊息」而不是回訊息，常有退費申請拖到隔天才被看到，客訴因此升溫。導入這條全通路分流後，所有來訊統一進單、AI 自動分類派單，客服早上一上線就直接從自己的 Slack 頻道接案，分揀時間幾乎歸零；退費與客訴類訊息被即時標高優先並轉給資深專員，過去拖到隔天的情況明顯改善。主管也終於能從量能統計看出「每週五出貨日 LINE 進單會暴增」，提前把人力排上去。團隊回饋是「同樣三個人，現在感覺像四個人在做」。

延伸應用

這條流程是客服自動化的入口，往前往後都能擴充。往前，可在派單前先接一層 FAQ 自動回覆，讓「出貨時間、退貨政策」這類標準問題直接被擋下，只把真正需要人的訊息往下送。往後，可把派單結果接到 /workflows 裡的工單派發流程，自動開立工單並追蹤 SLA；案件結束再接滿意度調查收尾。你也可以把量能統計接到 /automation 的排程與告警，做成每日客服日報自動寄給主管。想看更多客服與電商自動化的組合設計，可參考 /recipes 裡的相關配方，依自己的通路與團隊規模拼出最合適的支援鏈。

流程圖

用到的工具

更多「企業職能」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →