%20.png)
AI 客服導入流程，要先分清哪些問題有正式答案、哪些需要即時資料、哪些必須由真人接手，再用試營運紀錄決定是否上線。
先把「可上線」說清楚，再開始測。
AI 客服導入前，先盤點客服資料與責任邊界，再用有限的試營運驗證回覆品質，最後依驗收紀錄決定能否正式上線。
在 Data-DI 的導入工作裡，我們不會把「AI 能不能回答」當成第一個問題。會先把問題分成三類：有正式資料可核對的、必須查即時資料的，以及即使有資料也應交給真人處理的。這三類若一開始混在同一份 FAQ 裡，後面的測試就會失去判斷基準。
如果你現在已經有平台、Demo 或一份待整理的 FAQ，最常遇到的情況是大家對「可以上線」各有一套說法。業務看見它能回覆，客服主管在意答錯後怎麼補救，IT 則要確認資料從哪裡來、哪些權限真的開了。三方都看過測試，專案仍可能在正式接客後才發現首波範圍太大。
因此，這篇用案例來說明我們在試行測試（POC）前會先釐清的四個問題：首波到底測什麼、哪些資料才是可用版本、驗收紀錄要留下什麼，以及上線後看到哪類回覆時要退回修改。在沒有真實導入數據時，也不把未確認的結果寫成承諾。
不要先整理一大包 FAQ，先決定這一輪要讓 AI 接哪幾種問題。
資料盤點的目的，是把每類問題的回答依據、資料需求與真人責任寫清楚，再決定這一輪要測什麼。
假設小吳是某跨境電商的客服主管。她來找我們時，手上可能有一份 FAQ、幾張商品頁截圖，還有客服同事丟在群組裡的回答紀錄。她問的第一句通常會是：「這些資料給你們，多久可以上線？」
在範圍、資料和串接條件還沒確認前，我們不會先承諾一個日期，而是先問：「這一輪，你希望 AI 先接哪幾種問題？哪些問題即使資料齊全，也要留給真人？」因為「退貨期限」、「我的訂單到哪裡」和「客戶要求例外退款」看起來都是客服問題，實際上需要的資料和負責的人完全不同。
第一步，我們會請小吳先把收到的問題分成三類，不要急著把所有內容再塞進一份更長的 FAQ：
接著，我們會和小吳一起把四個欄位寫在同一張表上：問題原句、回答依據、AI 要做的事、真人要接的事。之後每一題測試都拿這四欄回頭對照，才分得出來是資料缺了、查詢沒接好，還是這題本來就不該讓 AI 自己處理。
小吳如果只寫「導入 AI 客服」，測試做到最後很容易變成大家各自挑幾題問，然後用「好像還可以」做結論。我們會請她把暫時排除的內容也寫在同一張表上，例如：尚未確認版本的活動價格、還沒有資料權限的訂單查詢、需要人工核准的退款例外。
這些內容先不要混進第一輪。等小吳能分辨「這題是資料尚未更新」和「這題本來就要真人判斷」，她才知道下一步該補資料、修流程，還是縮小 AI 的責任範圍。這張範圍表，也會成為後面試營運與上線驗收共用的判斷基準。
先確認資料是不是目前有效的版本，再決定哪些內容可以拿來測試。
資料能不能用，先看內容是不是目前有效的版本、能不能拿來回答，以及之後由誰更新；檔案多不代表資料已準備好。
小吳可能會說：「我把官網、Excel，還有客服群組裡的回答都整理好了。」這時候我們不會只看檔案數量，也不會因為資料很多，就直接說可以開始測。我們會陪她逐份確認：這份內容現在還算不算數？如果兩份資料寫法不一樣，哪一份才是正式答案？之後規則有變動，誰會通知我們更新？
例如退貨規則，官網可能已經更新，客服同事手上的舊版 PDF 卻還留著。小吳如果兩份都交給我們，問題就不只是「AI 會不會讀」，而是它可能找到兩個看起來都合理的答案。
所以我們會請小吳先指定正式版本，並把需要定期確認的內容標出來。像活動價格、配送方式、退貨條件這些資訊，不能只在導入當下確認一次；如果沒有人負責後續更新，今天測試通過，過一陣子仍可能回答到過期內容。
「我的訂單到哪裡」和「這件商品還有沒有庫存」這類問題，不能只放一份說明文件就算準備好了。我們會再和小吳確認，這些資料目前放在哪裡、系統要靠什麼找到顧客的資料，以及查不到時要怎麼回覆。
如果要連到既有系統，也要先確認資料權限和串接方式是否可行；手上有訂單資料，不等於導入後就能查訂單。確認完這些條件，才知道這題適合放進第一輪測試，還是先列為之後再處理。若目前沒有 IT 人員，也可以先從不需查即時資料的固定問題開始。
資料盤點完成的標準，是每一類問題都有可以核對的回答依據，也有人知道內容變動時要怎麼更新。這樣後面測到答錯，才有辦法分辨是資料本身有問題，還是流程或設定需要調整。
不要只讓大家隨便問幾題，要把問題、判斷方式和後續處理一起記下來。
試營運要用事先選好的問題，記下每次回覆是否符合預期，以及哪裡需要真人接手。
小吳可能會問：「客服同事都試過了，大家覺得回答還可以，這樣可以上線嗎？」我們通常會請她先不要只看大家的印象，而是把每一題問過什麼、AI 回了什麼、原本應該怎麼回，以及最後有沒有交給真人，留在同一份紀錄裡。
我們會請小吳從客服平常收到的問題開始，不要只挑最容易回答的題目。除了退貨規則、配送方式這些固定問法，也要放進顧客講得比較含糊、同一件事換個方式問，或是資料不完整的情況。
例如顧客問「那我要多久以前申請才可以退？」這不一定會和 FAQ 裡的「退貨期限」長得一樣。這類問法放進試營運，才看得出來 AI 是真的理解問題，還是只認得幾個固定關鍵字。
有些回答從字面上看沒有錯，但不一定適合直接給客人。例如活動還沒正式公布，或是商品推薦需要先確認庫存。這時候我們會請業務或營運主管一起看：這句話現在能不能對外說？如果不能，應該改成提醒、請顧客留下資料，還是交給真人處理？
業務或營運主管在這裡要確認，AI 回覆有沒有超出公司目前能承諾的範圍。若遇到需要例外判斷的問題，也要在紀錄裡留下最後由誰接手、怎麼處理。
查詢訂單、庫存或會員資料時，測試不能只記「有查到」或「沒查到」。我們會一起確認，資料查不到時，AI 是依照事先寫好的說法回覆，還是要把對話交給真人；如果查詢本身沒有成功，也要留下原因，方便後面判斷是權限、資料欄位，還是串接方式需要調整。
試營運紀錄除了「這題答對了」或「這題答錯了」，還要留下問題屬於哪一類、回答依據在哪裡、是否需要真人接手，以及下一步由誰補資料或修改設定。下一輪要不要擴大範圍，就以這些紀錄來判斷。
每一題都要有結果，並寫清楚誰判斷、哪裡要修改。
上線驗收是把試營運紀錄逐題對照原本的範圍，確認哪些問題可以讓 AI 處理、哪些要調整，或是從一開始就應該交給真人。
小吳拿著測試紀錄來問：「大家都說回答還可以，這樣算通過了嗎？」我們不會用一句「看起來沒問題」結案，也不會直接套用一個固定的答對比例。會先把每一題分清楚：這次回覆是否符合原本的答案？如果不符合，是資料有問題、查詢沒有成功，還是這題本來就不該由 AI 自己處理？
小吳要看的不只是 AI 有沒有回話，而是回覆有沒有完成原本交給它的工作。像「退貨期限」這種固定問題，要確認回答是否跟正式規則一致；遇到退款爭議，則要確認它有沒有在適當的地方停下來，把對話交給真人。
如果一題需要修改，我們會在紀錄裡寫清楚是要補資料、調整說法，還是把它移出這一輪。這樣小吳下次再看，不用重新猜當時為什麼判定不通過。
有些回答不是完全錯，而是講得比公司現在能做到的更多。例如商品還沒有確認庫存，AI 卻直接說「可以幫你保留」；活動規則還沒公布，回覆卻先講了折扣。這些情況要由業務或營運主管確認，哪些話可以直接對外說，哪些話要改成請顧客等待或轉真人處理。
如果訂單查詢沒有回資料，或資料權限暫時沒有開通，測試紀錄要留下實際發生什麼事，以及顧客最後看到什麼回覆。IT／資料負責人要確認，這種情況有沒有按照事先約定的說法處理，而不是讓對話停在沒有答案的地方。
我們會在驗收表上保留四種結果，讓小吳、業務或營運主管、IT／資料負責人都知道現在卡在哪裡，下一步要改什麼：
上線後先保護顧客體驗，再回頭處理資料、流程或設定。
正式上線後，要把顧客實際提問和異常回覆記下來；遇到超出原本範圍的問題，先交給真人處理，再判斷要不要補資料或調整設定。
小吳可能在上線幾天後收到客服同事的訊息：「AI 又把活動折扣講錯了。」這時候我們不會先問她要不要把整個 AI 關掉，而是先確認是哪一類問題：活動內容是不是更新了、資料版本是不是還沒換上去，還是這種例外本來就不該由 AI 自己回答。
小吳要看的不是轉真人越少越好，而是哪些問題在上線後一直需要同事接手。像退款爭議、特殊折扣或顧客情緒比較高的對話，本來就可能需要真人處理；如果連固定的退貨規則也常常被轉接，就要回頭檢查回答依據或問題範圍。
當某一類問題暫時不穩定，我們會先把它留在真人處理的路徑，不讓 AI 繼續用不確定的方式回答。等資料或流程修正後，再拿同一批問題重新測，確認真的改善了才放回來。
活動價格、配送方式、退貨條件或商品庫存，只要有變動，就要有人通知客服主管和資料負責人。不能等到顧客截圖回報，才發現 AI 還在使用舊內容。
我們會請業務或營運主管在規則確認後，把變更內容和開始適用的時間說清楚；如果新規則還沒準備好，就先讓相關問題轉真人，避免 AI 提前替公司做承諾。
如果訂單、庫存或會員資料查不到，IT／資料負責人要先確認是資料沒有更新、權限改變，還是查詢流程出了問題。這些原因不能只寫成「系統錯誤」，否則下一次遇到同樣狀況，大家還是只能重新猜。
我們會把上線後發現的問題分成三種處理：資料更新後重測、流程或設定修改後重測，以及先維持真人接手。這樣每次收回一類問題，都有清楚的理由，也不會因為一次答錯就把已經穩定的範圍全部撤掉。
不要先問一個固定天數，先確認問題範圍、資料狀態和是否需要串接其他系統。
AI 客服導入所需時間，取決於首波要處理哪些問題、資料能不能直接使用，以及是否需要另外確認查詢或串接工作。
小吳一開始問「資料都給了，什麼時候可以上線？」很合理，但我們不會只看她交來的檔案數量。假如第一輪只處理退貨規則和營業時間，準備方式和需要查詢訂單、庫存的專案就不一樣；如果資料版本還沒有確認，檔案再多也不能直接拿來測。
小吳要先把第一輪範圍說清楚，包含哪些問題要讓 AI 回答、哪些問題先交真人，以及哪些內容目前還沒有正式版本。範圍越清楚，我們越能直接安排測試；如果什麼都想一起處理，反而會在每一題之間來回確認，時間也會跟著拉長。
如果只是根據已確認的客服資料回答，工作重點會放在資料整理、設定和測試；如果還要查訂單、庫存或會員資料，就要另外確認資料權限、欄位和串接方式。這些條件還沒確認前，不能只用「資料已經準備好了」推算上線時間。
就算測試中的回答看起來沒有問題，也要等活動規則、商品資訊或服務承諾確認好，才適合正式對外。業務或營運主管要在這裡確認，公司現在願意讓 AI 說哪些話，哪些內容仍然要由同事接手。
討論時間時，我們會先把工作分成「範圍確認、資料準備、設定與測試、驗收」幾個階段，再依實際卡點安排；符合標準導入條件時，Alta.DI 可依約在 5 週內完成導入與上線。這份清單也能讓小吳判斷，眼前是資料還沒確認、系統條件還沒到位，還是測試結果需要再修一次。
不用先準備一份完美文件，但要先把範圍、資料、查詢和真人接手方式說清楚。
AI 客服導入前的檢查清單，是幫你把第一次討論需要的資訊放在一起，不是要求公司先把所有資料整理到完全沒有問題。
如果你是公司的老闆，或像小吳一樣負責客服，但平常沒有專人整理這些內容，可以先用下面的問題自我檢查。答案不完整沒有關係，重點是知道哪裡還需要和供應商一起確認。
小吳把這五題先寫出來後，我們就能從她的答案看出下一步：是先整理資料、先確認系統權限，還是先縮小第一輪範圍。她不用一開始就把所有事情都處理完，也不用拿著一份看起來很完整、但沒有人知道哪個版本才算數的資料來開會。
本段重點：每一階段都要留下可以核對的紀錄，不能只看 AI 有沒有回話。
小吳不是特定客戶，而是依 Data-DI 現有的 PoC、資料確認與驗收作業整理出的匿名情境。不同公司的客服管道、資料狀態和時程會不同，但範圍、資料、試營運與驗收四個階段，都要留下可回頭檢查的內容。
這張表的重點不在於把流程拉長，而是讓小吳、營運和資料負責人都能指出目前卡在哪一格：資料還沒確認、查詢條件未齊，或是測試結果要再修。這也是我們判斷首波能否上線的依據，不會只用「看起來可以」當結論。
先完成可驗證的導入循環，不用一開始就處理所有客服問題。
AI 客服導入流程的第一步，是選一個資料能核對、結果看得見的客服場景開始測。
小吳最後帶回去的，不應該只是一句「AI 好像可以」，而是一張能和同事一起看的紀錄：這一輪處理哪些問題、哪些資料已經確認、哪些情況要交真人，以及測完後下一步要改什麼。
如果你現在是老闆、客服主管或負責營運的人，可以先做三件事：
如果你還在比較不同 AI 客服平台，可以先看〈AI 客服怎麼選？從需求盤點到平台評估的完整指南〉；如果已經有想測的場景，就可以直接從本文的範圍表和驗收表開始準備。Alta.DI 的重點是讓客服對話與資料不被單一通路綁住；想討論第一輪怎麼安排，可從 Alta.DI AI 客服 開始。
