B2B 訂貨與營運系統
批發商何時需要 B2B 訂貨系統？整合分級價、帳期、庫存與 ERP
從客戶分級價、最低訂購量、帳期審核到 ERP、庫存與物流串接，判斷批發商何時值得建立客製 B2B 訂貨系統。
批發訂貨不是把一般購物車改成登入後才能使用。企業客戶可能有不同型錄、分級價、數量級距、最低訂購量、付款帳期與審核規則；同一家公司還可能有總公司、分店、採購與財務等不同帳號。若網站收到的訂單仍要由內勤重新輸入 ERP、電話確認庫存，再用訊息追問出貨地址，數位入口只是把紙本換成另一張表單。B2B 訂貨系統真正要解決的是價格、權限、信用、庫存與履約資料如何在同一條可追蹤流程中運作。
具體問題與執行難點：同一件商品，對每位客戶都可能不是同一筆交易
批發商常同時維護公開牌價、經銷價、專案價與促銷價，還可能依箱、件、組或累計採購量計價。當業務用試算表查價、客戶在 LINE 下單、內勤再人工核對合約，很容易使用過期價格、忽略最低訂購量（MOQ），或在不同單位換算時產生數量錯誤。若價格規則只存在於資深同仁的經驗，系統即使能收單，也無法可靠地自動算價。
企業帳號也不是單一會員。總公司可能需要查看全部分店訂單與信用額度，分店只能使用自己的收貨地址，採購可以建立訂單，但超過金額後必須由主管核准；財務則只需查看發票與應收狀態。若權限只分成管理員與一般使用者，可能讓分店看到其他據點的價格、訂單或帳務資料。
庫存與履約是另一個斷點。前台顯示有貨，不代表 ERP 的可售庫存已扣除門市、業務保留量或待出貨訂單；允許超賣的品項也要有預計到貨日與拆單規則。訂單成立後若仍靠人工把資料輸入 ERP、物流平台與對帳表，同一筆訂單就會出現多個狀態與多次出錯機會。
- 公司、分店、採購、核准者與財務需要不同資料範圍與操作權限
- 型錄、客戶分級、數量級距、MOQ、包裝單位與專案價必須有明確優先順序
- 帳期、信用額度、訂單審核、庫存保留、拆單與出貨狀態需要共同規則
何時值得做：先確認人工成本與商業規則是否已經穩定
如果訂單量不高、客戶條件大致相同，標準電商或整理過的訂單表單可能已經足夠。客製系統較值得投入的訊號，是內勤每天重複查價、補資料與輸入 ERP；客戶必須等待業務才能知道自己的價格；分店與總公司訂單難以彙整；或因帳期、庫存與核准規則複雜，現成平台需要大量繞路操作。
規則必須先能被說清楚。若同一位客戶每次下單都由主管臨時決定價格，或 ERP 商品編碼長期重複、庫存不準，直接開發只會把不穩定流程寫進系統。較好的做法是先選一組客戶、一類商品與一種訂單流程，整理價格來源、例外條件、負責角色和最終帳務依據，再判斷哪些部分應自動化。
以一家 B2B 經銷商為例：企業客戶旗下可能有多個據點，訂單則從 LINE、Email 與電話進入，內勤每天逐筆確認合約價、箱入數與可售庫存。這類情境的第一階段不必做完整電商商城，而可以先讓已核准客戶登入、看到自己的型錄與價格、送出符合 MOQ 的訂單，再把訂單可靠送進既有 ERP。
- 每週有固定且可量化的查價、抄單、補單或對帳工作
- 客戶、分店或商品規則有差異，但差異可以整理成明確條件
- 既有 ERP 仍是帳務或庫存主系統，需要的是前台與流程整合，而非全面取代
AgentTech 方法與技術設計：先定義資料主責，再建立可稽核的訂單流程
AgentTech 會先畫出從客戶申請、帳號核准、瀏覽型錄、加入品項、內部審核、成立訂單、配置庫存到出貨與對帳的流程，並指定每類資料的主責系統。例如 ERP 管理商品編碼與實際庫存，B2B 平台管理登入、購物草稿與前台體驗，CRM 或合約資料管理客戶等級；只有一個主責來源能修改核心欄位，其他系統透過同步取得結果。
資料模型會把公司、分店、使用者與角色分開，再將可購買型錄、價格表、付款條件與信用額度連結到公司或合約。算價服務依固定順序處理客戶專案價、等級價、級距價、活動價與稅別，訂單成立時保留價格快照與規則版本，避免日後調價導致歷史訂單無法核對。MOQ、箱入數與倍數限制則在加入購物車和送單時共同驗證。
訂單不應只有已成立與已完成。系統可依實際流程設計草稿、待買方核准、待賣方審核、待信用確認、已接受、部分配置、待出貨、部分出貨、完成、取消與異常等狀態。每次價格覆寫、核准、取消與 ERP 回傳都留下操作者、時間與原因；ERP、庫存和物流則透過 API 或批次檔案整合，並提供同步失敗的待處理清單。
- 以角色與資料範圍控制總公司、分店、採購、核准者和財務權限
- 以版本化價格規則和訂單快照保留當時成交依據
- 以狀態機、操作歷程與異常佇列，讓訂單能被追蹤、重送與人工處理
分階段落地：先讓高頻訂單正確進來，再擴充自助服務
第一階段是流程診斷與原型驗證。選取代表性的企業客戶、商品與歷史訂單，確認帳號層級、價格計算、MOQ、帳期和 ERP 欄位映射，並用可操作原型讓業務、內勤與財務共同走過一次完整流程。此階段的目標是找出規則衝突，而不是先製作大量頁面。
第二階段建立最小可用產品：企業與分店帳號、限定型錄、客戶價格、快速訂貨、訂單審核、ERP 匯入或 API 同步，以及內部異常處理後台。先邀請少數客戶平行試行，將系統訂單與原流程對照，驗證價格、數量、稅額、庫存與收貨資料一致後，才逐步擴大使用範圍。
第三階段再依實際採用情況加入常購清單、整批上傳、重複下單、信用額度提示、到貨通知、物流追蹤、發票查詢、業務代客下單或行動版 App。功能優先順序以減少錯單、縮短處理時間與提高客戶自助率為依據，不把所有想像功能一次塞入第一版。
- 階段一：流程圖、資料盤點、規則表、整合風險與可操作原型
- 階段二：限定客群 MVP、ERP／庫存串接、試行與平行對帳
- 階段三：依使用數據擴充自助、物流、帳務與行動功能
最終交付物與驗收：交付可營運的平台，不只是一組前台頁面
專案交付應包含企業帳號與權限、商品與型錄、價格與 MOQ 規則、購物草稿、審核、訂單狀態、內部管理後台，以及約定範圍內的 ERP、庫存或物流整合。AgentTech 也會整理資料字典、角色權限表、狀態流程、介接規格、異常處理方式、管理操作說明與上線檢查清單，讓企業能知道系統如何運作及誰負責處理例外。
驗收不能只看頁面能不能開啟。應用代表性帳號與訂單案例測試：不同分店是否只能看到授權資料；各級價格、級距與 MOQ 是否算對；超額訂單是否進入正確審核；ERP 是否收到唯一且完整的訂單；庫存不足、介接逾時或取消時是否留下可處理紀錄。財務還應抽查歷史價格快照、稅額與帳期資訊能否回到原始依據。
上線後的服務可包含監控、錯誤通知、整合對帳、權限與規則調整、效能與安全更新，以及依採用率規劃下一階段。最終產品不是取代所有既有系統，而是一個讓企業客戶可以自助訂貨、內部人員可以管理例外、既有 ERP 可以持續作為可信營運核心的整合平台。
- 可操作產品：B2B 訂貨前台、企業帳號、審核流程與營運後台
- 系統整合：ERP、庫存、物流或帳務的介接與異常處理機制
- 營運文件：資料字典、權限表、流程圖、操作手冊、測試與上線紀錄
- 驗收證據：代表性訂單測試、跨系統對帳結果、權限與失敗情境紀錄
這篇文章適用的服務
客製系統與數位平台
SYS Agent
需求診斷、CRM、電商、會員、預約、營運後台、資料權限、API 整合與部署維運。