企業導入 AI 客服，通常先從常見問題、需求蒐集與初步回覆開始。但當 AI 開始查詢訂單、辨識多個需求，甚至協助執行部分服務動作，真正影響客戶感受的往往不是「AI 回答得多快」，而是它遇到不能處理的案件時，能不能把工作完整交給下一位同仁。
2026 年 9 月 15 日，Air India 擴大客服 AI 的應用範圍，從退款延伸到多主題 Email、姓名更正與客服知識助理。報導提到，系統需要跨系統蒐集與驗證資料，符合條件的回覆也設有信心門檻與人工監督。這項發展透露一個重要變化：**AI 客服正在從「回答問題」走向「參與服務流程」。**一旦 AI 開始判斷、查詢或執行，轉人工就不能只是丟出一句「請稍候，由專人為您服務」。
如果接手者看不到前面的對話、查詢結果與停止原因，客戶仍要重新說明；如果系統沒有建立案件、責任人與處理期限，轉人工只代表換了一個窗口，問題並沒有真正進入可管理的流程。
轉人工最常失敗的地方，不是速度，而是上下文斷掉
常見的情況是：客戶先在聊天視窗說明需求，AI 問了幾個問題，也查到部分資料；後來因為權限、風險或規則限制而轉人工。客服人員接手時，卻只看到「客戶要求專人處理」。
於是客服必須再次確認姓名、訂單、問題內容與期望結果。客戶覺得自己已經講過，員工則擔心漏掉細節。若案件又需要財務、物流或主管協助，同一段資訊可能再被重述兩三次。
這種摩擦通常不是 AI 模型單獨造成，而是交接設計只處理了「把對話轉給人」，沒有處理「把工作轉進企業流程」。企業可以先檢查三件事：
- AI 已經知道哪些事，接手者是否看得到？
- AI 為什麼停止，接手者是否知道要判斷什麼？
- 轉出後由誰負責、何時回覆、最後如何結案？
真正完整的轉人工，不只是換人回話，而是把一段對話轉成可追蹤、可分工、可結案的服務案件。
一份可用的交接內容，至少要讓接手者回答七個問題
企業不一定要保存冗長逐字稿，但應把對話整理成接手者能快速採取行動的結構化內容。
第一，客戶是誰。包括客戶或公司、聯絡人，以及必要的身分驗證狀態。不是每個人都應該看到完整個資，欄位仍要依角色與權限顯示。
第二，這次在處理什麼。把客戶的主要目的與次要需求分開。例如「修改收件地址」與「重開發票」可能出現在同一段對話，但需要不同單位處理。
第三，相關資料在哪裡。包含訂單、產品、合約、服務紀錄或先前案件的關聯，不要只把號碼複製進備註，卻沒有連回正式資料。
第四，AI 已經做過什麼。哪些資料查過、哪些規則比對過、哪些問題問過，都應簡短記錄，避免人工重做。
第五，為什麼要轉人工。可能是信心不足、客戶明確要求、超出權限、需要例外核准、涉及客訴，或同一問題連續處理失敗。
第六，下一個決策是什麼。接手者應知道要確認地址、判斷退款資格，還是核准特殊價格，而不是重新閱讀所有對話才猜出任務。
第七，何時必須完成。案件需有接手時間、預計回覆時間與逾期處理方式，才能避免訊息停在某個人的收件匣。
不要只用「信心分數」決定轉不轉人工
信心分數可以當條件之一，但不能成為唯一標準。企業應同時考慮風險、權限與客戶意圖。
例如，AI 對公司退換貨規則的理解可能很有把握，但只要案件涉及高額退款、合約承諾、正式客訴、個人資料更正或特殊價格，仍可能需要人工確認。反過來，某些低風險需求即使資訊不完整，也可以先請客戶補件，而不是立刻轉給人工。
較實用的轉人工條件可包括：
- AI 無法確認關鍵身分、訂單或適用規則。
- 客戶明確要求人工協助。
- 同一意圖連續失敗，或客戶需要重複說明。
- 案件涉及退款、價格、合約、客訴、敏感資料或例外承諾。
- 後續動作超出 AI 或目前使用者的權限。
- 已接近服務期限，繼續追問可能造成延誤。
這些條件應由企業依風險分級，而不是直接套用外部案例的固定門檻。Air India 的 95% 信心門檻是特定企業與特定案件的設計，並不代表所有產業都應採用同一數字。
示意情境：同一段對話裡，有一件事能做，另一件事要確認
假設客戶透過線上對話提出兩個需求：修改尚未出貨訂單的地址，並要求重開發票。
AI 可以先辨識客戶與訂單、確認出貨狀態，也能根據規則判斷地址是否仍可修改。但重開發票可能需要財務確認原發票狀態與公司資料，因此不能把整段對話都當成「已處理」，也不應要求客戶重新聯絡財務。
較好的流程是：
- AI 將兩個需求拆開，記錄各自狀態。
- 可處理的地址變更依權限執行，重要動作保留確認機制。
- 發票需求建立服務案件，附上對話摘要、客戶與訂單關聯、已查資料、轉交原因及待確認事項。
- 案件分派給財務或指定角色，設定接手與回覆期限。
- 系統回覆客戶已受理的項目、尚待確認的項目，以及後續聯絡方式。
- 人員完成後，將結果、處理依據與對客回覆寫回案件。
這裡的重點不是讓 AI 盡量多做，而是讓每一項需求都有清楚狀態。 AI 能做的可以繼續，必須由人判斷的也不會消失。
轉人工之後，案件還需要責任人、狀態與逾期處理
有了摘要仍不等於完成交接。若案件沒有明確的 Owner，大家都能看到，卻不一定有人負責。
企業可以依實際流程設計少量而清楚的狀態，例如「待接手、處理中、等待客戶、等待內部、已解決、已結案」。狀態不要過多，但每一個狀態都要回答：目前球在誰手上？下一個動作是什麼？期限是否暫停？
此外，接手時間與解決時間應分開管理。某位同仁很快按下接手，不代表客戶問題已解決。較具管理價值的觀察項目包括：
- 轉人工後多久有人承接。
- 交接內容是否完整，人工還需不需要重問。
- 案件是否在承諾時間內首次回覆與完成。
- 是否因分派錯誤、資訊不足或規則不清而再次轉派。
- 結案後是否又因同一問題重開。
如果案件即將逾期，系統應能提醒負責人或通知主管；如果卡在客戶補件，也要留下聯絡紀錄與下一次提醒，而不是讓案件看起來一直「處理中」。
結案不是把案件關掉，而是把結果寫回下一次服務
轉人工流程最容易被忽略的最後一步，是把人的處理結果重新變成組織可用的資料。
結案時可記錄實際處理結果、適用規則、是否屬於例外、對客承諾、相關文件與後續追蹤。若同一類案件反覆出現，也應標記是否需要調整 FAQ、知識內容、轉人工條件或內部流程。
這不是要把員工的每一句話拿去訓練模型，而是先讓企業知道：AI 常在哪裡停下來？人工最後怎麼判斷？哪些情況其實可以標準化？哪些必須持續保留人工覆核？
當結果有一致的分類與來源，企業才有機會逐步改善，而不是讓 AI 每次遇到相同問題都再次轉人工。
niio 可以放在「對話變案件、案件進流程」的中間層
依 niio 官網公開資訊，niio CRM 可集中管理客戶資料、聯絡人、互動紀錄與服務需求，AI 可支援客服詢問、需求蒐集與常見問題回覆。niio 的 AI Agent、AI Action、權限與 Workflow 能力，則可把資料查詢、欄位整理、API 呼叫、任務建立與人工確認接進既有流程。
因此，企業可以把導入重點放在一條明確鏈路：
客戶提出需求 → AI 蒐集與判斷 → 符合條件則處理 → 超出條件則建立案件 → 指定人員與期限 → 人工完成 → 結果回寫。
在價格、退款、合約、客訴與敏感資料等高風險情境，仍應設定角色權限、執行前確認與可追溯紀錄。niio 的位置不是取代客服人員，而是協助企業把 AI 與人工之間容易中斷的工作接成一套可管理流程。
導入時，先選一種高頻轉人工情境
不要一開始就把所有客服管道與所有問題都放進同一套自動化。可以先選一種高頻、邊界清楚、目前最常需要重複說明的情境，例如：訂單資料更正、發票需求、售後預約或服務案件查詢。
接著完成四個步驟：
- 盤點目前轉人工時缺少哪些資料。
- 定義 AI 可以做、必須停、需要誰確認的邊界。
- 建立案件欄位、負責角色、狀態與期限。
- 每週檢查重複說明、錯誤分派、逾期與重開原因。
先把一種交接做完整，往往比一次增加更多 AI 回覆能力更有價值。因為對客戶而言，好的服務不是每一題都由 AI 解決，而是無論由 AI 或人工接手，都不用重新開始。
常見問題
AI 客服在什麼情況下應轉人工？
除了信心不足，也應考慮客戶明確要求、重複失敗、風險類型、權限限制、敏感資料與服務期限。高額退款、價格承諾、合約、正式客訴等情境通常更需要人工確認。
轉人工時一定要保留完整逐字稿嗎？
不一定。較重要的是留下可執行的摘要、需求拆分、客戶與相關紀錄、AI 已做事項、停止原因、待決策項目、責任人與期限。逐字稿可依稽核、隱私與保存政策決定是否保留。
AI 客服可以完全自動結案嗎？
低風險、規則明確、資料完整且權限允許的案件可以評估自動處理；涉及例外承諾、合約、客訴、金額或敏感資料時，應保留人工確認與追溯機制。
如何判斷轉人工流程是否改善？
可以觀察客戶重複說明率、交接資料完整率、首次承接時間、期限內完成率、再次轉派率與案件重開率。這些是企業流程指標，不等同 SEO 排名或生成式搜尋曝光。
返回文章列表