2026 年，「自建」看起來從沒這麼便宜過

如果你是台灣中大型企業的 CTO 或 IT 主管，過去一年大概被高層問過同一句話：「AI 這麼成熟了，客服這塊我們自己接個 LLM API 做，不就好了？」

這個問題在 2026 年比任何時候都更難回答——因為表面上，自建的門檻確實崩塌了。大型語言模型 API 的價格在 2025 到 2026 年間大幅下滑，主流廠商多次降價；語音辨識（ASR）與語音合成（TTS）都有即開即用的雲端服務；開源框架讓你幾天內就能串出一個會講話的 Demo。工具便宜到一個地步，讓「自己做」看起來像是精打細算的選擇。

但這正是危險所在。當自建的「起手式」變便宜，真正的成本就從「要不要做得出來」轉移到「做出來之後，能不能一直活著」。而後者，才是這篇文章要拆給你看的東西。

先講我的立場：這不是一篇勸你不要自建的文章，也不是一篇推銷的文章。我要做的，是把兩條路的真實帳本都攤開，讓你自己推導出結論。即使你讀完決定自建、或決定買別家，這篇文章對你都該是有用的。

一、先拆解：所謂「自建一套 AI 客服」，到底要建哪些東西？

高層想像中的「接個 API」，通常只看到冰山一角。一套能真正上線營運的 Customer Operations 系統，至少包含六層，而 LLM API 只是其中一層裡的一個元件。

這張表想說的其實只有一句話：Demo 是 20%，Production 是 80%。

這不是修辭。多份 2024–2026 年的研究都指向同一件事：讓 AI 在展示間裡跑起來很快，讓它在真實營運裡活下來很慢、很貴、而且大多數人失敗。這一點，我們用數據講。

「Demo 很快、Production 很久」的量化佐證

• MIT Media Lab Project NANDA《The GenAI Divide: State of AI in Business 2025》（2025 年 7 月）：研究基於 52 場高階主管訪談、153 位領導者問卷，以及 300 個公開 AI 部署案例的分析。報告指出，在全球投入約 300–400 億美元之下，95% 的企業生成式 AI 試點沒有帶來可衡量的損益（P&L）影響。更關鍵的是報告的結論方向：成功的路徑是「from building to buying」，由外部廠商建置的工具，成功率明顯高於內部自建。

• S&P Global Market Intelligence《Generative AI shows rapid growth but yields mixed results》（2025 年 10 月，基於 451 Research 對逾 1,006 位受訪者的調查）：放棄多數 AI 專案的公司比例從 17% 增加到 42%，平均每家組織有 46% 的 POC 在進入 production 前被砍掉。該調查另指出，只有 48% 的 AI 專案最終上線，且從原型到上線平均耗時 8 個月。

• Gartner 預測：至 2025 年底，至少 30% 的生成式 AI 專案會在 POC 後被放棄，主因是資料品質差、風險控管不足、成本失控與商業價值不明。

• RAND Corporation《The Root Causes of Failure for Artificial Intelligence Projects》（RR-A2680-1，2024，基於 65 位資料科學家與工程師訪談）：部分估計顯示，超過 80% 的 AI 專案以失敗收場，是不涉及 AI 的一般 IT 專案失敗率的兩倍。

換句話說，你高層看到的那個「幾天做出來的 Demo」，統計上有八成的機率，永遠走不到穩定營運那一天。

二、Build 的真實 TCO：五條會持續長大的成本線

自建的預算表上，通常只寫了「工程師薪水 ＋ API 費用」兩行。但真正決定三年後你會不會後悔的，是下面這五條線——而其中有三條，是上線那天才開始計費的。

把這五條加起來，即使你只做文字、完全不碰電話，一個自建團隊的年投入通常仍落在千萬元級距——而且它是持續支出，不是一次性投資。三年累積下來的量級，往往比第一版預算表上的數字高出一截。

這裡刻意不列逐項報價，原因很實際：真實數字高度取決於你的話務量、既有系統、團隊組成與合規要求，任何一份「標準答案」拿到你的情境都會失真。這張表更該被當成檢查清單——重點不是別人的數字，而是你的預算表上，這五條線是不是都在。

其中三塊值得單獨拆開講，因為它們是壓垮自建團隊最常見的原因——而且前兩塊，跟你做不做電話完全無關。

