AI 客服轉人工規則要在 AI 客服上線前寫清楚，而不是等客訴發生才補。台灣中小企業最常見的風險，不是 AI 完全不能回答，而是它在不該回答的時候繼續回答：客戶已經生氣、想退費、涉及付款或個資、正在比較高價方案，或連續兩輪都沒有得到解決。安全的做法，是先把「可自動回、可草擬、必須真人、不得回」分級，讓 LINE、網站聊天與 CRM 都照同一套接手規則運作。
這篇文章寫給已經使用 LINE 官方帳號、網站表單、聊天室或 CRM 的台灣 SME。目標不是降低所有轉人工率，而是把低風險問題交給 AI，把需要信任、判斷與責任的時刻交給真人。這樣客服效率才會變好，行銷與業務也不會因為機器人卡住高意圖客戶而漏單。
AI 客服轉人工規則的 5 個判斷點
Kustomer 的 AI customer-service best practices把 human handoff、團隊訓練、資料品質與透明告知列為導入重點，也建議追蹤 escalation rate、CSAT、FCR 和 AHT 等指標。Weave 的 chatbot-to-human handoff guide則指出複雜問題、客訴、建立信任與高價值線索常需要真人。把這些原則放到台灣中小企業情境，可以整理成以下 5 個判斷點。
判斷點一：AI 沒有足夠來源或信心
如果 AI 的答案找不到知識庫來源、引用到過期政策，或只能用模糊語氣猜測，就要轉真人。客服知識庫應把每個答案標上來源文件、最後更新日、負責人與適用條件；沒有來源的問題，只能請 AI 收集資訊或回覆「我需要請專人確認」。
這條規則尤其適用於保固、交期、客製報價、產品限制、醫療或專業建議。AI 可以先問清楚型號、訂單編號或使用情境，但不能自己創造例外承諾。
判斷點二：客戶出現負面情緒、客訴或取消意圖
當客戶出現「我要取消」「我要客訴」「你們都不處理」「我要退費」「我已經等很久」等訊號，不應再讓 AI 用 FAQ 反覆回覆。Freshworks 對 AI-to-human handoff 的文章強調，是否轉人工應以信任而非技術能力判斷；轉接的溫度與上下文，會影響客戶是否留下。
實務上，AI 應立即做三件事：承認問題、告知將轉專人、整理摘要給客服。真人接手時要看得到客戶原話、AI 已回覆內容、訂單或會員資訊、建議優先級，而不是要求客戶重新說一次。
判斷點三：付款、退費、保固、合約與個資
涉及付款狀態、退款條件、保固例外、合約修改、身分資料、地址、電話、醫療或財務資訊時，AI 至少要降級為草稿模式。台灣《個人資料保護法》第 5 條要求個資利用不得逾越特定目的必要範圍；第 8 條要求蒐集時告知目的、類別、利用期間、地區、對象、方式與當事人權利；第 20 條則規範非公務機關在特定目的外利用個資。正式導入前應以全國法規資料庫最新條文與公司法務判斷為準。
如果使用外部 AI API，還要確認資料保留與使用政策。OpenAI Platform data controls說明 API 資料預設不會用於訓練或改善模型，除非使用者明確選擇分享；同頁也說明 abuse monitoring logs 與保留控制。企業仍應先遮蔽或排除不必要個資，再把對話送入 AI 流程。
判斷點四：高價值線索與需要判斷的成交情境
AI 客服常被看成客服成本工具，但它也會遇到行銷與業務線索。例如客戶問「企業方案怎麼算」「可以到場簡報嗎」「我們有三個據點」「月底前要上線」時，這不是普通 FAQ，而是高意圖商機。AI 可以收集需求、預算、時程與聯絡方式，但應轉給業務或顧問。
轉人工規則要和 CRM 欄位對齊：來源通路、需求類型、預算級距、急迫性、下一步、負責人與 SLA。若只讓 AI 回一段制式介紹，可能會讓真正想買的客戶離開。
判斷點五：同一問題重複兩輪仍無法解決
很多 bot loop 不是因為 AI 完全錯，而是它一直用不同說法回答同一個無效答案。建議設定「兩輪規則」：同一意圖連續兩次沒有解決、客戶重複同一問題、或 AI 沒有找到新來源，就轉真人。
這條規則也能幫知識庫維護。每次轉人工都要記錄原因：知識庫缺內容、政策不清、AI 判斷錯、客戶情緒升高、CRM 資料不足，或通路設計不良。下週修知識庫時，先修這些高頻轉接原因。
LINE、網站與 CRM 的轉接表
| 情境 | AI 可以做 | 必須轉人工 | CRM 要記錄 |
|---|---|---|---|
| 營業時間、地址、基本流程 | 直接回覆並附來源 | 來源過期或客戶追問例外 | 問題類型與通路 |
| 退費、保固、付款 | 收集訂單與問題摘要 | 需要承諾、例外或金額判斷 | 訂單、風險、負責人 |
| 客訴或負面情緒 | 致歉、告知轉專人、摘要 | 立即轉 | 優先級、情緒、時限 |
| B2B 詢價或高價服務 | 問需求、時程、預算、聯絡資訊 | 有明確採購或比較訊號 | 商機階段與下一步 |
| 個資刪除、退訂、資料疑慮 | 說明申請方式 | 涉及身分確認或資料處理 | 請求類型與處理狀態 |
若主要通路是 LINE，請把轉接規則設計在整體 bot server 與客服流程中，而不是只看單一回覆功能。LINE Developers Messaging API overview說明，Messaging API 可透過 webhook 接收使用者訊息、由 bot server 回覆，並支援 reply、push、多種訊息類型、取得使用者傳送內容、rich menu 與帳號連結。這些能力要和 CRM、客服排班與資料告知一起設計。
30 天上線順序
第 1 週：列出 20 個必轉人工情境
從最近的 LINE、電話、表單與客服信箱挑出最容易引發不滿或成交的情境。不要先做漂亮流程圖，先列出「絕對不能讓 AI 自己回答」的清單。
第 2 週：寫轉接話術與摘要格式
每種轉接都要有固定格式：一句安撫、一句告知轉專人、一段給客服看的摘要、需要補問的欄位。摘要要讓真人接手時知道發生什麼事。
第 3 週：用真實對話測試 bot loop
拿客戶原句測試，不要只用理想提問。特別測試錯字、情緒化訊息、半夜詢問、付款疑慮、重複追問與高價方案詢問。
第 4 週：小流量上線並看升級原因
先讓 AI 處理低風險問題或只做客服助理。每週檢查轉人工率、轉接後等待時間、人工修正率、錯誤回覆、商機建立數與客訴變化。
誰適合，誰不適合
這套規則適合客服與行銷共用 LINE 官方帳號、網站聊天室、CRM 或表單的中小企業，也適合售後、預約、B2B 詢價、保固與退費情境較多的團隊。不適合沒有客服排班、沒有人維護知識庫、或任何問題都需要專業診斷的公司。若真人無法接手，就不要承諾即時轉人工；應改成收件、排程與明確回覆時間。
資訊更新與來源
本文於 2026 年 6 月 11 日整理。SERP 與 benchmark 參考了 Kustomer、Weave、Freshworks 等 AI 客服轉人工與客服最佳實務頁面；事實性與平台/資料處理建議優先使用官方或主要來源：LINE Developers Messaging API overview、OpenAI Platform data controls、全國法規資料庫個人資料保護法、AWS SMB AI customer-service guide。AI 客服平台功能、LINE API 能力、資料保留政策與台灣法規可能更新，正式上線前應以供應商合約、隱私條款與最新法規為準。
結論：好的 AI 客服不是少轉人工，而是轉得準
AI 客服轉人工規則的重點，不是把轉人工率壓到最低，而是讓客戶在需要信任、責任與判斷時快速找到人。台灣中小企業可以先從 5 個判斷點開始：來源不足、負面情緒、付款退費個資、高價值線索、兩輪仍未解決。當這些規則和 LINE、網站、CRM 串在一起，AI 才能真正幫客服省時間，也幫行銷與業務留住機會。
FAQ
AI 客服轉人工規則應該由誰負責？
客服主管應負責日常規則，行銷或業務補充高價值線索條件，涉及個資、合約或法規的情境要由管理者或法務確認。
轉人工率越低代表 AI 客服越成功嗎？
不一定。低風險問題可降低轉人工率，但客訴、退費、高價值線索若不轉真人，可能會造成信任下降或商機流失。
LINE 官方帳號做 AI 客服時，何時要轉人工？
客戶要求真人、情緒升高、涉及付款退費個資、同一問題兩輪未解決、或出現明確採購訊號時，都應轉人工或建立 CRM 任務。
AI 轉人工時要交給真人哪些資訊？
至少要有客戶原話、AI 已回覆內容、問題分類、訂單或會員線索、建議優先級、需要真人決策的原因與下一步。
沒有即時客服人力可以導入 AI 客服嗎？
可以，但不要承諾即時轉人工。應改成收集資料、建立待辦、告知回覆時間，並把高風險問題排除在自動回覆之外。