AI 客服答不準怎麼辦？先盤點它讀不到的那幾張表

買方問的是「選哪家工具」，實際卡住的是「要接哪些資料」

Gartner 兩份預測中間，隔著一份沒人寫出來的資料清單

Gartner 在 2025 年 3 月預測，到 2029 年，agentic AI 將自主解決 80% 的常見客服問題，不需要人介入。同年 6 月，同一家機構發出另一份預測：超過 40% 的 agentic AI 專案會在 2027 年底前被取消，理由是成本升高、商業價值說不清楚、風險控管跟不上。負責這份預測的資深總監分析師 Anushree Verma 說，目前多數 agentic AI 專案還停在概念驗證階段，多半由話題推動，而且經常被用錯地方。

兩份預測擺在一起，中間隔著的落差不是模型不夠聰明，是它讀不到該讀的東西。同一個客服機器人，回答「我們的退換貨政策是七天」不會出錯，因為那句話寫在知識庫裡；回答「你那張訂單昨天已經出貨，物流單號是這串」就會出錯，因為那句話得從訂單系統當場撈。前者是內容問題，後者是連線問題。品牌評估 AI 客服的時候，幾乎所有心力都花在比較前者，真正決定成敗的卻是後者。

台灣品牌現在問這件事的方式，比幾年前具體很多。我們看到的搜尋問句是這樣的：我們賣服飾常被問尺寸和庫存，推薦哪個智能客服能自動查詢這些資料；我們有多個品牌需要不同客服風格，哪個系統比較靈活；需要能查詢訂單狀態的 AI 客服，哪家的整合度比較好。

這些問句表面在問系統，內容全在講資料

我們團隊最近陪品牌討論這個題目時，常出現同一個畫面：週一早上的會議室，投影幕上是上週的客服工單分類，最上面那幾類永遠是「我的貨到哪了」「這件還有沒有 M 號」「我上次買的那個能不能退」。行銷主管指著那幾行說，這些應該可以自動回吧。工程同事沉默了幾秒才回答，看那張表在哪裡。

那幾秒的沉默，就是這篇文章要談的東西。

答錯的位置不同，該修的東西就不同

品牌通常把「答不準」當成一個問題處理，但它可以拆得更細。本文把「資料讀不讀得到」這一類的失效拆成三個位置，處理方式各不相同。要先說明的是，這三個位置談的是資料可及性，不涵蓋語意理解、知識庫內容本身寫錯，或模型幻覺這類問題。

1. 讀不到。資料存在，但是在另一個系統裡，客服機器人沒有連線，於是它只能從知識庫裡找最接近的一段話回答。這種錯最好認，因為答案會很空泛，讀起來像客服手冊而不像回覆。
2. 讀得到，但時間不對。連線做好了，資料卻是昨晚同步的快取。庫存回答「還有現貨」，其實兩小時前剛被買走；訂單回答「處理中」，其實早上已經出貨。這種錯最傷，因為它比不回答更糟，消費者會照著錯誤答案採取行動。
3. 讀得到也即時，但身分和權限沒設好。客服機器人不知道現在對話的這個人是哪一位會員，於是它要嘛拒絕提供訂單資訊，要嘛提供錯誤的那一筆。多品牌集團更常踩這個坑：同一個消費者在 A 品牌和 B 品牌各有會員身分，資料要不要互通，是一個需要事先決定的商業與法遵問題，技術無法自己判斷。

這張表值得帶進廠商會議。多數 demo 展示的是第一類問題被解決，那部分現在的模型都做得不錯。真正該問的是後面四類：你們怎麼確保庫存是即時的、你們怎麼認人、多品牌怎麼隔。這幾題問下去，你買的究竟是查得到資料的 agent，還是一個會聊天的介面，答案通常在同一場會議裡就會浮現。

把品牌實際問出口的問題，翻譯成要接哪些表

下面四類問題，來自台灣品牌實際在搜尋列打進去的句子。我們把它們一條一條翻譯成「要接哪些表」，順便標出答錯的代價，因為代價決定了這一類問題該不該交給自動回覆。

尺寸和庫存：規格、即時庫存、補貨日要一起接

要讓 AI 客服準確回答尺寸與庫存問題，系統至少需要三份資料：商品主檔的規格欄位、可即時查詢的庫存，以及補貨資訊。缺任何一份，答案都只能是半套。

