AI 導入該買 SaaS 還是客製開發?用『邊角案例數量』決定的選型準則

先講一個反直覺的結論:AI 導入該買 SaaS 還是客製開發,最可靠的判斷變數不是預算,也不是團隊規模,而是「你的業務裡有多少個邊角案例」。

一家做工業零件的客戶,去年買了一套評價很好的 AI 報價 SaaS。標準品詢價,系統三秒出價,漂亮。問題是他們六成營收來自非標品——客戶丟來一張手繪圖、一段規格描述,要工程師判斷公差、選材、估工時。這些 SaaS 一個都接不住。於是業務部門長出一套影子流程:標準品交給 AI,非標品全部退回 Excel 手算。半年後我們進場,那套系統每天被打開的次數是個位數。

這就是「先買 SaaS 試試看」這句話最危險的地方。它假設你踩到的坑會隨時間變少,但真實情況往往相反。每一個 SaaS 接不住的邊角案例,都會長出一條繞道的人工流程;而這些繞道的成本是隱形的、會複利的,而且不會出現在你當初比價的那張表上。

先搞懂:「AI SaaS vs 客製開發」真正在比的東西

很多人把這題當成「便宜快 vs 貴又慢」。這是錯的框架。

AI SaaS 的本質,是「把你的流程,塞進別人設計好的模具」。模具是為「一般客戶」開的,所以它對標準流程的覆蓋率很高,通常能吃下你八成的日常工作。客製開發的本質則是「照你的流程開一副模具」,前期慢、貴,但每一個轉角都是為你彎的。

真正該比的,從來不是上線那一天的價差,而是總持有成本(TCO):訂閱費、導入費,加上那些為了讓系統「勉強能用」而付出的人工繞道、資料搬運、例外處理,以及最貴的一項——低採用率。

邊角案例,是可以被數出來的

「邊角案例」聽起來抽象,其實可以具體數。它就是那些「系統的預設路徑接不住、必須有人介入才能完成」的情境。

一種是資料形狀不合。你的合約、報表、圖檔格式跟 SaaS 預期的 schema 對不上,每次都要人工轉檔或重 key。一種是流程分歧。你的簽核關卡、退件邏輯、跨部門交接跟內建工作流不一樣,只能用 email 和口頭補。一種是產業規則。金融的稽核軌跡、醫療的病歷格式、製造的非標件判斷,這些是你的護城河,恰恰也是 SaaS 最不可能為你客製的部分。還有一種是系統整合。要跟你那套十年的 ERP 或內部知識庫對接時,標準 API 剛好少了你要的那個欄位。

把這四類逐一列出來、標上「每天發生幾次、每次吃掉一個人多少時間」,你就有了一個可以算的數字。

那個門檻在哪裡

我們的經驗法則是這樣:當需要人工繞道的案例超過核心流程的兩到三成,或者任何一條繞道每天固定吃掉一個人半小時以上,客製的總持有成本通常會在 12 到 18 個月內反超 SaaS。

原因在邊際成本的形狀。SaaS 多接一個邊角案例,邊際成本是陡升的——因為你根本改不動它的核心,只能在外圍堆人力、堆外掛、堆 Excel。客製多接一個邊角案例,邊際成本是平緩的——因為那正是它被設計來吸收的東西。兩條曲線一定會交叉。邊角案例越多,交叉點來得越早。

別急著二選一:大多數人該走第三條路

講到這裡得誠實承認一個取捨:客製不是萬靈丹。如果你的邊角案例其實不多,硬要客製,你只是把 SaaS 省下的錢拿去養一套自己的維運負債。這是我們也踩過的雷。

所以實務上最常見的最佳解,是混合:核心的標準流程用成熟 SaaS 或基礎模型頂著,把工程資源集中投在那兩三成真正是護城河、SaaS 永遠接不住的邊角案例上——用 RAG、Agentic 工作流,或一層薄薄的客製介面把它們接起來。你不是在買現成 vs 客製之間二選一,而是在決定「哪些流程值得為它彎模具」。

在 Tenten,我們做選型評估的第一件事,不是問你預算多少,而是派工程師進你的現場,把邊角案例一條一條數出來、標上頻率和耗時,再算兩條 TCO 曲線的交叉點落在哪裡。因為 Demo 那天全場點頭不算數;半年後系統每天真的有人打開、真的接住了那些非標的麻煩,才算數。