客戶的真實業態
這客戶是跨四個地區（台灣 / 大陸 / 香港 / 馬來西亞）的 B2B 經銷商——產品繁多（醫美儀器級的精密商品），下游店家近兩千家，每家可能對應多個合約（價格體系完全不同）。
業務團隊主要在外面跑——終端是 LINE，不是 ERP 後台。
核心痛點清單（PRD 直接抄）：
- 商品與組合眾多，業務不一定記得貨號
- 同店家可能有多組合約，價格與扣款身份不同
- 活動組合常變動，若無版本保留歷史統計會失真
- 下單後仍可能改單、改合約、改品項，人工處理成本高
- 業務輸入店名 / 品名可能有錯字或簡寫，系統需具備一定容錯
- 手寫訂單辨識只能作為輔助，仍需人工檢核
- 需支援台灣 / 大陸 / 香港 / 馬來西亞不同地區價格庫
為什麼這案不公開客戶名
跨境 B2B 經銷的合約 / 價格體系是商業敏感資訊，揭露品牌會直接洩漏代理關係。客戶 + 川輝雙方同意：對外只揭露『跨境 B2B 經銷商』，不揭露具體商號。
揭露的是 know-how，不是客戶身份。
我們交的東西
1. LINE Bot 為主要下單介面（不是 ERP）
業務在 LINE 一句話下單：
沛牧美學會館 合約 A，H3 水光微針筆 5 支 9 折
系統做的事：
- 店家比對：「沛牧美學會館」用模糊比對對到店家 ID（業務打簡寫也認得）
- 合約解析：「合約 A」對到合約代號 + 該合約的價格體系（含 9 折特殊條件）
- 商品辨識：「H3 水光微針筆」用商品資料庫模糊比對找出 OT131；「5 支」對到數量
- 特殊價檢核：「9 折」如低於合約定價 → 自動觸發特殊價審批 workflow
- 訂單建立：產生訂單號 → 回傳確認訊息 + 訂單按鈕（可點修改）
業務不用打開後台、不用記貨號、不用查價格——口語打字、系統翻譯。
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 本事的不多），我們收到後做的事：
- 完整盤點對照：每一條 PRD 需求對應 schema / API / 後台模組，標哪些已有、哪些缺、哪些是 over-engineering
- 分階段交付：核心鏈路（下單 → 收款 → 統計）先上，OCR / 多地區屬於進階階段
- 權限系統提早設計：因為這客戶的多角色 + 跨地區，權限亂套等於整個系統不能上線——我們在 schema 設計階段就把雙層權限定下
- LINE Bot 容錯 / NLP 反覆迭代：parse-order edge function 是這案最關鍵的單檔——業務真實口語跟工程師寫的 prompt 差很遠，我們收到客戶實際對話 log 後迭代了多輪
為什麼這案值得寫
台灣有大量「業務在外跑、客戶在 LINE 上、ERP 後台複雜到沒人用」的 B2B 經銷商——食品代理、醫美儀器代理、保健品代理、化妝品代理、進口酒商，這個 vertical 至少幾百家公司同樣型態。
這套「LINE Bot 為主、後台為輔、Sheet 為維護介面、雙層權限、多地區、OCR 輔助」的 stack 直接可 transfer 到下一個跨境經銷客戶——對我們是 vertical know-how 累積。