AI 客服何時轉人工怎麼定
AI 客服上線前，先寫明哪些情況轉給人工、工單要帶上哪些前文，以及哪個時段由誰看隊列。轉交分成事先料到的交接，和助理對不上時的退回。草稿能不能發出，寫在客服機器人那一篇；這裡寫對話離開助理、進入坐席隊列的規則。
目錄
上線前先寫轉交，不在對話裡現編
轉交規則寫在上線之前：哪一類問題一定交給人、哪一類先由助理答到哪一步、人接過之後要看見哪些前文、人沒有在線時顧客看到什麼。規則由負責客服的人定稿，坐席主管確認隊列和時段。助理上線之後才在對話裡臨時決定轉不轉，隊列會在忙的時段堆滿，閒的時段又沒有人接敏感問題。
機器人那一篇處理的是：重複問題先分類、用已核准文本草擬、由坐席決定發不發出。權限那一篇處理的是內部助理誰可以讀哪些資料。對外客服的轉人工是第三件事：對話離開助理、進入坐席隊列。三篇不要併成一句「都要人工看過」。分別見 AI客服機器人怎麼做、企業AI助理如何設定權限。渠道怎麼接到坐席每天打開的畫面，見 客服、銷售及語音助理。
Zendesk 要先定策略和渠道
2026年10月20日閱讀的 Zendesk：為 AI 代理設定升級策略與流程 寫明，詢問若複雜、緊急或敏感，AI 代理有時要把查詢轉給人工。上線前先制定升級策略並設計升級流程，再用對話建構器裡的升級區塊把路徑做出來。該頁寫明可為訊息和電郵的 AI 代理建升級流程，並註明支援方案為 Team、Professional 或 Enterprise。該頁沒有刊登日期。
同一頁把升級策略定義成：哪些查詢要升級、走哪一個渠道。它寫通常有訊息和電郵兩個渠道，並要考慮坐席人數、坐席是否在線與辦公時間、該渠道的對話量、查詢的複雜和緊急程度。頁上的例子是：四人團隊、朝九晚五、每天約 200 至 250 則對話時，若訊息升級太多，坐席會過載、顧客會等很久；該例子建議把訊息升級留給會直接影響收入或顧客滿意的高影響問題，例如產品問題和運送失敗，並在助理已無法把顧客引到自助內容時才提供升級。這是該頁的例子，不是各公司都要抄的人數或通數。公司把自己的時段、人數和哪幾類問題走訊息、哪幾類走電郵，寫在策略頁上。
計畫內交接和對不上時的退回
2026年10月20日閱讀的 IBM：連接到真人坐席 把升級定義成：助理已接上支援的服務台時，在需要時把對話轉給真人。該頁寫明，要用這個功能，助理須以網頁聊天或電話與顧客互動，而且要先加好服務台整合。該頁列出的服務台包括 Genesys、NICE CXone、Salesforce、Twilio Flex、Zendesk，以及自備服務台。該頁沒有刊登日期。
同一頁把轉交分成兩種。計畫內升級是事先料到、一定要交給人的情況，例子包括顧客要求的服務無法只靠助理完成，以及需要人處理的敏感事項，例如喪親福利或投訴。退回升級是顧客從助理得不到幫助的意外情況，例子包括：顧客反覆提出對不上任何已定義動作的問題、反覆給出無效答案、或明確要求找人。退回由內建的 Fallback 動作處理，預設就是發起轉給真人。客服規則頁用這兩個名字分開寫：哪些句子屬於計畫內、哪些屬於退回，不要合成一個「不滿意就轉」。
工單要帶上顧客已經講過的話
Zendesk 設計流程一節寫明，升級前可以先做這些事，讓交接和後續對話更有效：收集訂單編號、姓名或電郵；為既有流程加標籤並更新欄位；找出適合接手的坐席。然後用範本回覆設計升級流程；需要多於一條流程時，再加範本。IBM 頁寫明，助理發起轉交時，坐席在自己的儀表板上收到通知，並能看到顧客與助理的聊天歷史。規則頁把「必須帶上的前文」寫成清單：訂單或案件編號、顧客用來聯絡的渠道、已經收集的姓名或電郵、助理最後停在哪一題、聊天紀錄是否隨工單走。
清單上沒有的項目，不要在轉交當下要求坐席回頭再問一遍顧客剛剛講過的話。Zendesk 另註明：對話裡至少要有一則顧客或 AI 代理的訊息，才可以升級。空對話不要開出一張沒有內容的工單。標籤用客服已經在用的那一套，不在助理裡另起一組坐席看不懂的詞。加標籤和改欄位的動作寫在流程上，並寫明寫進哪一個欄位。
誰在哪個時段看這個隊列
時段和隊列寫在策略頁，不寫在單一則對話裡。Zendesk 寫明，可以選擇只在坐席可繼續對話時才用訊息升級；同步渠道若已過坐席工作時間，可以改用電郵升級，並在路徑開頭用可用性區塊，讓流程先看辦公時間或坐席是否在線。轉給坐席時，預設進入整合 CRM 時指定的群組，也可以在詳細資料裡用「升級到團隊」改指定；升級失敗時，可以指定改走哪一段對話，例如系統回覆「升級失敗」。電郵升級的舊選項，該頁註明已不再建議。
IBM 的轉交步驟在動作的「然後」選 Connect to agent。可設定的訊息包括：坐席在線時對顧客說的話（預設是 Let's send you to an available agent）、坐席不在線時對顧客說的話（預設是 There are no agents available at this time. When one becomes available, we'll connect you.）、可選的給坐席的訊息，以及可選的指定隊列。該頁並註明：一旦轉交發生，這個動作就結束，不論顧客其後有沒有真的接上坐席。所以「轉交已發出」和「坐席已接起」要在紀錄上分成兩欄，不要把動作結束當成顧客已經被人接聽。隊列負責人的名字和時段寫在策略頁，請假時改的是這一頁，不是某一則歷史對話。
轉交失敗和坐席不在線分開寫
坐席不在線，是策略裡已經料到的時段問題：改走電郵、留下不在線的訊息、或約到下一個有人的時段。Zendesk 用可用性區塊做這個分支。IBM 用「坐席不在線」的回覆，預設告訴顧客目前沒有坐席、有人可用時再連接。兩頁都沒有規定等待秒數或服務水準，公司自己的等待標準寫在客服制度裡，並註明日期，不寫進這兩頁的引用。
轉交失敗是另一種情況：路徑已經決定要轉，但沒有交到指定的團隊或服務台。Zendesk 讓你指定失敗時改觸發的對話。IBM 寫明動作在轉交時就完成，即使顧客沒有接上坐席。規則頁因此要寫：失敗時顧客看到哪一句、工單落在哪一個隊列、誰在下一個工作時段清這個隊列。沒有這三行，失敗的對話會停在助理已經結束、坐席還沒看見的中間。電郵若設了自動化門檻，Zendesk 還提到升級後對話會帶上 escalated_by_ultimate 標記、助理不再回覆，工作流程要能認出狀態仍是 Open 且帶這個標記的工單。只有實際採用該電郵能力時，才把這個標記寫進清隊列的條件。
和草稿、內部權限不要混寫
價格、交期、退款和投訴要不要由人確認才發送，寫在客服機器人那一篇：助理可以草擬，坐席決定發不發出。那是「句子還在助理裡」。這一篇是「對話要離開助理」。一則投訴可以兩步都發生：先按已核准文本草擬能答的部分，再按計畫內升級把人或退款交給坐席，並帶上訂單編號和已經講過的話。不要因為內部知識庫有權限表，就以為對外隊列已經有主人。
內部助理的權限管的是員工能讀哪些文件。對外轉交管的是顧客對話進哪一個坐席群、在什麼時段。兩張表的人名可以相同，欄位不要混用。權限表沒有寫隊列時段；策略頁沒有寫文件目錄。上線檢查時分開看：坐席能不能在自己的畫面看見帶前文的工單，以及員工助理沒有被拿來回答這張對外工單。
上線前用一則對話走通
上線前用一則計畫內、一則退回，在預覽或測試環境走完。IBM 寫明，動作預覽窗裡不會真的轉交，只會用 Connect to an agent 的訊息確認步驟有觸發；要測試真正的轉交，需在已接上服務台的助理預覽頁進行。走測時核對：顧客看到的在線或不在線訊息是否為規則頁寫定的那一句、坐席是否看見聊天歷史或約定的欄位、失敗時是否落在指定隊列。走測的日期、對話編號和結果寫在策略頁末。
人數、等待時限和滿意度目標留在公司自己的客服制度裡。Zendesk 頁上的四人與每日對話量只是該頁例子。兩份說明都沒有給轉交成功率或必須幾秒內接起。策略頁寫完之前，用三件事看能不能上線：計畫內和退回是否分開、工單是否帶上約定的前文、每個時段是否有隊列負責人。三件事都在策略頁上，才讓助理對顧客開放轉人工。