1. 從「會回答」到「能辦事」的落差。 這是文字場景最容易被低估的一段。Demo 階段的 AI 通常在做問答：你問退貨政策，它答退貨政策，看起來很準。但真實客服對話裡，客戶要的多半不是答案，而是動作——這張訂單到哪了、幫我改配送地址、發票重開、我要退款。要做到這些，AI 必須安全地讀寫你的訂單、會員與金流系統，還得處理身分驗證、權限邊界、操作失敗的回滾，以及「做錯了誰負責」的稽核軌跡。這一段的工作量通常比串 LLM 本身大上一個量級，而且不會因為模型變強就自動變簡單。

2. 多輪與交接的複雜度。 Demo 是單輪問答，真實對話是客戶講到一半改主意、一次問三件事、前面提過的資訊後面要記得。而當 AI 處理不了、要轉真人時，脈絡不能重來——沒有客戶願意把問題再講第二遍。這個「無縫交接」看起來只是介面問題，實作上牽涉對話狀態、權限、工單與即時監看，是自建專案最常做到一半就卡住的地方。

3. 維運的無底洞。 on-call 輪班、模型版本更新後的迴歸測試、prompt 改一句就要重跑一輪驗證、資安與個資稽核。這些是「上線那天才開始」的長期支出，而非一次性投資。

如果你還要做電話語音，難度再往上一層：ASR、LLM、TTS 三段延遲會累加，而人類自然對話的容忍上限大約在 800 毫秒，實務上多數語音 Agent 落在 800 毫秒到 2 秒之間（Telnyx 延遲拆解，2025–2026）。慢一點，客戶就開始插話或掛斷。這也是為什麼不少團隊先做文字，把語音無限期往後延。

延伸閱讀

隱形成本：Customer Operations 的 TCO

三、Buy 的真實 TCO 與風險：採購也不是萬靈丹

如果只講自建的壞話，那這篇文章就不誠實了。採購訂閱同樣有它的痛點，你必須睜大眼睛看。

計價模式與隱形費用

國際大型客服平台的計價，近兩年正在從「per seat（按席計費）」快速轉向「per resolution（按解決數計費）」與「per minute／per conversation」的用量制。市場上常見的作法，是按「成功解決一次問題」計費，而 AI 功能往往還是額外加購的項目。

這帶來三個要提防的地方：

• 用量爆量風險：按次計費在流量尖峰（如促銷、當機事件）可能瞬間暴增，一週的帳單就失控。

• 「AI 稅」：分析機構觀察到，不少廠商在續約時把 AI 功能綁進更高階的方案，造成兩到三成以上的實質漲價。

• 隱藏成本普遍：多份 SaaS 採購調查指出，多數買家是在購買「之後」才發現隱藏費用（導入費、整合費、進階支援費），使實際軟體成本被明顯低估。

客製的邊界，以及路線圖不由你決定

比計價更常見的落差在這裡：平台是為「多數客戶的共通需求」設計的，而你的流程總有幾處是自己長出來的。買現成的東西，代表你得接受某些地方要照它的邏輯走——不是每個特殊流程都能被完整還原，有些反而要回頭調整既有作業方式。

同時，功能什麼時候長出來、往哪個方向長，決定權在對方手上。你認為的高優先需求，未必排在它的路線圖前面。這是採購真實的機會成本：你用速度與穩定性，換掉了一部分的主導權。

判斷方法其實不複雜——把你真正非有不可的那三、五件事列出來，直接問對方「這幾件現在做得到嗎？做不到的話，是怎麼處理？」能講清楚邊界的，通常比什麼都說可以的可靠。

四、最容易被低估的一塊：知識的持續維護

如果這篇文章你只記得一件事，請記這個：自建 AI 客服最常見的結局，是「上線當天最準，之後越用越落後」。

原因很單純：知識會腐壞。產品改版、資費調整、政策更新，而你的知識底層還停在三個月前。研究顯示，過時的知識會讓檢索準確率明顯下滑，而且它是「靜默失效」——系統不會報錯、延遲也正常，只是很有自信地給出錯誤答案。有企業 AI 導入研究指出，相當高比例的組織在部署後三個月內就出現準確率下滑，主因就是知識過時；而客服類資訊的「半衰期」尤其短。

