向廠商詢問部署需要多久，您會得到一個區間；詢問企業買方編列了多少時間，常聽到的答案是 12 至 18 個月。兩者都是真心話，只是衡量的東西不同。廠商計算的是設定時間，您計算的則是從簽約到首張自主解決的工單之間的落差。
較大的那個數字值得仔細檢視，因為它並非技術本身的特性。多數企業預設的 12 到 18 個月時程，是採購流程造成的結果，而非產品的必要條件。之所以如此，是因為 3 條工作流程被依序執行，而不是同步進行。
3 大延遲因素，以及它們為何依序進行
首先是廠商遴選：撰寫需求、安排展示、形成候選名單、做出決定。直到這時才開始資安審查，因為沒有人想為 5 家廠商做合規審查，而其中 4 家終究會落選。接著才開始規劃整合，因為為尚未選定的廠商界定整合範圍，感覺像是白費工夫。
紙上看來，這一切都很合理。但合在一起，就形成了毫無重疊、效率低落的時程。同步進行會讓人不太自在，因為這代表要把資安審查的心力花在不會勝出的廠商上，還要界定可能被捨棄的整合範圍。但這也是縮短部署時間最有效的單一槓桿，而且相較於損失一整季由能力帶來的價值，被捨棄的工作成本其實很低。
時程拉長時會發生什麼事
Gartner 預期，到 2027 年底將有超過 40% 的代理式 AI 專案遭到取消，原因包括成本攀升、商業價值不明確，以及風險控管不足。在同一份分析中，Gartner 也指出，將代理整合進舊有系統往往技術複雜，會干擾工作流程並需要昂貴的修改。
這 2 項發現描述的其實是同一種失敗模式。專案很少因為模型在測試中表現不佳而被取消；被取消的原因，是串接工作不斷擴大，而商業論證卻一直在等待遲遲未出現的成果。漫長的時程不只是慢，更是讓取消成為理性選擇的條件。
架構如何拉長每個階段
在遷移模式下，正式開始設定之前，文章要先匯出並重新排版、分類架構要重建、工單歷史要匯入、權限要重新對應、身分驗證要重新串接。還有一項沒人會報價的成本：遷移期間，您的知識庫形同施工中，維護團隊要嘛停止更新，要嘛得在新舊系統同步更新。產品持續推出、政策持續變動，遷移後的副本就會悄悄出錯，直到某位客戶拿到過時的答案才被發現。
在疊加模式下，代理會連接您既有的系統，直接在知識所在之處讀取內容，並透過團隊已在使用的工具執行操作。沒有任何東西需要搬移，因此整合階段縮短，凍結期也隨之消失。同樣的邏輯也適用於語音：語音對語音代理會直接連接您既有的電話系統，不需要先遷移電話系統。
太晚才界定範圍的相依鏈
知識只是看得見的部分。整合規劃真正的工作量落在鏈上的其他環節，因此及早開始比快速完成更重要。
- 身分。 代理需要知道自己在和誰對話，這代表它必須納入您的單一登入與客戶驗證流程，也就代表要排進資安團隊的待辦清單。
- 權限。能解決問題的代理必須獲得執行操作的授權。必須有人決定可執行哪些操作、適用哪些帳戶類型、上限為何，以及哪些情況需要真人處理。這是需要決策者參與的政策工作，而不是一張工程工單。
- 下游系統。 處理退款會牽涉帳務系統，變更地址會牽涉訂單管理。每個連接單獨來看都很單純，但各自都有一位不在原始專案計畫中的負責人。
無論採用哪種架構，這些都不會消失。問題在於您是在第 1 週就著手處理，還是等資料專案結束後才開始。
壓縮後的時程長什麼樣子
K1x 上線後第 1 週內即達到 80% 的自主解決率。不是第 1 週試行、之後才正式上線，而是第 1 週就實現解決。Papaya Pay 在 3 週內達到 90% 的自主解決率。在所有企業部署中，從簽約到正式上線平均只需 4 至 6 週。
這些時程並非因為客戶準備得特別充分，而是當關鍵路徑上沒有遷移工作、3 大延遲因素得以重疊而非排隊時，自然會出現的結果。
找出真實時程的提問
- 代理是直接在原處讀取我們的知識，還是需要一份副本？
- 團隊更新文章後，代理的回答要多久才會跟著改變？
- 在首張工單被自主解決之前，有哪些東西必須先搬移？
- 哪些整合目前已原生支援，哪些要在導入期間建置？
- 客戶最快多久正式上線？是什麼讓他們這麼快？
最後一題務必追問到底。快速部署通常有共同的原因，若廠商說不出來，靠的可能是運氣而非架構。
為什麼時程就是策略
在數週內完成的部署，能讓您在預算討論尚未定案時，就以真實流量衡量解決率。需要數季才完成的部署，則要等到仰賴這些數據的決策已經做出後，才交出第一批真實數據。比起任何模型基準測試，這樣的先後順序往往更能區分哪些計畫獲得續約、哪些被一筆勾銷。
《90 天試行範圍》 提供在全面推行前驗證解決率的參考範圍，內容取自 《State of AI in CX 2026 報告》 的「部署悖論」章節。
用您自己的對話實際體驗。
申請免費的專屬展示。
