先把 POC 縮成一個可判斷的業務任務
POC 應選擇規則相對明確、通話量可估、結果能從後台核對，且發生錯誤後可以補救的任務。例如蒐集維修資料後建立工單，比「處理所有客服問題」更適合驗證。開始前要寫清楚通話入口、必要欄位、可執行動作、禁止動作、人工接手條件，以及企業 API 和測試環境由誰提供。範圍若無法畫出邊界，驗收就只會變成主觀試聽。
AI 語音客服 POC 怎麼驗收？測試情境、指標與上線門檻
AI 語音客服 POC 的目的不是錄出一段順利 Demo，而是用有限範圍回答三件事：真實來電能否完成指定任務、失敗時能否被發現與接手、整體成本是否值得進入正式建置。只驗收聲音自然或回答流暢，無法證明系統能正確建立工單、查詢狀態或保護重要資料。
蔡翊廉｜全端工程師・數位產品開發者 發布 2026-08-30
本文章節
- · 先鎖定任務
- · 建立測試案例
- · 定義指標
- · 設定門檻
- · 失敗情境
- · GoGoCha 證據邊界
- · 正式上線
先保存人工流程基準，再談 AI 改善
沒有基準值就無法判斷 POC 是否改善。至少記錄目前任務由誰處理、成功如何定義、常見錯誤、尖峰等待、需要重新輸入的資料，以及人工如何補救。基準不一定要是漂亮的 KPI；一小批經確認的實際案件，也比供應商自行假設合理。正式比較時要使用相同任務、相近來電條件與一致的成功定義。
黃金測試案例要包含正常、模糊與失敗路徑
先由業務、客服與系統負責人共同寫出輸入、預期追問、必要欄位、允許動作與最終狀態，再交給系統重複測試。案例不能全部使用照稿念的標準句，應包含使用者改口、資料缺漏、同音字、背景噪音、沉默、插話、API 逾時及要求真人。涉及姓名、地址、金額或身分時，還要測試 AI 是否會重述確認，而不是只看逐字稿像不像。
| 情境 | 要觀察什麼 | 可核對的結果 |
|---|---|---|
| 正常完成 | 必要欄位、追問順序與工具呼叫 | CRM／工單／派單狀態與通話紀錄一致 |
| 資料模糊或改口 | 是否重新確認並覆蓋舊值 | 只保留最後確認資料，不重複建單 |
| 語音誤解 | 低信心、重問與轉人工條件 | 錯誤未被直接寫入正式系統 |
| API 逾時或拒絕 | 回覆、重試、待辦與冪等 | 不先宣稱成功，後台可追蹤最終狀態 |
| 要求真人或高風險事項 | 轉接路由與上下文交接 | 人工收到已確認欄位與未解問題 |
指標要對應任務，不要只看辨識率
語音辨識正確不代表任務成功，逐字稿有錯也不一定影響結果。驗收應同時看任務完成、必要欄位正確性、工具呼叫成功、誤解或 fallback、計畫性轉接、異常升級、使用者放棄、回應延遲及人工修正量。每一項都要有明確分母與資料來源，例如以「符合範圍的測試通話」為分母，並由電話紀錄、模型事件、API log 與企業系統最終狀態交叉核對。
| 指標 | 定義方式 | 避免的誤判 |
|---|---|---|
| 任務完成率 | 符合範圍且最終狀態正確的通話占比 | 不能把只完成對話算成完成工單 |
| 必要欄位正確性 | 經確認欄位與真實答案相符程度 | 平均值不可掩蓋地址、金額等關鍵欄位 |
| 工具執行成功 | API 動作成功且沒有重複或錯誤副作用 | 網路逾時不能直接算失敗或成功 |
| 誤解與 fallback | 系統無法理解或進入重問的頻率 | 要區分合理追問與無效循環 |
| 人工接手 | 計畫轉接、異常升級與使用者主動要求 | 轉人工不是一律失敗，要依原因分類 |
上線門檻必須依錯誤成本設定
沒有一條及格線適用於所有 AI 電話。查詢營業時間與修改付款資料的錯誤成本完全不同；同一個任務中，地址錯一個字也可能比語氣不自然嚴重。做法是先把錯誤分為可自動重試、需要人工覆核、不得自動執行三類，再為每類指定門檻與責任人。若樣本不足，只能說 POC 尚未發現特定問題，不能推論正式環境一定達標。
POC 驗收也要測失敗後能不能營運
正式服務一定會遇到電信斷線、模型逾時、企業 API 異常、人工席位滿線及供應商維護。POC 應確認每種異常會回覆什麼、資料停在哪個狀態、誰會收到通知，以及恢復後能否安全重試。前端與營運後台要完整顯示可理解的錯誤，不能把例外吞掉後讓客服以為案件已成立。
GoGoCha 能作為架構證據，不是通用驗收數據
GoGoCha 公開案例可證明隼訊做過 AI 電話入口、共用派單後端、佇列、即時通知，以及網站、LINE、App 與後台整合。案例沒有公開辨識率、平均延遲、接通率、人力節省或正式通話 SLA，因此這些數字不能拿來替另一個企業設定門檻。新的 POC 仍要用該企業的電話環境、客群語言與任務資料重新驗收。
從 POC 進正式版前要留下哪些交付物？
至少留下版本固定的測試案例、結果明細、未解風險、系統架構、資料流、權限、監控、人工接手與回復流程。正式版還要重新測尖峰併發、真實 PBX／SIP、備援、錄音政策與營運權限。POC 通過只表示值得繼續建置，不表示可以原封不動直接承擔正式流量。
參考資料
- Evaluate agents with golden test cases and scenarios｜Google Cloud Documentation
- Voice virtual agent dashboard metrics｜Google Cloud Documentation｜2026-08-26
常見問題
AI 語音客服 POC 要測多少通才夠？
沒有通用數字。樣本要覆蓋主要意圖、常見說法、重要失敗路徑與不同來電條件；高風險或低頻例外不能只靠隨機通話碰運氣，必須刻意建立測試案例。
POC 能只用網頁麥克風測試嗎？
可以用來早期確認對話，但不能替代真實電話驗收。正式 POC 至少要加入實際電話路由、音訊品質、轉接與企業系統，否則會漏掉電信延遲、斷線和 PBX 限制。
轉人工很多就代表 POC 失敗嗎？
不一定。高風險事項的計畫性轉接可能正是正確設計；要分開看計畫轉接、使用者主動要求與系統誤解造成的異常升級。
相關服務
公開案例與可驗證證據
GoGoCha AI 電話與即時派單技術案例