Marco｜高效整合下單管道、重建計價邏輯、7成採購商順利遷移LIFF
B2B 生鮮批發系統，服務 4+家供應商（使用後台）與下游 700+ 採購商（使用LIFF）。以第二位接手的設計師身分兼產品負責人，在 16 個月內完成 20+ 個模組/功能（5向度）的入口整合與計價邏輯重建。
Year
2024~2026
Duration
1.5years
Client
4+食品批發供應商
Role & Responsibility
Product Designer / PM｜需求撰寫、規格文件、流程梳理/介面設計、驗收測試、單據改版、操作說明、教育訓練
Category
B2B2B 平台
供應商｜4+
採購商｜700+
日均訂單｜100–300
商品價格模式｜8
經手｜11 個主要模組、20+功能與優化
Intro
整體概括是在鑽研兩件事：
[ 訂單從哪裡進來 ]
原四個下單管道收斂成一個正規入口（LIFF）
[ 訂單金額如何確定 ]
一張訂單無法馬上確認金額（受秤重等現場因素影響）
使用者主流程：供應商 → 設定/操作後台 → 系統 → 出貨 ← 操作LIFF或手動下單 ← 採購商
Background
4供應商的差異
（公版與個別客製化之跟進與取捨）
Ａ商｜系統原始客戶，本產品最初就是為其開發，持續合作至今
Ｂ商｜大量客製化需求（2000+ 商品每日改價、客戶設定、揀貨台與裝箱流程的多項調整）
Ｃ商｜肉品，額外服務（分切、散裝）需求
Ｄ商｜偏採購商角色，會再轉賣給下游商店
接手時狀態
系統已上線約 1.5 年，我是第二位接手的設計師
沒有 PM 因此身兼。由全端工程師監督與覆核
需求來自四個方向：
客戶老闆（立即評估）、業務窗口（收集後批次評估）、操作人員的教學請求、bug 回報（立即處理）
由我預先開票並排優先級，主管再覆核（設計與開發視角以及經驗的差別，對優先級的判斷經常有落差）
大量時間熟悉既有邏輯架構與元件：8 種價格模式、各層級/功能設定、全端複雜的交互影響、上下游廠商與客戶之關聯設定與其對商品可見性和價格的影響
整體經手模組與功能以時間軸呈現（見圖一）
Ａ 訂單從哪裡進來
客戶批發商的下游有眾多採購商，長年並存四個下單管道：
LINE 訊息/手寫單、一般 App、專屬 App、網站。
多平台多年來導致管理與規則統一困難。採購商也陸續反映不確定該用哪個平台叫貨，並擔心自己用的通路是不是不夠優惠、有沒有隱形限制。
供應商也苦於來源繁多的管理成本，我方（系統商）也需平行維護這些管道。
對三方來說都不是理想的長期互動模式。
因此聚焦在統一一條高效的下單管道，也提高處理訂單的效率
A1｜手動建單改版
使用者｜供應商的建單操作員
目標｜加快建單速度，原版所有核心功能、邏輯流程全遵守（但尋找更清晰的呈現方法）
關鍵決定1｜把鍵盤操作納入，全流程可純鍵盤完成，不需離開鍵盤
關鍵決定2｜「客製化商品」功能，可以直接在建單時新增尚未在系統裡建好的商品（因手動建單經常有客製商品的需求情境），不需「回系統商品頁去新建」或「找既有商品充當+備注」
過渡期保留｜原版較高頻使用的「依分類查找商品」不刪除，讓操作習慣一定程度維持
痛點1 ｜需逐一搜尋商品，且搜尋速度慢
解方1 ｜ 搜尋加速、一次搜尋可加入多筆商品
痛點2｜5步驟型流程，無法在一頁內完成
解方2｜精簡、統合操作，一頁內即可全部操作完成（唯需要先選客戶，系統才能篩出該客戶可看到的商品與被設定的價格）
痛點3｜價格類型、有無手動調整..等非常難分辨
解方3｜使用顏色區分預設價、已調整價等
整理為四Section，清晰區分操作與資訊：
客戶資訊、商品明細、價格明細與備注、確認建單
客戶回饋
「蠻好用也比較快，如果地址可以輸入一個字就能搜尋地區的話更好」
因此後續持續依照實際狀況來優化迭代、關聯更新（預設帶入客戶綁定的地址、常用商品詞條、價格回填、計重等）
A2｜LIFF App
核心需求：
進入方便（第一次使用：採購商進入供應商官方LINE，點擊進入連結，且不需下載安裝）
操作方便（相較原版省去許多操作、步驟與彈窗頁面）、
一站式管理（完全不需跨平台查看與操作，更新訊息同樣推播至LINE）
18+ 主要頁面：註冊、登入（主要/多帳號）、未開通、公告彈窗、商城、搜尋、商品詳情、收藏、快速購買、購物車、確認下訂~編輯配送~已下訂、訂單列表/詳情、帳單列表/詳情、線下結帳、會員中心…等全部完整頁面
後續迭代
購物車｜移除 改為 移至收藏、
訂單｜待審核訂單可編輯商品
公告與商品卡片呈現調整
因應系統功能新增或改版時進行相應的調整
….等多筆迭代。
A3｜多帳號切換與 LINE 綁定
問題：採購商沒有總公司聯盟/分店功能，切換帳號要先登出再登入，操作繁瑣
參照：IG 的裝置內多帳號（長按頭像切換）
設計要點：
主帳號＝綁定 LINE 的帳號，打開 LIFF 預設登入主帳號
子帳號登入後將採購名稱、帳號、token 記憶在裝置中（token 效期 7 天）
主帳號登出＝清空裝置上所有帳號記憶（並解除 LINE 綁定）
四種帳號失效情境各有不同的處理路徑
全域明確顯示「現在正以哪個採購 + 哪個帳號操作」，購物車到下訂流程尤其必要（顯示於Header）
A4｜手寫訂單辨識 OCR（多規格收斂成唯一規格）
背景
LIFF 推行後仍有約20%採購持續用 LINE 訊息下單 —— 打字、傳手寫訂單照片（對其來說用講的寫的最快）或excel/表格/PDF訂單（量大且固定）
兩代解法：先讓建單更快（A1手動建單改版）→ 不必人工建單（OCR自動辨識訂單）
核心難題：大量形式的手寫/表格訂單皆需能順利辨識、辨識結果對應到這家供應商的商品清單、並能轉譯商品行話
行話學習機制：讓AI學會廠商之間習慣的簡寫，「排」＝豬排骨、「高」＝高麗菜
準確度演進：初期準確度不佳，靠反覆測試與比對邏輯調整逐步提升
操作員批量上傳手寫訂單照片 → 大量自動辨識、自動建單 → 高效逐單檢查、正式建單、會出統一規格之excel
實作
亮點1｜自訂檔案夾模式，可分流每日或每位採購商，避免千張以上訂單交雜混亂，且可篩選搜尋
亮點2｜批量上傳等待時同時讓人工確認每筆訂單的客戶（部分訂單不會有任何客戶資訊，且辨識訂單前必須要確認客戶才能套用該客戶的商品可見與價格設定）
亮點3｜信心度分級：以顏色標示 AI 辨識的信心度，過低項目引導人工複查、空缺項目警告色
亮點4｜Bounding Box– focus欄位時，預覽畫面會高亮該欄位值於照片中的位置，極度幫助人工複查。
亮點5｜拆單：一個PDF訂單通常是一採購商在各分店（不同採購單位）的訂單，支援根據採購單位自動拆單，避免單一訂單包含不同配送地點
成效與迭代
2個月即完成（需求與設計稿3周，開發3週，測試3週），後續同步優化迭代持續3個月
初期準確度約45%，後期準確度70%以上。初期辨識成訂單速度約一張40秒，後期一張15秒。
初期容易因關鍵項目缺少或無法定位而整單辨識失敗（約30%），經邏輯參數調整，辨識失敗率不到8%
後續持續優化且配合其他功能關聯調整，如「計價邏輯更新」「單位/數量轉換、」「遠信額度顯示」等
A5｜訂單可新增商品
訂單建立後，後台原本只能調整數量與金額，不能新增商品。
將新增商品之功能帶入，大幅增加供應商員工理單時的便利性（雙方很容易有商品改動之需要）
從設計角度相對簡單，把新增流程做清楚即可；但在後端是很大的改動，牽涉訂單快照的重建，以及釐清什麼訂單狀態可以新增、什麼狀態下不可…等邏輯條件。設計成本與工程成本總不成正比，學習排優先級時必須優先考量各方耗時與排程。
主線 A 成果
LIFF 推行的方式是由後端直接為每個採購商開通可進入 LIFF 的帳號，再由供應商漸進式地請採購商使用並教學。
最終約 7 成採購商順利完成遷移（主因爲不需要再下載App、請人設定帳號），
1 成尚未從專屬 App 轉出（雙方私下的需求），
2 成小型採購者持續以 LINE 訊息與手寫訂單下單。
因此再催生OCR辨識訂單之產品，完成一輪全面的下訂單與整理訂單之優化
B 訂單金額如何確定
計重上線前
供應商處理「賣出時不確定重量」的方式是：
在訂單詳情把數量暴力改成能湊出正確金額的數字，並在備註寫下原因。
因不會顯示「重量」，員工只能拿「數量」來換算重量，備註成為唯一參照。
訂單出貨後鎖定，就只能到帳單那邊再改一次數量、再寫一次備註。
也常算完後乾脆取消訂單，打電話請客人依指示重下一次。
每天約 50 張該情境訂單、佔總量 10–20%
問題
多數訂單的商品，在下單當下算不出金額：因時價尚未定價、重量尚未秤重。
而系統同時存在 8 種價格模式：定價、時價、指導價、計重價、專屬價、分組價、會員價、以量定價。
B1｜新增商品計價方式：按重
商品層級新增「計價方式」設定，可選按件或按重，與原版的定價／時價無關
（過去的商品預設為按件）
採購仍按「單位」下單（袋、包），只有計價方式改變
選擇按重時，「單位轉化公斤數」為必填（才能知道1包=幾台斤）
影響範圍：幾乎全域，只要出現單價與價格計算處皆改版
關鍵設計決定
LIFF 上誠實標示「（預估）」，並在訂單確認頁聲明「實際訂單金額會受最終出貨重量而調整」
實際重量的防呆只提示、不阻擋（低於預估或超過預估 1.1 倍時跳提示）—— 現場情況太多變，不做硬阻擋
修改實際重量會改變總價，修改數量不會 —— 數量代表採購商要的件數，實際重量是秤出來的結果（若直接修改數量）
B2｜運費設定模組
運費設定 =運費性質 + 運費模式 + 套用範圍
三層優先級：指定客戶 > 客戶標籤 > 全體，一個客戶只套用到一個運費設定
互斥檢查：一個客戶標籤／一個客戶不可同時被兩個運費設定選中
下單時快照：下單時記憶當時的運費設定，後續修改設定不溯及既往
金額變動觸發重算：因時價會變動連帶影響運費，訂單金額修改時需依運費設定重算
既有資料遷移規則：未設定運費 ⇒ 默認為「下單時不顯示」；已設定運費 ⇒ 默認為「滿 0 元運費即 X 元」
訂單詳情皆註明當前運費來自哪一條設定，或已被手動調整
B3｜額外服務與耗損
額外服務
（C商需求 → 後被大家接受成為公版）
可為商品開啟服務組（如牛肉可被設定：原塊／厚切／絞肉／薄片），並各自設定加工價
下單後以快照記錄，商品設定後續變更不影響已成立的訂單
同樣可新增「客製化」服務項目，專屬於單一訂單，不同步回商品設定
耗損管理
（專屬C商需求）
肉品裁切產生之邊角料由客戶負擔，供應商在揀貨台或訂單編輯登記耗損
供應商層級的開關，關閉後不影響已登記的訂單
三種計價公式各有不同的耗損計算方式
B4｜[信貸額度] 管理
緣起
串接第三方貸款商遠信。供應商替有需求的採購核給購買之額度，
採購商可先用額度下單，日後統一結帳後由遠信將費用先支付給供應商
緩和雙方現金週轉不穩的狀況，也開啟更多下單的機會與意願，讓雙方皆有受益
實作
兩種額度：遠信額度（正式可信貸額度） ＆ 系統額度（供應商可設定給採購的緩衝量）
在停用遠信的情境下，既有額度全沿用至系統額度，避免帳務遺失。
與計重功能的連動：實際重量確定後金額變動，額度必須跟著修正
採購端同步迭代顯示自己已用額度、下單時檢查可用額度之放行與阻擋等
並同步優化訂單與帳單的關係：訂單可超連結到所屬帳單
任何讓訂單/帳單金額有變動的行為，額度都需在下次刷新時更新
所有的操作可由同個入口前往，解決多步、跨模組操作造成迷路與耗時
也一併將客戶的帳單做統計呈現，方便一併檢視/操作額度與帳款狀況
帳單相關術語也進行統一更新（如「結算」統一改為「付款」）、
新增「等待撥款」（待遠信系統認同該筆額度取用之「介於未付款與已付款之間的狀態」）等因應額度所新增、調整的帳單狀態（包含對帳單）
測試與上線
為大型模組，影響範圍從客戶設定、額度顯示、訂單一路到帳單。
除金流串接、額度顯示與設定外，所有關聯訂/帳單金額皆需重理清。
釐清額度的生命週期與各狀態下的邏輯，
並密集嚴密測試，確保無計算錯誤、遺漏、浮報的可能性
B5｜帳單閘門
帳單建立前的檢查是整條收斂流程的終點閘門：
時價商品未定價、計重商品未設定實際重量，都不可建立帳單。
在此之前訂單金額允許調整；成立帳單後，金額必須確定。
（若調整數量，系統會以相對數補回，確保金額不變）
主線 B 結果
計重上線後，揀貨時可一次查看多個客戶的訂單，
系統自動彙整同一品項各客戶的需求量並換算為重量，操作員照著秤即可。
系統支援與電子秤直連，實際秤重可一鍵回填。
出車時，秤重結果自動回寫訂單的「實際重量」並重算金額；
數量維持原樣，保留人工調整空間。
「秤重」首次真的能正式決定金額，解決「改數量湊金額」等暴力人工法。
橫向判斷x5
H1｜改一個欄位，就需掃描整個系統
客戶提出要為採購商加上「客戶編號」以管理旗下幾百位採購商（不能全靠店名/人名辨識）
需求看似簡單，但必須全系統排查：哪些頁面要顯示、支援，不能漏掉任何一處。
H2｜公版與客製化
單一客戶的需求先做成客製化；
當第2,3 個客戶提出類似需求時，再評估是否擴大為公版。
Marco 原本是為單一大型供應商開發，成熟後才對外拓展客戶，
「客製化先行、公版後至」是自然路徑。
例子
訂單標籤份數列印：Ｂ商提出 → 判斷所有供應商都需要，且功能獨立/影響不大 → 直接做成公版
肉品額外服務：C商的客製化需求 → 後續收斂為所有供應商可用
每寫一份規格都要判斷影響對象是公版還是單一客戶。
有時需要主動聯絡客戶，確認他們能否接受改變或不改變。
H3｜台斤
重量單位原本幾乎寫死為公斤，但半數供應商習慣使用台斤。
在供應商層級新增重量單位設定後，所有呈現重量的位置都要跟著切換。
而揀貨台的秤重輸入必須改成「斤」「兩」兩個欄位
—— 因選擇台斤時，磅秤顯示的是 0.3.76 這樣的格式（斤.兩.錢）
進位規則：[兩]四捨五入到整數，滿 16 進位到[斤]（輸入 50 兩 = 3 斤 2 兩）。
但資料庫實際儲存的仍然是斤，僅在輸入與呈現層做轉換（出貨與秤重時的顯示與單據）。
單位設定會影響計重商品的預估重量、實際重量、耗損登記、訂單匯出、帳單明細等所有顯示重量的位置。
H4｜設計交付到紙上
也需要做系統輸出的出貨單與訂單標籤。
要同時滿足出單機與打印機的格式限制、以及客戶已經熟悉的舊版面，
靠反覆使用點陣列印機與出單機試錯調整出來。
不同供應商的需求、著重點不一，都需各自產出不同格式規格的單據
H5｜商品可見性—客戶黑名單制
原廠會有一些優惠、特別商品，不願開放給部分更下游的採購購買
或者是中游通路商，不讓下游採購看到自己上游原廠的商品（因少了中游抽成，價格更低）
因此催生黑名單功能，同樣需重新釐清一遍「商品可見性」之整體設定與層級
原則x3
G1｜永遠留一條手動的路徑
不管系統算得多準，都要有一個選項讓操作員完全手動處理。
供應商會私下對不同採購商有不同的合作條件與優惠，自動化規則追不上線下人情。
幾乎所有自動計算之數值，都設計有手動調整的方式，並明確標記是手動值，且可再恢復為自動計算（秤重、實際重量、價格、運費…）
G2｜非必要不去變動
在牽一髮動全身的系統裡，改動本身就是風險。
與新功能沒有關聯的既有項目，即使不理想也盡量不動。
只有當它明確阻礙了新功能，才會與客戶討論能否移除或簡化
— 先確認他們是否還在使用、是否也覺得不需要了。
例：隱藏「訂單附屬品功能」（如棧板、菜籃）並持續評估使用情境；
「運費批量修改」雖是客戶建議，但評估後判定當前設定量可負荷，且邏輯改動巨大，暫定不動
G3｜誠實呈現不確定，而不是假裝確定
LIFF 商品與購物車的「（預估）」標示、
訂單確認頁的「實際金額會受最終出貨重量而調整」聲明，
以及 OCR 建單的信心度顏色標示，都是同一種判斷：
當做不到百分之百確定時，需告知使用者，並引導注意力放在需要人工確認之處。
其他負責模組/功能
已成立訂單可編輯給採購看的備注
訂單優化：顯示出貨批次與車次
出貨批次／揀貨台的持續優化迭代（操作順暢度/項目顯示與排序/列印與匯出/狀態標示/操作防呆優化、「缺品單」列印）
快購清單功能：設定推薦給特定採購的商品清單，顯示在LIFF的收藏頁
專屬價／快購清單的 Excel 匯出匯入，供客戶批次調整後回匯
商品批次設定匯入：原廠廠商、採購者、預設揀貨台
供應商計重單位設定（公斤or台斤）（台斤是否以「兩」為最小單位）
各供應商的訂單匯出與明細客製化
Takeaway
｜回顧成長軌跡｜
介面效率 → 平台建置 → 系統邏輯 → 金流規則。
從「把流程與畫面做好」（UXUI）、「提高效率優先」到「好好把規則搞清楚」（深入理解系統架構）、「規劃最佳解才去做畫面流程」（見樹見林的完整視角去評估解方）
｜接手的代價與收穫｜
花大量時間熟悉既有邏輯，但也因此有機會處理全新專案不會遇到的問題
— 資料遷移規則、改動的成本/風險評估、既有使用習慣的遷就
｜遺憾｜
未獲准到倉庫現場觀察揀貨作業。出貨批次的邏輯全靠與操作人員、業務反覆釐清
