跨境客服的難點不是「會不會答」，而是「時區、語言、訂單狀態、退換貨規則」四件事同時對上
很多人把跨境客服當成「本地客服 + 翻譯」。真正做過就會發現，難點在四個地方同時疊加：
| 差異點 | 具體表現 | 對 AI 客服的要求 |
|---|---|---|
| 語言 | 同一套商品、同一套政策，要用多種語言表述 | 回答要「按語言重寫」，不是逐句機翻 |
| 時區 | 客戶在別人的白天提問，你的團隊在睡覺 | 要嘛全時段自動應答，要嘛明確告知回應時間 |
| 訂單與物流 | 狀態分散在平台後台、物流商、倉儲系統 | 必須能查真實狀態，不能憑印象答 |
| 政策與合規 | 退換貨、關稅、隱私條款各市場不同 | 回答必須有出處，越界要拒答 |
這四點決定了：跨境 AI 客服的第一性問題不是「答得像不像人」，而是「答的資訊是不是真的、是不是這個市場適用的」。任何一條答錯，代價都比本地客服高——跨境退換貨成本、糾紛率、平台考核都更敏感。
多語客服最常見的失敗方式，是把中文 FAQ 機翻成十種語言就上線。結果是語法沒錯但語氣生硬，客戶讀得出「這是翻譯的」，信任度直接掉。
可行的做法是按語言維護知識條目，而不是維護一份中文再翻譯：
| 做法 | 優點 | 代價 |
|---|---|---|
| 一份中文 + 機翻 | 維護成本最低 | 語氣生硬，專業術語易錯，客戶體驗差 |
| 每種語言獨立維護 | 表達自然、術語準確 | 維護量成倍增加，容易不同步 |
| 中文為母版 + 人工校訂各語種 | 平衡：結構同步、表達道地 | 需要一次性投入校訂，之後按變更同步 |
建議走第三條：中文（或英文）作為結構母版，每種目標語言由懂當地表達的人校訂一遍，之後政策變更時只改差異部分。判據很簡單：讓目標語言的母語者讀一遍，如果他能指出「這句像是翻譯過來的」，就還沒過關。
另外要注意語言識別與切換：客戶可能用非你支援的語言提問，也可能中英混寫。策略應該是「識別不出就明確說明支援哪些語言，並給出人工入口」，而不是硬猜著答。
這是跨境客服裡唯一不能靠知識庫解決的部分。訂單狀態、物流軌跡、清關進度都是即時資料，必須透過介面查，不能寫進知識庫當靜態答案。
把可用資料源列清楚：平台訂單介面能拿到什麼欄位、物流商能拿到什麼節點、倉儲系統能不能查庫存。很多團隊一上來就設計對話流程，最後發現「清關進度」根本沒有介面——那這段就只能給「預計時效 + 人工入口」，不能假裝能查。
查訂單必須驗證身分（訂單號 + 電子郵件/手機末幾碼等），否則等於把別人的訂單資訊暴露給任何人。這一步是安全底線，不是體驗優化。驗證失敗時給統一話術，不要提示「訂單號對不對」這類可被枚舉的回饋。
介面逾時、訂單不存在、狀態異常，都要有明確話術並轉人工。最危險的行為是「基於相似訂單推測一個狀態」——客戶按錯誤狀態行動（例如以為已出貨而放棄催單），後果比直接說「我需要幫你轉人工核實」嚴重得多。
這條主線的本質是把 AI 客服當成一個會呼叫工具的助手，而不是一個會說話的搜尋框。工具呼叫的邊界、失敗處理、權限驗證，都是工程問題，不是提示詞問題。
退換貨是糾紛高發區，也是最容易被 AI「好心答錯」的地方。模型很容易把「7 天無條件退貨」推廣成「都可以退」，把「不影響二次銷售」理解成「拆了也能退」。
正確做法是把政策寫成結構化規則，由程式判定，模型只負責把判定結果講清楚：
# 規則示意（欄位與閾值以你實際政策為準）
條件：
1. 是否在退貨窗口內（按簽收日 + 政策天數）
2. 商品類別是否屬於不支援退貨類（客製、生鮮、貼身用品等）
3. 是否已拆封 / 是否影響二次銷售
4. 是否屬於品質問題（影響運費承擔方）
輸出：
- 可退 / 不可退 / 需人工判定
- 運費承擔方
- 客戶下一步需要做什麼（附入口）要點：規則判定和話術生成要分開。規則由程式算，話術由模型按語言生成——這樣政策變更時只改規則表，不用重訓或改提示詞；同時模型也不會「自由發揮」出超綱承諾。
跨境團隊不可能 24 小時有人。AI 客服的價值之一就是覆蓋「無人時段」，但前提是把邊界講清楚：
| 時段 | AI 能做什麼 | 話術要點 |
|---|---|---|
| 有人線上 | 常規問答 + 查詢，複雜問題轉人工 | 正常應答，轉接時說明預計等待 |
| 無人值守 | 常規問答 + 查詢 + 登記工單 | 明確告知「人工將在 X 小時內回覆」，不要讓客戶以為有人在等 |
| 大促 / 異常 | 優先答高頻問題，主動說明延遲 | 提前準備「物流延遲」「庫存告急」的固定話術 |
一個常被忽略的細節：「預計回覆時間」要按客戶所在時區表達，而不是按你的時區。客戶看到「我們將在 8 小時內回覆」比看到「台北時間 18 點前」有用得多。
AI 客服做得好不好，很大程度看它什麼時候願意放手。轉人工的觸發條件建議明確寫死，不要交給模型自由判斷：
① 客戶明確要求人工；② 涉及金額爭議、投訴、法律與隱私問題；③ 連續兩輪未能解決或客戶表達不滿；④ 工具呼叫失敗（查不到訂單/物流）。
把對話摘要、已查到的訂單資訊、客戶語言與所在時區一起交給人工。沒有上下文的轉接等於讓客戶重講一遍，體驗比不轉還差。
人工接手後，AI 不應繼續插話。這條看起來瑣碎，實際是最容易被客訴的點——客戶已經在和人溝通，機器人還在自動回覆。
知識庫是跨境 AI 客服的地基。建得好不好，直接決定回答品質的天花板。
| 紀律 | 做法 | 不這麼做會怎樣 |
|---|---|---|
| 按市場分域 | 不同市場的政策、時效、關稅說明分開維護 | 把 A 市場的政策答給 B 市場客戶，直接產生糾紛 |
| 帶出處與生效時間 | 每條政策標註來源與生效日期 | 政策已變更但知識庫沒更新，答的是舊規則 |
| 區分「事實」與「建議」 | 事實類（時效、政策）嚴格照抄；建議類（怎麼選尺碼）可靈活表達 | 把建議當事實承諾，產生超綱承諾 |
關於知識庫檢索本身的技術細節（切分、混合檢索、權限隔離），可以看《AI Agent 知識庫踩坑》——那篇講的是通用方法，跨境場景額外要加的就是「按市場分域」這一層。
「保證 X 天到貨」「一定能退」這類承諾，遇到物流延誤或政策變化就會被拿來追責。改為「通常 X 天」「符合條件可退，具體以政策為準」。
關稅、清關、發票、合規申報屬於專業領域，AI 客服只應說明「流程與所需文件」，具體金額與法律責任一律轉人工或引導至官方渠道。
完整地址、完整電話、支付資訊不應在對話裡複述。需要確認時只顯示遮罩值（如末幾碼），這也是很多市場的資料保護要求。
上線前逐項打勾，任何一項沒驗過都不要宣布「做好了」。
| # | 驗收項 | 判據 |
|---|---|---|
| 1 | 多語回答品質 | 每種上線語言抽 20 條真實問題，母語者判定「不像翻譯」 |
| 2 | 訂單查詢身分驗證 | 錯誤憑證查不到任何訂單資訊，且回饋不可被枚舉 |
| 3 | 查不到時的備援 | 介面失敗/訂單不存在時 100% 轉人工，不推測狀態 |
| 4 | 退換貨規則一致 | 規則表判定與人工判定抽樣比對，無系統性偏差 |
| 5 | 轉人工觸發 | 四類必轉場景逐條測試，全部命中 |
| 6 | 轉接上下文完整 | 人工側能看到摘要 + 已查資訊 + 語言與時區 |
| 7 | 無人時段話術 | 按客戶時區表達預計回覆時間，無「台北時間」這類內部表述 |
| 8 | 合規話術掃描 | 全量話術 grep 承諾型表述、稅務法律建議、隱私複述，命中為 0 |
先做「母語者讀一遍」的驗收，通不過就按語言重寫，別指望模型自動道地。
介面查不到就轉人工。寧可多說一句「我幫你核實」，也不要給一個錯的狀態。
政策寫成結構化規則表由程式判定，模型只負責表達。政策變更時改表，不改提示詞。
按市場分域維護，檢索時帶上市場維度過濾。這是跨境場景與本地場景最大的結構差異。
轉接時自動附對話摘要與已查資訊，避免客戶重講一遍。
明確告知「人工將在 X 小時內回覆」並按客戶時區換算，不要讓客戶空等。
跨境電商 AI 客服的落地順序，建議是：先打通訂單與物流查詢（有真實資料才敢答）→ 再整理退換貨規則（把最容易出錯的部分鎖死）→ 然後做多語知識庫（決定體驗上限）→ 最後調時區與轉接（決定備援品質）。反過來做——先追求「回答得像人」，再補資料源——通常會在第一次訂單查詢失敗時全線崩塌。
如果你的客服團隊同時用著多個 IM 平台（例如本地用企微/釘釘、海外用 WhatsApp/Telegram），建議先解決「一個後台統一接入」的問題，再談 AI 能力——否則每接一個渠道就要重做一遍邏輯。多平台接入的架構見《AI Agent 與 IM 平台打通：接入架構》。