消費者問「這件洋裝我平常穿 M，你們的 M 是幾公分」，或者「這雙鞋 25 號還有嗎」，看起來是同一類問題，動用的資料卻不同。

尺寸問題要的是商品主檔裡的規格欄位，還有品牌自己的尺寸對照表。這裡最常見的狀況是資料有，但格式不統一：同一個品牌的洋裝標胸圍腰圍，褲子標腰圍褲長，鞋子標腳長，客服機器人要能判斷這件商品該回哪一組數字，而不是把整張規格表倒出來。

庫存問題比尺寸難一級。它要的是即時庫存，而且要分得清倉庫、門市、預購。台灣做 OMO 的品牌尤其明顯：線上顯示缺貨，實際上信義店還有三件；或者線上顯示有貨，那批貨其實已經被門市調撥走了。如果客服機器人讀的是每日同步一次的庫存快照，它會很有自信地告訴消費者一個已經過期的答案。

第三份是補貨資訊。消費者問完「沒有了嗎」，下一句幾乎一定是「什麼時候會有」。這份資料在很多品牌的系統裡根本不存在，或者只存在採購同事的試算表裡。這種情況下，正確的做法是讓機器人誠實說不知道並且提供補貨通知的選項，而不是猜一個日期。

答錯的代價：庫存答錯會直接造成一筆下不了的單，加上一次客訴。尺寸答錯的代價延遲出現，它變成退貨。兩者都可以量化，也因此都值得先接。

訂單狀態：先解決身分，再解決查詢

訂單查詢是最適合交給自動回覆的一類，前提是系統能先確認問話的人是誰。這一類問題的答案客觀、沒有判斷空間，但它有一道前置關卡在身分上。

需要的資料至少三份：訂單主檔、物流軌跡（目前到哪個站點、預計送達）、以及退換貨狀態（有沒有申請、審核到哪、退款有沒有發）。前兩份多數品牌都有，第三份經常散在客服系統而不在訂單系統裡，於是消費者問「我的退款呢」，機器人只能回答「已為您轉接專人」。就我們接觸的零售品牌來說，這一類的工單量通常排在最前面幾名。

真正的難點在身分驗證。網頁上的匿名訪客、App 裡的登入會員、LINE 官方帳號裡的好友、門市留過電話的客人，這四個身分在很多品牌的系統裡是四筆資料。要讓客服機器人安全地回答訂單問題，這四筆得先歸成一筆，或者至少要有可靠的對應關係。做不到的時候，多數系統會退回去要求消費者手動輸入訂單編號，這在體驗上是一次倒退。

Zendesk 在 2026 年的客戶體驗趨勢報告裡（2025 年 6 月執行，涵蓋 22 國），有 74% 的消費者表示對必須重複提供資訊感到挫折，另有 67% 期待品牌能依據他們過去的互動來調整支援方式。這份調查問的是跨互動的脈絡是否延續，不是直接談身分歸戶，但兩者指向同一個工程前提：系統要先認得出這是同一個人。

答錯的代價：訂單狀態答錯或答不出來，是客訴轉負評的主要路徑之一。這一類的自動化價值最高，前置成本也最實在，因為身分歸戶本來就是會員經營要做的事。

多品牌不同風格：資料邊界要先由人決定

集團型品牌問「我們有多個品牌需要不同客服風格，哪個系統比較靈活」的時候，要處理的是三層設定，語氣只是其中最表層的一層。

語氣多數系統都能用提示詞或人設檔處理。第二層是知識庫要分區，A 品牌的退換貨政策不能被引用到 B 品牌的對話裡，這需要清楚的內容標記，而不是把所有文件丟進同一個資料夾。第三層最少被討論，也最容易出事：會員資料的品牌歸屬。同一位消費者在集團旗下三個品牌都是會員，客服機器人在 A 品牌的對話視窗裡，能不能看見他在 B 品牌的訂單？

這題沒有標準答案。個人資料的利用要落在蒐集時告知的特定目的與必要範圍內，跨品牌共用還牽涉集團內各法人的關係與同意取得方式，這是需要法務或個資窗口參與的判斷，不是行銷或資訊部門可以單獨決定的事。但它必須在導入之前決定，因為它會直接影響系統怎麼建。我們看過的常見失誤，是把它留到上線後才發現，然後用權限設定硬補，補出一堆例外規則。