更根本的問題是：麥肯錫的研究發現，將近 70% 的客服人員表示，他們日常工作中至少有 25% 的內容「沒有記錄在任何地方」——這些是靠師徒口耳相傳的隱性知識。你就算把現有文件全部餵進去，也只搬進了一部分真相。

這就是為什麼沒有回饋機制，Build 和 Buy 兩條路都會失效。真正能持續變準的系統，靠的不是「一次把知識底層建好」，而是一個閉環：真人客服每天解決的問題、AI 答錯被糾正的案例，要能自動回寫、沉澱回知識底層，讓下一次回答更好。沒有這個飛輪，再貴的系統都會退化成一本過期的說明書。

延伸閱讀

為什麼 AI 客服會失敗

五、決策框架：六個問題，自我檢測該 Build 還是 Buy

企業採購理論其實早有共識，核心就一句話：buy the commodity, build the differentiation（通用能力用買的，差異化能力才自己建）。

但這句話最常被誤讀成「客服對我們很重要，所以要自己做」。那是把「功能」當成了「差異化」。真正該問的不是客服重不重要，而是你的差異化落在哪一層。

渠道、工作台、對話狀態管理、稽核軌跡——這些是每一家做客服的公司都要有的東西，做得再好也不會有客戶因此選你。真正讓你不一樣的，是你的知識、你的政策、你怎麼處理例外、你願意為客戶多做哪一步。而這一層，恰好是買了平台之後才有餘力去做的——你把工程資源從排程上抽回來，才有人力投在它上面。

所以，客服越是你的主戰場，這個判斷越不該倒過來：越重要的事，越不該把資源耗在重建基礎設施上。

把它落成六個可以自答的問題：

如果你多數答案落在右欄，誠實說，自建的期望值對你並不划算——你會用最貴的方式，買到八成機率失敗的結果。但這不代表你只能全盤外包，還有第三條路（見第七節）。

延伸閱讀

AI 客服適配度與 ROI 指南

六、台灣在地變因：三個讓天平更明顯的因素

1. 缺工與人力成本，只會往一個方向走

台灣的結構性缺工已經不是新聞。行政院主計總處職缺調查顯示，2024 年 11 月底工業及服務業職缺約 24.7 萬個，較上年同期增加 2.1 萬個；而住宿餐飲、支援服務等前線服務業，正是「高流動、招募難」的重災區。少子化讓新血只會越來越少。

同時，用人成本持續上升：2026 年基本工資自 1 月 1 日起由月薪 28,590 元調升至 29,500 元、時薪由 190 元調升至 196 元。這是自 2016 年以來連續第 10 年調漲，月薪 10 年總調幅達 47.4%。這對高度依賴真人處理的 Customer Operations 是雙重擠壓——人越來越難找，也越來越貴。AI 化不是要不要做，而是遲早要做；真正的問題只剩「自建還是採購」。

2. 個資法與在地維運支援

2025 年 11 月 11 日，《個人資料保護法》部分條文修正，將由新設立的「個人資料保護委員會」作為主管機關，新增個資事故通報義務、國際傳輸限制，以及稽核檢查權限（施行日期尚待行政院訂定）。對客服這種每天大量接觸個資的場景，這代表：資料存放在哪、跨境傳輸怎麼管、事故如何通報，都是要有人負責的法遵工作。

這也帶出一個現實考量：當系統出事，你要找的是懂當地法規、同時區、能用中文即時支援的對象。純國際平台的支援時區與在地法遵理解，常常是導入後才痛的點。

3. 語言與口音：現成模型不是為台灣調的

如果你的場景包含電話語音，還多一道資料層面的門檻。公開可用的大規模中文語音語料——例如 AISHELL、WenetSpeech——絕大多數錄製自中國，而商用等級的辨識模型動輒需要上萬小時語料訓練。換句話說，市面上多數現成模型，本質上是為另一個口音族群調校的；針對台灣中文的學術 benchmark 也顯示，同一批模型在台灣口音資料上的表現不如中國口音測試集（Twister, NTU／聯發科研究, 2025）。

具體差異落在捲舌音的弱化程度、ㄣ／ㄥ 的分野，以及「悠遊卡」「超商取貨」「發票載具」這類在地用詞——模型沒見過就是聽不出來，而它們恰好是客服對話裡的高頻詞。這不是寫程式能解決的問題，是資料問題；補這一段需要的，是你手上多半沒有的在地話務語料。

