很多企業的電話系統、CRM 與 AI 工具各自存在，但中間缺少可驗證、可交接的流程。 這篇不對應任何單一客戶，只整理「來電辨識 + 通話內容整理」類型專案的通用規劃重點。
先講結論
想幫企業電話系統接 AI（來電自動彈出客戶資料、通話結束自動寫摘要回 CRM），最花時間的不是 AI 模型，是電話系統那條縫。
如果你正在評估這類專案，下面三個教訓可以幫你少踩一年坑。
教訓一：外撥的架構限制，要先 spike 再報價
企業電話系統通常分來電與外撥兩條路，技術限制完全不一樣。
來電：客戶打進來 → 系統有完整的來電事件 → 觸發 Webhook → 彈出客戶資料。這條路順。
外撥：業務主動打出去 → 事件內容、識別欄位與權限可能和來電完全不同，不能直接假設可以沿用同一套流程。
這是平台層的硬限制，不是程式寫不好的問題；若要繞過，必須先確認平台是否提供可用的事件、識別欄位與授權能力。
教訓：報價前先花一兩天做 spike（技術驗證），把「來電」和「外撥」分開估。很多專案卡住，都是卡在沒人先驗證這條縫。
教訓二：雲端成本不是「買機器」，是「選架構」
同樣的功能，兩種部署方式，月費可以差到四倍：
- 常駐型運算：費用與維護責任較固定
- 按請求計費的容器服務：適合有尖峰與離峰差異的工作負載
電話系統的流量可能有明顯尖離峰；評估部署時，應把使用量、維護責任、資料權限與成本模型一起比較，而不是只看單次開發費用。
教訓：幫客戶做技術選型時，TCO（總持有成本）要當成交付物的一部分，不是附註。客戶不一定懂架構，但一定看得懂月費。
教訓三：第三方 App 的隱藏成本，比你想的多
評估直接採用第三方 CTI App 或現成連接器時，常見問題包括：
- 定價、資料處理與權限範圍需要先確認
- 上線後的維護與供應商依賴需要先評估
- 客製能力可能受限，未必能符合企業既有流程
是否自建不能一概而論，應依資料敏感度、維護能力、客製需求與長期擁有權評估。
教訓：評估工具時，把「改不動的成本」算進去。很多採購決策的隱形成本，是採購之後才開始。
這三個教訓的共同點
都是中間層的問題：
- 電話系統的 API 邊界
- 部署架構的計費模型
- 工具供應商的鎖定與資料權限
AI 模型本身只是其中一層；語音轉文字、結構化摘要與品質檢查，都必須放回企業的權限、驗收與人工覆核流程中。
這正是「Forward Deployed Engineer（FDE）」存在的意義：把企業既有的系統縫起來的人。不需要客戶懂技術，只需要客戶驗收結果。
如果你也遇到類似的狀況
- 你的電話／客服系統想接 AI，但不確定從哪開始 → 預約企業 AI 健診，2 小時盤點出第一條值得做的流程
- 你已經有工具但沒人串 → 先做 spike，再談專案
- 你想知道這套做法適不適合你的產業 → 直接加 LINE 聊，不推銷，先釐清方向