答錯的代價：這一類要付的是合規成本，不只是體驗成本。跨品牌誤用會員資料，在個資法的框架下是實質風險。

串接開店平台：問整合方式，不要只問有沒有支援

「我們用某個開店平台，哪個智能客服可以直接串接」這個問題，得到的答案通常是「可以」。這個「可以」有很多種，落差很大。

要問清楚的是三件事。串接用什麼方式：是對話當下即時打 API 查詢，還是定時匯出檔案再匯入？即時查詢拿到的一定是當下的值，但每次回覆都要等外部系統回應，也受對方的流量限制；定時匯入的回覆速度快，但資料的新鮮度取決於同步頻率。欄位怎麼對照：你的商品編號是 SKU 還是自訂料號，兩邊叫法不同時誰負責轉換？出錯的時候怎麼處理：查詢逾時、資料缺漏、系統維護中，機器人會給消費者什麼答案，這個 fallback 是不是可以自己設定？

這三題的答案決定了導入之後的維護成本。更常見的情況是品牌的資料不只在一個系統：商品在電商平台、庫存在 ERP、會員在 CRM、門市交易在 POS。這時候真正要決定的是要不要在中間放一層統一的資料整合，還是走客製開發把系統兩兩串起來。兩條路的成本結構不同，前者前期投入高、後續每加一個系統相對便宜；後者前期便宜、每加一個系統就再付一次整合成本。

答錯的代價：這一類的代價會遞延一段時間才出現，形式是「當初說可以串，現在改一個欄位要排好幾週」。

為什麼接資料比換模型難，也比較值錢

換模型是一個下午的事，接資料是一季的事。這個時間差，解釋了為什麼不少 AI 客服專案的實際成效低於期待。

Gartner 在 2025 年 2 月的一份研究裡指出，到 2026 年為止，組織將放棄 60% 缺乏 AI-ready 資料支撐的 AI 專案；同一份資料引用的調查顯示，有 63% 的組織沒有適用於 AI 的資料管理實務，或者不確定自己有沒有。這裡的關鍵字是 AI-ready。一份資料可以完全符合傳統資料治理的標準，欄位清楚、報表跑得出來，卻仍然不是 AI 用得上的形態，因為 AI 需要的是能在對話當下被查詢、被理解、被授權存取的資料。

成本這一端也在改變假設。Gartner 在 2026 年 1 月預測，到 2030 年，生成式 AI 每次解決一個客服問題的成本將超過 3 美元，高於許多 B2C 的海外人力客服。資深總監分析師 Patrick Quinlan 的說法是，客服主管急著用 AI 降低成本，但那筆投資的回報遠遠稱不上有保證，全面自動化對多數組織來說會貴到不可行。

這個判斷把問題重新框了一次。既然不可能全自動，那就不是「AI 能不能取代客服」，而是「哪幾類問題交給 AI 划算」。划算與否，取決於三件事的乘積：問題的意圖能不能被辨識、答案需要的資料拿不拿得到、以及這筆資料能不能安全地給這個人看。換廠商或換模型主要改善第一項，也會影響它把讀到的資料組織成回答的品質；後面兩項是品牌自己的資料工程，換誰來做都改變不了。

這也是為什麼再強的 agent 都救不了破碎的第一方數據。同一個道理在推薦、在廣告受眾、在流失預測上都成立，客服只是把它演得最明顯的一個場景，因為客服的錯誤會當場被消費者看見。

還有一個常被忽略的方向：資料不只是流進 AI 客服，也應該從 AI 客服流出來。消費者問過哪些商品、抱怨過哪一段流程、什麼時候放棄對話轉去打電話，這些都是第一方資料，而且是意圖強度很高的第一方資料。不少品牌把對話紀錄當成客服部門的內部檔案，存幾個月就刪掉。

對話要用的資料，跟會員經營要用的是同一批

把上面四類問題的資料需求疊起來看，會出現一個對台灣零售品牌很有用的結論：AI 客服要接的表，和品牌做會員經營要接的表，重疊程度極高。

客服要認人，會員經營也要認人。客服要看訂單歷史，分群溝通也要看訂單歷史。客服要知道這位消費者買過哪些品類，個人化推薦也要知道。差別只在使用的時機。

