跨境 B2B 經銷商 — LINE Bot 自動接單 + 多地區價格體系

這客戶是跨四個地區（台灣 / 大陸 / 香港 / 馬來西亞）的 B2B 經銷商——產品繁多（醫美儀器級的精密商品），下游店家近兩千家，每家可能對應多個合約（價格體系完全不同）。

業務團隊主要在外面跑——終端是 LINE，不是 ERP 後台。

核心痛點清單（PRD 直接抄）：

1. 商品與組合眾多，業務不一定記得貨號
2. 同店家可能有多組合約，價格與扣款身份不同
3. 活動組合常變動，若無版本保留歷史統計會失真
4. 下單後仍可能改單、改合約、改品項，人工處理成本高
5. 業務輸入店名 / 品名可能有錯字或簡寫，系統需具備一定容錯
6. 手寫訂單辨識只能作為輔助，仍需人工檢核
7. 需支援台灣 / 大陸 / 香港 / 馬來西亞不同地區價格庫

跨境 B2B 經銷的合約 / 價格體系是商業敏感資訊，揭露品牌會直接洩漏代理關係。客戶 + 川輝雙方同意：對外只揭露『跨境 B2B 經銷商』，不揭露具體商號。

揭露的是 know-how，不是客戶身份。

1. LINE Bot 為主要下單介面（不是 ERP）

業務在 LINE 一句話下單：

沛牧美學會館 合約 A，H3 水光微針筆 5 支 9 折

系統做的事：

1. 店家比對：「沛牧美學會館」用模糊比對對到店家 ID（業務打簡寫也認得）
2. 合約解析：「合約 A」對到合約代號 + 該合約的價格體系（含 9 折特殊條件）
3. 商品辨識：「H3 水光微針筆」用商品資料庫模糊比對找出 OT131；「5 支」對到數量
4. 特殊價檢核：「9 折」如低於合約定價 → 自動觸發特殊價審批 workflow
5. 訂單建立：產生訂單號 → 回傳確認訊息 + 訂單按鈕（可點修改）

業務不用打開後台、不用記貨號、不用查價格——口語打字、系統翻譯。

2. 雙層權限系統（後台 UI × LINE 端）

這客戶的權限模型有兩條獨立軸：

• 後台 UI 權限：哪個角色能看 / 改 / 刪 哪個模組（業務 / 主管 / PM / 系統管理者）
• LINE 端權限：哪個 LINE 帳號可下單、可查價、可看全公司訂單

兩條軸獨立配置但對應同一個 user——例如 PM 可改商品資料但不能下單；業務可在 LINE 下單但不能改商品；主管能審批特殊價但不能改合約結構。

後台有「角色編輯器」可視化編輯這雙層權限矩陣，所有 module × action 用 JSON 存在 custom_roles 表的 backend_permissions 與 line_permissions 欄位。

3. 20 個後台模組（完整鏈路）

總覽         商品管理         客戶管理      訂單管理         系統管理
├ 儀表板    ├ 商品主檔       ├ 店家管理   ├ 訂單管理      ├ 銷售統計
           ├ 組合商品       ├ 合約管理   ├ 交易明細      ├ LINE 使用者
           ├ 價格管理       ├ 儲值管理   ├ 特殊價審批    ├ OCR 紀錄
           └ 活動價格       └ 收款紀錄                  ├ 系統日誌
                                                       ├ 資料匯入
                                                       ├ 系統設定
                                                       └ 帳號管理

每個模組對應前述某條業務鏈路——商品建檔 → 合約綁定 → 價格套用 → 訂單建立 → 收款 → 統計閉環。沒有冗模組。

4. 多地區價格體系

商品主檔每個 SKU 有 地區 欄位（taiwan / china / hk / my），同一商品可在不同地區掛不同價格 / 不同合約。Sidebar 切換地區就切換整套資料庫視角。

這對「跨境 B2B」是基礎要求——但市面上多數 ERP 套版不支援這種多區架構。

5. OCR 手寫訂單輔助

客戶仍有部分傳統業務用紙本訂單。我們做了 OCR 紀錄模組：

• 業務拍訂單照片 → 上傳 → OCR 辨識
• 結果存「時間 / 使用者 / 信心度 / 狀態 / 辨識內容 / 操作」六欄記錄
• 信心度低於門檻自動進人工檢核 queue
• 辨識內容可直接轉成系統訂單草稿，業務確認後送出

OCR 不取代業務，是替業務省 80% 打字時間。這個 framing 是我們提的——避免「AI 全自動」的虛幻承諾。

6. Google Sheet 作為「可維護資料庫」

PM / 老闆對 Google Sheet 熟悉度遠高於 admin 後台。我們設計成：

• 商品 / 合約 / 價格的批次匯入用 Sheet 直接吃資料
• 每張 Sheet 對應一個 import edge function（import-customers / import-products / import-payments / import-transactions）
• 改資料先改 Sheet → 點匯入 → 後台自動更新

這比強迫 PM 學 admin UI 自然多了。

7. 活動組合版本保留

活動組合（A 商品 + B 商品 + C 商品打包價）會動。傳統做法是直接改現有組合——但這會讓「歷史訂單統計」失真（過去買的組合內容跟現在不一樣）。

我們做的是版本快照：每次組合改動 → 寫新版本號；歷史訂單永遠對到當時下單的版本；統計可選看「按 SKU」或「按組合版本」。

PRD v1.0 是客戶寫的（很罕見——客戶有 PM 本事的不多），我們收到後做的事：

1. 完整盤點對照：每一條 PRD 需求對應 schema / API / 後台模組，標哪些已有、哪些缺、哪些是 over-engineering
2. 分階段交付：核心鏈路（下單 → 收款 → 統計）先上，OCR / 多地區屬於進階階段
3. 權限系統提早設計：因為這客戶的多角色 + 跨地區，權限亂套等於整個系統不能上線——我們在 schema 設計階段就把雙層權限定下
4. LINE Bot 容錯 / NLP 反覆迭代：parse-order edge function 是這案最關鍵的單檔——業務真實口語跟工程師寫的 prompt 差很遠，我們收到客戶實際對話 log 後迭代了多輪

台灣有大量「業務在外跑、客戶在 LINE 上、ERP 後台複雜到沒人用」的 B2B 經銷商——食品代理、醫美儀器代理、保健品代理、化妝品代理、進口酒商，這個 vertical 至少幾百家公司同樣型態。

這套「LINE Bot 為主、後台為輔、Sheet 為維護介面、雙層權限、多地區、OCR 輔助」的 stack 直接可 transfer 到下一個跨境經銷客戶——對我們是 vertical know-how 累積。

認識熊董 →