電商 AI 客服採購：自建、SaaS 與外部交付的範圍及成本比較

先讓各份方案回答同一項工作

選定客服工作、使用者、來源與允許行動，再邀請方案說明如何完成。例如政策查找、配送狀態或待覆核的訂單處理，具有不同的資料與權限需求；不能只按「會聊天」比較。

自建應用不一定要訓練或自有一個模型，也不必使用向量庫。它可能呼叫外部模型或既有 API。外部團隊也可能協助設定已購平台，而非重新開發。建置方式、部署位置和交付人員是不同選擇，可以分層組合。

表中的問題應由實際架構、產品能力及合約回答，不先給供應商類別高低排名。

面向	自建應用要確認	購買 SaaS 要確認	外部交付要確認
一次性投入	開發、資料、整合、評估與交接	設定、資料準備、整合及啟用	提案範圍、交付項目、依賴與驗收
持續成本	固定容量、模型／工具用量、覆核與維運	計費單位、額度、超額及支持條件	運作、變更、供應商費用及責任分界
時程依賴	團隊、來源、介面與測試是否就緒	所需能力與介面是否可用	範圍、客戶配合、批准與交接安排
資料處理	哪些資料交給哪些服務、存多久	次處理者、用途、保留、存取與匯出	實際部署、外部存取與資料權利
客製與整合	維護能力、授權與既有系統限制	文件化能力、版本與平台限制	支持的介面、變更範圍及接手方法
營運與失效	誰看品質、處理中斷與版本變更	平台與客戶各自的支持範圍	問題接手、復原及服務範圍
退出與權利	程式、來源內容及第三方授權	資料匯出、遷移、終止及相容性	權利、文件、交接與後續維護合約

用相同工作量、尖峰、品質要求與比較期間估算完整成本。保留有日期的實際報價與假設，不將固定容量或自行部署當成每次請求零成本，也不假設 SaaS 都按對話量線性計費。

省下處理時間可能先形成工作容量，是否減少支出則需額外紀錄。英國政府效率框架（2025-11-24 更新）提供這種方法區分，並不是台灣電商價格或會計規則。

Intercom 連接器 FAQ列出可設定的 API 讀取／更新及多步程序。這是某個 SaaS 能力的具體反例：不能斷言只有客製系統能接入這類工作。仍須確認方案的版本、可用條件、介面和任務驗收；文件不證明本商家的成效或持續記憶。

依任務可使用直接查詢、文件檢索、草稿準備與人工處理的組合。不要為了分層就把退款或金額爭議交給 RAG 決定；檢索提供資訊，交易行動需要自己的權限與規則。

準備退換貨回答時，核對適用市場、政策版本、交易條件、來源權威及消費者權利。台灣消費者保護法第 19 條以收受商品或服務為符合條件通訊交易解除權期間的起點，並有合理例外等規定。公司內規不能單獨證明可以限縮適用權利；個別交易與商品例外仍須由負責人確認。

拆封狀態是否影響處理，應依適用規則及個案條件確認。來源文件顯示修正日期為 2015-06-17；這項引用限於第 19 條的一般邊界，商品例外實施規則仍須另行確認。

確認身份、訂單、允許行動、批准及失敗處理。只使用當次工作需要的資料，不預設完整會員歷史都必要。Intercom API 設計指南（2026-06-15）討論身份、最少資料與後端業務規則，不能代替商家的實際授權。

讓每份方案處理相同的代表性問題、缺漏、衝突、拒絕存取與失效情況。比較來源支持、適用性、完整處理時間及人工負擔。首次回應、實際解決與訂單成功改動是不同端點。

將負責人、來源更新、例外處理、支持與退出條件寫入範圍，再決定配置。資料在自家或供應商環境，都要核對真正的處理及權利，不用部署標籤代替合約。

來源於 2026-10-04 查閱；Intercom FAQ 的相對更新標籤未建立確切日期。可搭配七項客服驗收診斷，並用零售 AI ROI 評估整理完整成本與效益。