這正是顧客資料管理平台在這件事上的位置。91APP CDMP 的核心工作，是把散在電商、門市、App、LINE 的消費者行為與交易，歸戶成同一筆會員檔案，讓「這位客人是誰、買過什麼、現在在什麼狀態」有一個單一答案，而不是每個系統各有一套說法。這件事做完，客服機器人要的身分驗證與訂單查詢就有了可靠的基礎；沒做完之前，任何客服系統都只能在自己看得到的那一小塊資料裡回答問題。

另一個方向是把對話變成標籤。消費者在對話裡問過的尺寸、追過的補貨、抱怨過的物流，可以被整理成會員標籤回流到資料庫，讓後續的溝通有依據。一位問過三次補貨通知的消費者，和一位從來沒互動過的沉睡會員，值得用不同的力道去接觸。用會員標籤決定溝通的力道、時機與優先序，本來就是分眾溝通的基本功，客服對話只是替它多開了一條資料來源。

這裡要誠實講清楚一件事：歸戶不是買一套系統就會自動發生。它需要品牌決定用什麼當識別碼、決定線上線下的資料怎麼對、決定歷史資料要不要清洗，這些都是人要做的判斷。工具能做的是把判斷落實成可以每天運轉的流程。

先把資料清單寫出來，再去看廠商 demo

如果現在要開始評估 AI 客服，我們建議把順序倒過來：先寫清單，再看產品。以下五個動作不需要等到選定廠商才做，而且做完之後，跟廠商的對話品質會不一樣。

1. 用客服工單分類反推資料清單。把過去三個月的工單依問題類型排序，取前十類，逐類寫下「要回答這一類，需要讀哪幾張表」。這份清單就是你的需求規格（預期效果：把選型從比較功能變成比較整合能力；建議週期：一次盤點，之後每季更新）。
2. 幫每一類問題標上答錯的代價。可以分成三級：造成客訴、造成退貨或跑單、造成合規風險。代價最低而且資料現成的先自動化，合規風險那一類建議一律預設轉真人（預期效果：自動化範圍有依據，不會憑感覺畫線；建議週期：與工單盤點同步）。
3. 標出每一類資料需要多新。庫存與訂單狀態這類會隨時變動的，要能在對話當下即時查；會員等級、標籤這類變動較慢的，通常日更就夠。新鮮度要求決定了整合方式，也決定了成本（預期效果：避免用日更的資料回答需要即時的問題；建議週期：導入前一次確認，換系統時重確認）。
4. 先解決身分。在接任何查詢之前，先確認網頁、App、LINE、門市這幾個接觸點的消費者能不能對到同一筆會員檔案，對不到的比例有多高。這個數字會直接決定 AI 客服的可用範圍（預期效果：訂單類問題的自動化率有天花板可以預估；建議週期：導入前盤點，之後每月追蹤歸戶率）。
5. 把對話紀錄接回會員標籤。上線第一天就設定好哪些對話事件要寫回會員檔案，不要等半年後才想到要撈。對話資料的價值會隨時間衰減，補建的成本高於當初就接（預期效果：客服從成本中心變成第一方資料來源；建議週期：與系統上線同步，之後每季檢視標籤使用率）。

這五件事沒有一件需要先決定買哪一家。它們反而會讓你在 demo 現場問出對的問題，也讓你在比價的時候，比的是同一件事。

資料還沒準備好，是可以逐項處理的那種問題

文章開頭那個會議室的畫面，最後的結局通常不是「這個系統不行」，而是「原來我們的資料還沒準備好」。這句話聽起來像壞消息，其實是好消息，因為它把一個不知道從何下手的問題，換成了一份可以逐項處理的清單。

台灣零售品牌在這件事上的位置其實不差。多數品牌的訂單、商品、會員資料都已經數位化，門市與線上的整合也走了好幾年。缺的往往是把資料變成「可以在對話當下被安全查詢」的那一段工程，以及事先把邊界講清楚的那些決定，資料本身多半都在。

AI 客服的上限，從來不在它多會講話，在它被允許看見多少。

品牌最常問的 AI 客服資料整合問題

