先分清楚：這是通路選擇，不是技術高下
兩者底層都是「理解使用者、查資料、執行動作」的流程，差別在入口。語音客服活在電話裡：即時、免打字、對長輩與行動中的使用者友善，但每一秒都在計費、聽錯就要重來。文字機器人活在網站與 LINE 裡：可以慢慢回、可以貼連結圖文、對話紀錄天然留存，但接觸不到只打電話的客群。所以第一個問題永遠是：你的客戶現在都從哪裡來？
AI 語音客服與文字客服機器人的差別
語音與文字客服的差別不是技術高下，是通路差異：你的客戶習慣打電話，還是習慣用 LINE 與網站？選錯通路，再強的 AI 也接不到人。本頁把兩者的成本結構、失敗模式與量測方式攤開比較。
| 面向 | AI 語音客服（電話） | 文字客服機器人（網站／LINE） |
|---|---|---|
| 互動通路 | 電話進線與外撥 | 網站對話框、LINE 官方帳號 |
| 典型使用者 | 習慣打電話的客群、開車或不便打字的情境 | 習慣傳訊息的客群、可非同步往返 |
| 成本結構 | 建置＋電信線路＋語音辨識合成＋模型用量 | 建置＋模型用量（少了電信與語音層） |
| 整合需求 | PBX／SIP、代表號、錄音政策、併發容量 | 網站或 LINE 入口、知識庫、後端 API |
| 主要失敗模式 | 辨識錯誤、噪音口音、通話中斷 | 意圖誤判、模型幻覺、答非所問 |
| 量測指標 | 接通與完成率、欄位取得率、轉人工率 | 解決率、對話輪次、轉人工率 |
| 隼訊起價 | 需求與環境盤點後報價 | NT$ 30,000 專案起（AI 客服 MVP） |
成本結構差在哪？
文字機器人的成本結構比較單純：一次性建置加上模型 API 用量。語音客服在這之上多了三層：電信層（號碼月租、通話分鐘）、語音層（辨識與合成按音訊計費）、以及併發容量（尖峰同時來電數決定線路與運算配置）。這也是為什麼我們的文字客服 MVP 有公開起價（NT$ 30,000），語音專案卻堅持先盤點環境再報價——沒看過 PBX、併發與錄音需求就報的價格，多半不含你真正需要的範圍。
失敗模式不同，安全網設計也不同
文字機器人的主要風險是理解層面：意圖誤判、模型幻覺、答非所問——補救靠知識庫品質、回答限制與轉真人機制。語音客服除了這些，還多了聲音層面的風險：辨識錯誤、背景噪音、口音、通話中斷。所以語音流程必須設計重述確認（重要欄位讓使用者確認一次）、低信心轉人工、斷線後的狀態保存。評估廠商時，直接問「聽錯的時候會發生什麼事」，答不清楚的展示都只是理想情境。
怎麼選：從客群行為回推，不從技術出發
判斷方式很務實：翻你現在的客服紀錄。進線電話占大宗、客群偏好口語溝通（例如在地服務、年長客群）——語音優先；詢問集中在 LINE 與網站表單、問題適合圖文回覆（例如電商、預約服務）——文字優先；兩邊都有量，先做量大的那一邊，驗證流程後再擴充另一邊。預算有限時，文字機器人是比較低門檻的起點，因為少了電信與語音層的複雜度。
兩者並用：共用後端，通路只是入口
成熟的架構是把語音與文字當成同一套系統的兩個入口：知識庫共用（維護一份）、後端動作共用（查訂單、建工單、轉人工走同一套 API）、對話策略依通路調整（語音要簡短口語、文字可以貼連結）。我們公開的 GoGoCha 案例就是這個思路——電話、網站、LINE 三個入口接到同一套派單後端。先做哪個入口都可以，重點是後端設計時就預留多通路，避免之後重做。
常見問題
可以先做文字客服，之後再加語音嗎？
可以，這也是常見路徑。知識庫與後端 API 可以直接沿用，語音階段新增的是電話串接與語音處理層。前提是文字階段的後端有預留擴充空間——這點在第一次規劃時就要提出來。
語音跟文字，哪個建置比較便宜？
文字。語音多了電信、語音辨識合成與併發容量三層成本，持續費用也較高（通話分鐘與音訊處理都計量）。這是通路價值的代價：有些客群就是只打電話。
LINE 上可以做語音客服嗎？
常見做法是 LINE 走文字機器人（可含語音訊息的辨識），即時語音對話則屬於電話通路。兩者可以接同一套後端，讓客戶自己選擇習慣的入口。
兩種都想做，預算怎麼分配？
先做客群量大的通路並完成驗證，再擴充第二通路。共用後端的架構下，第二通路的增量成本低於重新開案——所以順序影響的是風險，不是總成本。