為什麼先從查庫存開始？

許多傳產想做數位轉型，第一步就被要求更換 ERP、重整全部資料，或一次購買整套系統。成本大、時間長，現場的人也不知道完成後是否真的比較省事。

庫存查詢剛好相反。它每天重複發生、結果容易驗證，而且不必改變原本的交易方式。先接上一份 CSV、Excel 或既有 API，讓經銷商從 LINE 自己查貨，就能很快知道這件事有沒有價值。

免費查貨不是縮小版 ERP，而是企業用最低風險認識數位工作流程的入口。

目前真正驗證到哪裡？

我們先建立一套模擬企業的 Odoo 19 情境，包含兩座倉庫、三個品項、已確認的銷售配置量與安全庫存。只整理這次回答需要的資料，再套用由人確認過的「可承諾庫存」規則；六組品項與倉庫答案也都從原始資料重新核對，結果一致。

其中一個品項在台北倉有 8 件、6 件已配置，還要保留 5 件安全庫存，答案是 8 − 6 − 5 = −3。負數會被保留，因為它代表已超出可承諾範圍，不能為了回覆好看而改成 0。

這還不是正式上線的企業 Agent

這次使用的是模擬公司的 Odoo 情境，不是客戶 ERP，也還沒有接到正式上線的店小二或 LINE。為了專心核對計算方式與結果，我們先把系統對欄位的理解固定下來，所以不代表 AI 已能自己看懂任何公司的資料。這次真正確認的是：資料範圍與計算方式由人說清楚後，每個答案都能重新核對；資料不足時，系統不會硬猜。

查得到資料，和做得完工作，是兩件事

一般查詢工具接到問題、找到資料、回覆答案，工作就結束了。但真正的店小二常常還要判斷身分、套用規則、等待核准，並把結果寫回另一套系統。

標準查貨工具

  • 依品號或品名找庫存
  • 顯示各倉數量
  • 無法處理時轉回客服

更深的企業流程（尚未上線）

  • 必須辨識客戶、權限與交易條件
  • 只能依確認過的規則安排下一步
  • 需要追蹤工作直到完成或交給人

未來若要把工作往下做，必須先滿足什麼？

依經銷商等級準備報價

同一項商品可能有牌價、經銷價、專案價與特殊合約。未來若導入報價流程，系統必須先確認經銷商身分與價格來源；超過折扣範圍時不能自行承諾，只能送給業務核准。

把零散詢價整理成可處理的內容

客戶可能一次傳來五個品號、三張照片和一句「月底前要」。可靠的流程應先整理品項、數量、交期與缺少資訊；內容不完整時要提出問題，而不是直接建立看似完整的結果。

建立訂單草稿，但把承諾留給人

只有資料、身分與權限都確認後，未來流程才可能把內容送進 ERP 或訂單系統建立草稿。價格例外、信用額度、特殊交期等高風險決策，仍必須由負責的人確認。

記得工作做到哪裡

有些工作不會在一次對話內完成：等待主管核准、等待供應商回覆，或隔天追蹤缺貨品項。這類具狀態流程還需要知道目前在等什麼、誰可以決定，以及何時應該提醒；這些能力目前尚未在店小二上線。

客製化，不等於每次都從零開發

企業差異通常集中在資料入口、商業規則、權限與核准方式。未來只有在真實需求反覆出現後，才適合把讀取 ERP、產生報價草稿、送出核准或寫回訂單等能力做成可重複使用的積木。

標準能力做成積木，企業規則留在專屬流程

這樣既不會把免費查貨工具做成龐大的萬用系統，也不需要為每個客戶重寫所有基礎能力。

導入前，我們應該先問哪些問題？

  1. 哪一件工作最常重複？ 先找頻率高、規則相對清楚的流程。
  2. 資料現在在哪裡？ Excel、ERP、CRM、Email 或 LINE 都可能是入口。
  3. 哪些決定可以自動做？ 哪些價格、承諾或例外一定要由人核准？
  4. 完成後要寫回哪裡？ 流程的結果必須回到公司真正使用的系統。
  5. 失敗時交給誰？ 每條自動流程都要有清楚的人工接手機制。

不需要一次把公司全部自動化

好的導入不是展示 Agent 會多少，而是選一件能被量化的工作：少回幾次庫存、少整理幾張詢價、少重複輸入幾次訂單。這些成效目前還沒有真實企業數據，必須由第一個 Pilot 在開始前與試用後實際衡量。

所以店小二目前只主張一件已證明的事：一套較接近 ERP 現實的庫存情境，已能在數字定義與資料範圍都說清楚的前提下算出一致答案。下一步才是接上真實企業資料與 LINE，驗證這個方法是否真的減少人的重複工作。