AI 語音客服是能在電話中辨識語音、理解任務、回覆使用者，並呼叫 CRM、工單、預約或派單系統的軟體流程。它不是單一模型，也不是把網站聊天機器人接上麥克風；能否營運，取決於電話串接、欄位確認、業務規則、系統動作與人工接手是否一起設計。
完整架構至少分成電話、語音、對話、工作流及企業系統五層。電話層處理代表號、PBX、SIP 與轉接；語音層負責辨識和合成；對話層判斷意圖與追問；工作流層驗證欄位、權限和狀態；最後才由 API 建立工單、預約、CRM 紀錄或派單。只展示自然對話，無法證明後面四層能穩定執行。
| 層級 | 主要責任 | 不能省略的驗收 |
|---|---|---|
| 電話與路由 | 代表號、PBX／SIP、排隊、轉接與溢出 | 尖峰來電、斷線、轉人工與號碼沿用 |
| 語音與對話 | 語音辨識、合成、意圖判斷與追問 | 口音、噪音、專有名詞與低信心處理 |
| 工作流 | 欄位確認、權限、規則、狀態與重複請求 | 資料不足、使用者改口、冪等與逾時 |
| 企業系統 | CRM、工單、預約、派單或通知 | 建立、查詢、取消、失敗回報與人工待辦 |
優先選擇重複性高、欄位明確、結果可驗證，且發生錯誤後有補救方式的任務：
醫療判斷、法律結論、付款授權、身分爭議、重大客訴及不可逆的高金額動作，不適合作為第一個自動化任務。這些情境即使保留語音整理，也應由真人確認後執行。判斷標準不是 AI 能不能說出答案，而是說錯時能否發現、停止並補救。
重要欄位要讓使用者重述確認，後端再做格式與業務規則驗證。連續誤解、信心不足、敏感關鍵字或使用者要求時，系統應把已確認欄位與對話摘要一起交給人工。若企業 API 逾時，應進入重試、佇列或待辦狀態，不能先向使用者回報任務已完成。
電話流程可能接觸姓名、電話、地址、訂單與通話內容。導入前要由企業確認告知方式、蒐集目的、可存取角色、保存期限與刪除流程；開發端則把權限、遮罩、稽核與環境隔離落實。不是所有對話都需要永久保存，也不該把真實客戶錄音直接拿來當未隔離的測試資料。涉及特定產業法規時，仍應由企業法務或合規角色確認。
隼訊公開的 GoGoCha 案例把 AI 電話入口、網站與 LINE 的叫車需求接到同一套即時派單後端，再同步至司機／乘客 App 與營運介面。公開資料能證明系統範圍與技術架構，但沒有公開營收、人力節省、接通率或真實通話 SLA，因此我們不把這些數字寫成成果。
不要只驗收「能對話」，至少要用代表性真實情境檢查：
公開案例與可驗證證據
GoGoCha AI 電話與即時派單技術案例