七、第三條路：Buy 平台 ＋ Build 差異化層

看到這裡你可能覺得，Build 和 Buy 好像都有致命傷。其實 2026 年多數成功的企業，走的是混合模式：買下成熟的平台底座，只在真正差異化的那一層自己建。

技術上，這條路比過去可行得多，關鍵是開放架構：

• API 與 MCP（Model Context Protocol）整合。 MCP 是 2024 年底提出、2025 年被主要 AI 廠商廣泛採用的開放標準，讓 AI Agent 能用統一協定安全地讀寫 CRM、ERP、資料庫，而不必為每個系統各寫一組客製接口。這正好解掉自建裡「資料整合層變成長期維運債」的痛點。

• 與 CRM／ERP／電商後台雙向串接。 差異化不在於「誰的 LLM 比較強」，而在於 AI 能不能即時、安全地接到你獨有的業務資料與流程。

換句話說：通用能力（語音、文字、工作台、基礎模型）用買的，把工程資源省下來，只投在「讓你之所以是你」的那層邏輯上。這才是把八成失敗率翻轉過來的作法——MIT NANDA 的結論同樣印證，能跨越 GenAI Divide 的組織，關鍵是「from building to buying」，採用外部平台再疊加自身差異化，而非什麼都從零自建。

八、網訊電通 Telli 的觀點與定位

講到這裡，該坦白我的身分。我們是網訊電通（Telexpress）。之所以敢用一整篇文章跟你講「Build vs Buy 該怎麼想」，是因為這題我們比多數人更有資格談——網訊電通深耕台灣客服代營運超過 25 年，是台灣唯一由客服代營運起家的 Customer Operations AI 平台。我們自己就是每天在接電話、扛 SLA、面對缺工與個資合規的那個角色。

Telli 是一套 Customer Service Operating System，包含：

• Voice（AI 語音） 與 Chat（AI 文字）：涵蓋前面談到的渠道層與 AI 執行層。

• Desk（真人客服工作台 ＋ AI Copilot）：讓 AI 與真人無縫協作。

• Telli Memory（對話記憶層）：讓脈絡不遺失。

• 知識飛輪：Build → Launch → Scale → Govern，再把營運中學到的東西回寫知識底層，形成「更好的 Build」。這正是前面說的閉環回饋——用結果來講，就是讓 AI「越用越準」的機制。

架構上，Telli 是雲端原生（不提供地端部署），可與 CRM、ERP、電商後台雙向串接；同時提供顧問導入與專案管理服務，定位是你的數位轉型夥伴，而不是丟一套工具給你自己摸索。目前服務的客戶橫跨百貨、零售、家電、精品與餐旅集團，包括 一卡通 iPASS、宜睿 Edenred、伊萊克斯 Electrolux、安欣科技（東元集團）、新光三越、昇恆昌、iChef、台泥、大買家等。

結論：別用最貴的方式，買到八成失敗的結果

回到高層那句話：「我們自己接 LLM API 做不就好了？」

現在你有了回答的底氣：接 API 是那 20% 的 Demo；真正的 80% 是渠道、工作台、知識飛輪、整合、合規與持續維運。統計上，純內部自建有八成機率走不到穩定營運；而在台灣，缺工漲薪、個資新法、在地語料的落差，還會把自建的天平壓得更斜。

聰明的作法不是二選一，而是想清楚：哪些是通用基礎建設（用買的、用夥伴的），哪些才是你真正的差異化（自己建）。把工程資源花在刀口上。

你可以現在就做的三件事：

1. 先算帳，再爭論。 用第二節那張五條成本線的檢查清單，把你自己情境的一年與三年投入兩條路都填一次——把人事、電信、合規、維運全放進去，而不是只比「訂閱費 vs 薪水」。

2. 用六題框架自評。 若第 1、4、5、6 題多落右欄（非核心差異、知識常變、AI 要真的操作後台系統、扛不住合規與 on-call），優先考慮 Buy 或混合模式。

3. 若決定混合，先確認開放架構。 平台要能用 API／MCP 與你的 CRM／ERP 雙向串接——這決定了你未來還有沒有空間，在上面疊自己的差異化。

