AI 客服串接 ERP／CRM 的核心不是把模型接上去，而是先定義資料、權限與失敗時的人工流程。對台灣中小企業來說，最安全的導入順序通常是「只讀查詢 → 建立工單 → 受控寫入」，每一步都用固定情境驗收。
優創智能公開定位包含企業 AI 導入、流程自動化與 AI 客服；實際能否接軌舊 ERP，取決於資料欄位、API、權限與內部窗口，而不是單看模型名稱。本文以採購與導入決策為目的，算例都是示意，不代表特定客戶成果或固定報價。
優創智能 AI 客服串接 ERP／CRM 的第一個門檻：先分清楚讀取與寫入
AI 客服接軌舊 ERP 需要先畫哪張資料地圖？
第一張圖不是系統架構圖，而是「問題到資料欄位」的對照表。每個客服情境都要標示資料來源、允許的動作、資料新鮮度與失敗後的去處。
| 客服情境 | 主要資料 | 第一階段建議動作 | 風險控制 |
|---|---|---|---|
| 查詢訂單狀態 | 訂單編號、狀態、出貨時間 | 只讀查詢 | 先驗證顧客身分與訂單關聯 |
| 查詢會員權益 | CRM 會員等級、到期日 | 只讀查詢 | 不回傳不必要的個資欄位 |
| 申請退換貨 | 訂單與退貨規則 | 建立待辦或轉人工 | 不讓模型自行判定例外賠償 |
| 修改聯絡資料 | CRM 電話、Email、地址 | 受控寫入 | 欄位驗證、二次確認與審計 |
| 發放折扣 | 促銷規則、客群條件 | 查詢核准活動 | 折扣由規則引擎或核准 API 決定 |
如果團隊說不出「這個回答來自哪個欄位」，這個情境還沒有準備好進入自動化。FAQ 可以先用文件知識庫處理，訂單和會員問題則要另外處理身分、權限與資料同步。
ERP、CRM 與知識庫的資料責任怎麼切？
ERP 或 CRM 是交易資料的來源，知識庫適合保存政策、SOP 與說明文件。把兩者混在同一個可自由修改的索引裡，會讓客服回答無法判斷哪一份資料優先。
| 資料類型 | 建議來源 | AI 回答時的處理 |
|---|---|---|
| 即時訂單狀態 | ERP 或訂單服務 | 即時查詢，不寫入知識庫 |
| 退換貨政策 | 核准文件與規章 | 版本化後供檢索 |
| 客戶聯絡資訊 | CRM | 依欄位最小化回傳 |
| 促銷與折扣 | 規則服務或核准表 | 只回傳有效期間內結果 |
| 例外處理 SOP | 知識庫與人工流程 | 超出條件就轉人工 |
企業應指定每種資料的 owner、更新頻率與失效行為。資料過期時，系統應說明無法確認並轉人工，不應讓模型用舊內容補出一個看似完整的答案。
AI 客服串接舊 ERP 的三階段導入流程
步驟 1：建立資料、身分與責任清單
先挑 5–10 個高頻且可驗收的問題，逐題填入以下欄位：
- 使用者如何證明自己有權查看資料。
- 需要的最小欄位與允許的最大回傳範圍。
- 資料的來源系統、更新時間與負責人。
- API 不可用或資料缺漏時的替代流程。
- 哪些例外一定由人工判斷。
這一步的交付物應是流程表、欄位對照、權限矩陣與測試樣本，而不是只有一張展示用的聊天畫面。
步驟 2：先做只讀查詢，再建立人工工單
只讀功能能先驗證資料是否正確、身分是否可靠，以及顧客問法是否足夠涵蓋。若回答無法取得資料，系統要回傳清楚的狀態，例如「目前無法查詢，已建立人工處理」，而不是猜測訂單進度。
建立工單通常比直接修改 ERP 更容易控管。AI 可以整理對話、填入已驗證欄位並建立待辦，但提交前仍要由規則或人工確認必要資料。
步驟 3：針對高風險寫入做受控工具
每一個寫入工具都應有明確名稱、輸入 schema、允許角色與可追蹤的請求識別碼。模型只能選擇工具和填入候選值，不能自行決定折扣、退款金額或權限。
使用者身分驗證
→ 讀取最小必要欄位
→ 顯示即將執行的動作
→ 規則驗證與人工核准（必要時）
→ 帶 idempotency key 執行一次
→ 回傳結果並保存審計紀錄
若上游系統沒有 idempotency 設計，先把功能限制在查詢或工單，避免網路重試造成重複訂單、重複退款或重複通知。
ERP／CRM 整合的 AI 客服驗收：用情境而不是 Demo
哪些案例必須在驗收集裡？
驗收集應同時包含正常、邊界與失敗情境。以下是可直接交給導入團隊的起始版本：
| 測試類型 | 範例 | 通過條件 |
|---|---|---|
| 正常查詢 | 顧客查詢自己的訂單狀態 | 欄位、時間與來源正確 |
| 身分不足 | 顧客只提供他人訂單編號 | 拒答並提供安全替代流程 |
| 資料過期 | 促銷已結束但舊文件仍在索引 | 依版本判斷，不套用舊規則 |
| API 失敗 | ERP timeout 或回傳 5xx | 依降級流程轉人工或稍後處理 |
| 重複請求 | 使用者連續點擊退款 | 不產生重複寫入 |
| 例外狀況 | 超過政策期限的退貨 | 不擅自承諾，交給指定角色 |
| 審計檢查 | 完成一次受控異動 | 可追溯操作者、時間與規則版本 |
不要只測「AI 能不能答對」。還要測「AI 不應該回答什麼」、「資料不在時怎麼停下來」以及「出錯後誰接手」。
成效指標要怎麼拆？
至少把下列指標分開，不要只報一個自動回覆率：
- 查詢正確率：回答是否與來源系統一致。
- 安全拒答率：無權限或超出範圍時是否停止。
- 人工轉接完成率：轉接後是否帶齊上下文。
- 寫入成功與重複率：交易是否一次且可追蹤。
- 例外處理時間：從 AI 停止到人工接手的時間。
AI 客服 ERP 串接成本怎麼算？
串接成本不只是一個 API 開發工時，還包括欄位確認、測試帳號、權限審查、失敗復原與後續維護。正式報價應拆開一次性建置、第三方費用與內部投入。
以下是示意預算表，不是市場均價或優創智能報價：
| 項目 | 示意投入 | 需要確認的問題 |
|---|---|---|
| 資料與流程盤點 | 2–4 個工作天 | 是否包含跨部門訪談與欄位表 |
| 只讀查詢 PoC | 1–2 週 | 是否包含測試帳號與失敗情境 |
| 受控工具整合 | 2–4 週 | 哪些寫入動作、誰負責核准 |
| 驗收與培訓 | 3–5 個工作天 | 是否交付測試集與操作文件 |
| 持續維護 | 依月或保底工時 | API、文件、權限變更如何計價 |
如果一份報價只寫「AI 客服串接 ERP」而沒有列出系統、欄位、動作與驗收，價格沒有可比性。這也是比較AI 導入費用與預算時最容易漏掉的差異。
優創智能適合在哪一段介入？
企業沒有專職 AI 工程團隊時，導入顧問的價值通常在於把業務流程、資料與系統責任整理成可交付的工作。優創智能的AI 客服服務與企業 AI 導入可作為需求討論入口，但實際範圍仍應依現有 ERP、CRM、LINE OA、資料權限與驗收條件書面確認。
採購前可以先準備一頁需求摘要：目前客服量、前 10 個問題、資料來源、希望查詢或寫入的欄位、人工轉接規則，以及不能出錯的情境。資料越具體，越容易比較自建、現成 SaaS 與 FDE 導入的總成本。
最後的判斷標準很簡單：先讓 AI 在可逆、可讀取、可追蹤的範圍內工作，再逐步擴大權限。只要企業還說不清楚資料 owner、人工接手人與失敗處理，就不應急著開放交易寫入。