先定義要改善的工作，而不是先選模型
很多 AI 專案一開始就問要用哪個模型、要不要做 RAG、要不要接 LINE 或 ERP。這些問題重要，但不是 ROI 的起點。ROI 的起點應該是某一段明確的工作流程：客服回覆、業務查詢報價、工程文件檢索、採購比價、設備異常判讀，或內部知識問答。流程越清楚，效益越能被量測；流程越模糊，最後通常只剩下展示效果。
我們會先把目前的做法拆成幾個步驟：資料從哪裡來、誰判斷、誰覆核、哪裡等待、哪裡重工、錯誤會造成什麼後果。AI 的價值通常不在於取代整個職位，而是在某些步驟降低查找、整理、比對、初稿產出或例外判斷的負擔。這也意味著 ROI 估算要以工作單元為基礎，而不是以部門人數為基礎。
好的 ROI 問題會長得很具體：如果 AI 助理能把客服人員查規格書與歷史維修紀錄的時間降低，主管是否能處理更多案件，或縮短客戶等待時間？如果系統能從 ERP、CRM 和文件庫整理業務所需資訊，業務是否少花時間追問內部窗口，並更快給出一致答案？這些問題比單純問 AI 能省多少人更有工程可操作性。
把效益拆成可驗證的幾類
AI 專案的效益通常不是單一數字，而是幾種改善疊在一起。估 ROI 時，最好先分開列出，不要急著合併成一個漂亮總額。因為不同效益的可信度不同，量測方式也不同。節省時間相對容易觀察；降低錯誤要看錯誤定義；提升轉換率、縮短銷售週期或提高客戶滿意度，通常需要更長時間驗證。
- 時間節省：例如減少查資料、寫初稿、整理會議紀錄、比對表單、製作例行報表的時間。這類效益要用實際任務樣本估，不要只用訪談印象。
- 吞吐量提升：同一組人可以處理更多案件、更多詢價、更多內部需求。這不一定代表裁員，而是讓瓶頸部門不再阻塞營運。
- 錯誤與重工下降：例如少漏資料、少用過期文件、少重複輸入、少因格式不一致造成返工。這類效益需要定義什麼算錯、誰判定、錯誤成本怎麼計。
- 知識保存與一致性：資深同仁的經驗、產品規則、維修判斷、合約條款如果能被更穩定地查詢，組織對個人的依賴會下降。這項很有價值，但要避免直接硬轉成誇大的財務數字。
- 服務品質：回覆更快、口徑更一致、跨系統資訊更完整。這通常是間接 ROI，適合搭配服務指標與使用者回饋追蹤。
每一項效益都要標註信心等級。已經有工作紀錄、工時、案件量或錯誤紀錄的，可信度較高；只來自主管預期或使用者感覺的，要保守處理。工程團隊寧可先用保守假設做出可落地的版本，也不要用樂觀假設支持一個後續難以維護的系統。
成本不只 API 費用，整合與維運才是關鍵
估 AI ROI 時，常見錯誤是只看模型 token、雲端主機或授權費。真正會影響專案成敗的，往往是資料整理、權限設計、系統整合、測試流程、監控與後續維護。尤其在 B2B 環境，AI 很少單獨存在，它通常要接企業文件、CRM、ERP、LINE 官方帳號、資料庫、IoT 平台或內部簽核流程。
成本可以分成一次性與持續性。一次性成本包含需求盤點、資料清理、系統串接、權限模型、前後端開發、測試與上線。持續性成本包含模型用量、雲端資源、資料更新、提示詞與檢索規則調整、錯誤案例回收、資安稽核、使用者教育與客服維運。若專案只算建置費，不算後續調整，ROI 會看起來過度樂觀。
還有一種成本容易被低估：流程改變的成本。AI 助理如果給了答案，誰要負責確認？什麼情況必須轉人工？答案引用的文件是否足以讓使用者信任？錯誤答案發生時要如何追溯？這些設計不是行政細節，而是 ROI 的一部分。沒有清楚責任邊界的 AI 系統，初期可能看起來省時，後期卻把風險和審核負擔轉移到其他人身上。
用試點專案驗證假設，再決定擴大
比較務實的做法，是先選一個高頻、資料可取得、風險可控、使用者願意配合的場景做試點。不要一開始就承諾全公司導入，也不要把第一版做成萬能助理。試點的目標不是證明 AI 很強，而是驗證三件事：資料是否支撐答案、使用者是否真的改變工作方式、改善是否大於新增負擔。
試點前要先建立基準。比如目前一個案件平均需要哪些步驟、通常卡在哪裡、哪些資料最常被查、哪些錯誤最常發生。上線後再看同一類任務的變化。若沒有基準，專案後期很容易只剩下主觀評價：有人覺得好用，有人覺得還好，管理層無法判斷是否值得擴大。
最後，ROI 不應只是一張投資報酬表，而應該是一個決策工具。如果試點顯示效益明確，就擴大資料範圍、接更多系統、補上權限與監控。如果效益普通，就檢查是場景選錯、資料品質不足、流程沒有配合，還是模型能力不適合。成熟的整合團隊會把這些問題拆開處理，讓企業知道該加碼、調整，或停止投入。