什麼情況該改變上述建議？ 不是「客服對我們很重要」——那反而是更該把資源留給差異化那一層的理由。真正讓自建划算的條件很窄：對話系統本身就是你要賣的產品（那它屬於研發，不是 Customer Operations）、或者你的場景極度單一且幾乎不變、而且你能穩定養住一支不會被抽調的專職團隊，並願意承擔三年以上的維運責任。三個條件同時成立，天平才會往回傾斜。

如果你正在評估這條路，歡迎到 聯絡我們 跟我們聊聊——先不談導入，先幫你把這張 Build vs Buy 的帳算清楚。即使最後你決定自建，這場對話也會讓你少踩幾個我們替客戶踩過的坑。

本文引用之研究與資料來源

1. MIT Media Lab Project NANDA，《The GenAI Divide: State of AI in Business 2025》，2025 年 7 月。https://www.forbes.com/sites/jasonsnyder/2025/08/26/mit-finds-95-of-genai-pilots-fail-because-companies-avoid-friction/

2. S&P Global Market Intelligence（451 Research Voice of the Enterprise），《Generative AI shows rapid growth but yields mixed results》，2025 年 10 月。https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results

3. Gartner，《Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025》，2024。https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025

4. RAND Corporation，《The Root Causes of Failure for Artificial Intelligence Projects》（RR-A2680-1），2024。https://www.rand.org/pubs/research_reports/RRA2680-1.html

5. CloudZero，《LLM API Pricing Comparison》，2026。https://www.cloudzero.com/blog/llm-api-pricing-comparison/

6. Telnyx，《What is Voice AI Latency: Typical Numbers, Standards & How to Measure》，2025–2026。https://telnyx.com/resources/low-latency-voice-ai

7. Introl，《Voice AI Infrastructure: Building Real-Time Speech Agents》，2025。https://introl.com/blog/voice-ai-infrastructure-real-time-speech-agents-asr-tts-guide-2025

8. 行政院主計總處職缺調查；國防安全研究院，〈人力短缺對我國經濟安全的影響〉，2025。https://indsr.org.tw/focus?uid=11&pid=2844

9. 勞動部，〈2026 年勞動新制：最低工資調升至月薪 29,500 元、時薪 196 元〉，2025。https://www.mol.gov.tw/1607/1632/1633/87257/post

10. 全國法規資料庫《個人資料保護法》；理律法律事務所，〈總統公布「個人資料保護法」修正條文〉，2025 年 11 月 11 日。https://www.leeandli.com/TW/NewslettersDetail/7532.htm

11. 個人資料保護委員會籌備處。https://www.pdpc.gov.tw/

12. 台灣中文語音辨識 benchmark：《Twister》，NTU／聯發科研究，arXiv 2506.11130，2025。https://arxiv.org/pdf/2506.11130

13. AISHELL-1 語料庫（openSLR），Bu et al., O-COCOSDA 2017。https://www.openslr.org/33/

14. McKinsey & Company，《Agentic AI and the future of customer experience》，2023–2025。https://www.mckinsey.com/capabilities/operations/our-insights/the-future-of-customer-experience-embracing-agentic-ai

15. Atlan，《LLM Knowledge Base Staleness: Scoring, Causes, and How to Fix It》，2025–2026。https://atlan.com/know/llm-knowledge-base-staleness/

16. RAG About It，《Why Enterprise RAG Systems Need Continuous Learning》，2025。https://ragaboutit.com/why-enterprise-rag-systems-need-continuous-learning-a-technical-guide-to-dynamic-knowledge-updates/

17. SaaS 計價模式趨勢與續約漲價觀察：SoftwareSeni，《SaaS Pricing Is Shifting from Per-Seat to Usage and Outcome》，2026。https://www.softwareseni.com/saas-pricing-is-shifting-from-per-seat-to-usage-and-outcome-what-changes-at-your-next-renewal/

18. Model Context Protocol 企業導入觀察，2024–2025。https://www.holmesconsultants.com/blog/model-context-protocol-enterprise-integration/

註：本文所提成本量級為情境參考，實際數字依企業規模、話務量、既有系統與合規要求而異，請以自身財務評估為準。文中語音延遲與辨識字錯率數據取自公開 benchmark 與學術論文，真實環境表現受噪音、通道品質、口音與訓練語料影響。部分市場觀察（如 SaaS 續約漲價、隱藏成本）屬產業彙整資料，非同儕審查結果。