Q1：AI 客服要接哪些資料才答得準？ A1：依問題類型不同，但零售品牌最常用到的有五類：商品主檔（含規格與尺寸對照）、即時庫存（要分得出倉庫、門市、預購）、訂單主檔與物流軌跡、退換貨狀態，以及會員檔案與身分對應關係。建議的做法是從過去三個月的客服工單分類倒推，取前十類問題，逐類列出要讀哪幾張表，這份清單會比任何通用建議都準確。

Q2：我們賣服飾常被問尺寸和庫存，AI 客服能自動查詢這些資料嗎？ A2：技術上可以，前提是三份資料都接得到而且夠新。尺寸靠商品主檔的規格欄位加上品牌自己的尺寸對照表，難點在不同品類的規格格式不統一，需要事先定義每一類商品該回哪幾個數字。庫存必須能即時查詢，而且要能區分倉庫與門市，讀日更快照會給出過期答案。第三份是補貨資訊，很多品牌沒有這份資料，這種情況下應該讓系統誠實說明並提供到貨通知，而不是推測日期。

Q3：需要能查詢訂單狀態的 AI 客服，整合時要注意什麼？ A3：先解決身分再解決查詢。訂單查詢本身資料明確、沒有判斷空間，是最適合自動化的一類，但前提是系統要能確認對話者是哪一位會員。網頁訪客、App 會員、LINE 好友、門市留過電話的客人，如果在系統裡是四筆各自獨立的資料，機器人就只能退回去請消費者輸入訂單編號。另外要確認退換貨與退款狀態是否也接得到，這份資料經常單獨存在客服系統裡，是最常被漏掉的一塊。

Q4：我們有多個品牌需要不同客服風格，資料上該怎麼分？ A4：語氣只是最表層。實際要處理三層：人設與語氣、知識庫分區（避免 A 品牌的政策被引用到 B 品牌的對話）、以及會員資料的品牌歸屬。第三層必須在導入前決定，也就是同一位跨品牌會員的資料能不能互通。個人資料的利用要落在蒐集時告知的特定目的與必要範圍內，跨品牌共用還牽涉集團內各法人的關係與同意取得方式，建議由法務或個資窗口一起確認，留到上線後再補會產生大量例外規則。

Q5：我們用開店平台，AI 客服可以直接串接嗎？ A5：多數廠商會回答可以，但要追問三件事才知道落差。串接方式是對話當下即時打 API，還是定時匯入，這決定資料會不會過期；欄位對照由誰負責轉換，商品編號、會員識別碼兩邊叫法不同是常態；查詢逾時或資料缺漏時的預設回覆能不能自訂。此外，品牌的資料通常散在電商平台、ERP、CRM、POS 四處，要先決定是在中間建一層統一整合，還是逐一客製串接，兩者的長期成本結構差異很大。

Q6：預算有限的品牌，該從哪一段資料開始接？ A6：從訂單狀態查詢開始。這一類問題量大、答案客觀、答錯的代價最容易量化，而且它要求的身分歸戶本來就是會員經營該做的事，投資不會浪費。庫存查詢次之，但要先確認庫存資料能即時查詢，做不到就先不要開放這類自動回覆。多品牌隔離與跨系統整合成本最高，建議放在後面，等前兩類跑穩了再處理。

Q7：導入之後多久看得出效果，最常見的誤解是什麼？ A7：這取決於起點。資料已經接通的品牌，工單自動處理比例通常會比較快出現變化；如果要從身分歸戶開始做，就要把歸戶工程的時間一起算進去。最常見的誤解是把 Gartner「2029 年 agentic AI 自主解決 80% 常見客服問題」當成現在就該達到的水準，那是一個關於 2029 年的預測，不是今天的基準線，也不是承諾。第二個誤解是以為導入 AI 就能減人力，但 Gartner 在 2026 年 1 月的預測指出，到 2030 年生成式 AI 的每次解決成本會高於許多 B2C 海外人力客服，實務上更合理的目標是讓人專注在真正需要判斷的那部分。

延伸閱讀

1. AI Agent 工具怎麼選？企業級平台選型，先看你的資料住在哪
2. AI Skill 怎麼按職能分工：CRM、廣告、客服各該裝哪一個範本
3. 行銷科技 SaaS 怎麼選？先問資料能不能歸戶，再談功能

想確認自家的會員資料是否已經具備讓 AI 客服安全查詢的條件，歡迎與 91APP CDMP 團隊聊聊你的資料現況。