電商多通路庫存同步流

🎯 這條流程解決什麼

只要同一款商品同時掛在官網、蝦皮、momo、Yahoo 等多個通路，庫存管理就會立刻變成一場永遠對不齊的拉鋸戰。問題的根源很單純：每個通路各自記著一個「可售數量」，但實體倉庫的存貨只有一份。當蝦皮賣掉一件，如果沒有人手動把官網與 momo 的數字也減一，這件已經出去的貨在其他通路眼裡仍然「有現貨」，於是顧客照樣下單、照樣付款，最後賣家才發現倉庫根本沒貨可出——這就是電商最頭痛的「超賣」。反過來，店家為了怕超賣，常常把每個通路的可售量都壓得很低、留一大段安全緩衝，結果又變成「明明倉庫還有三十件，蝦皮卻顯示售完」，白白錯失訂單。

如果純靠人工同步，這件事幾乎不可能做好。一個有 500 個品項、掛 4 個通路的賣場，等於要維護 2000 組庫存數字。倉管人員通常得每天早晚各登入一次每個後台，把昨天各通路的銷售明細匯出、用 Excel 彙總、再一個一個品項回頭去改各平台的可售量。光是這件事，一個人每天就要耗掉 1.5 到 2 小時，遇到檔期、大促銷售爆量時根本追不上更新速度，超賣與斷貨同時發生。更別說人工抄寫難免抄錯數字，一個按鍵失誤就可能讓某個爆款在所有通路瞬間「賣到負庫存」，引發大批取消訂單與客訴。這些隱性成本——道歉、退款、取消訂單拉低店家評分、錯失的銷售機會——加總起來遠比想像中可觀。

這條流程的核心價值，就是把「多通路庫存對齊」這件高頻、高出錯、又毫無創造性的苦工完全自動化：任一通路售出就即時彙整、AI 計算出最新的真實可售量、再把同一個數字回寫到所有通路，讓每個平台看到的庫存永遠一致，從源頭杜絕超賣與不必要的斷貨。

導入後的改變

導入前，庫存是一筆「永遠落後現實」的帳：人工同步有時差，超賣與假性缺貨輪流上演，倉管被綁在後台抄數字，補貨全憑印象。導入後，庫存變成一個由系統即時維護、各通路共用的單一真相來源，差異相當明顯：

• 超賣幾乎歸零：售出即時扣量、跨通路同步，顧客在任何平台看到的「有貨」都是真的有貨，因超賣產生的取消訂單與客訴可大幅下降，店家評分不再被無謂拉低。
• 可售量放大：不必再為了怕超賣而保守壓低各通路庫存，安全緩衝可以收得更精準，原本被白白藏起來的存貨重新上架販售，等於釋放出一段被埋沒的營收。
• 人力釋放：原本每天 1.5 到 2 小時的匯出、彙總、逐筆改數字，幾乎全數自動化，倉管與營運人員可省下約八成的庫存維護工時，改去處理補貨決策與供應商溝通等更有價值的事。
• 補貨更及時：低於安全水位自動預警並推播給採購，斷貨前就先補上，熱銷品不會在最會賣的時候掉鏈子。

效益會隨通路數、品項數與銷售波動而異，但方向一致：用自動化換到更準的庫存、更少的超賣、更高的可售率與更省的人力。

流程怎麼運作

整條流程對應 frontmatter 的五個節點，逐步說明如下：

1. 觸發：售出或排程（🛒）——流程有兩種啟動方式。一是事件觸發：任一通路成立訂單時，透過該平台的 Webhook 即時通知流程「某品項賣掉了幾件」；二是定時排程：每隔固定時間（例如每 5 到 15 分鐘）主動輪詢各通路的最新銷售與庫存狀態。實務上常兩者並用——Webhook 求即時、排程做兜底，確保沒有任何一筆銷售被漏掉。
2. AI 比對庫存（🧠）——這是流程的大腦。它把各通路回報的售出量、退貨入庫量、以及庫存資料庫裡的實際存貨彙整在一起，計算出每個品項當下真正的「可售庫存」。AI 在這裡的角色是處理通路間的差異與雜訊：例如各平台 SKU 命名不一致需要對應、同一筆訂單在 Webhook 與排程裡重複出現要去重、組合商品要拆算到單品庫存，這些靠單純減法容易出錯的比對，交給有判斷力的節點處理更穩。
3. 回寫各通路（🔁）——算出最新可售量後，流程透過各通路平台 API 把同一個數字回寫到所有平台，讓官網、蝦皮、momo 看到的庫存瞬間對齊。回寫時會帶上更新依據與時間戳，方便日後追查。
4. 低庫存預警（⚠️）——每次更新後比對安全水位，當某品項可售量低於預設門檻（可依品項銷速分別設定），自動標記為「待補貨」並產生補貨建議數量（參考近期銷速與進貨前置時間）。
5. 通知補貨（🔔）——把待補貨清單與建議補貨量透過 Slack 或 LINE 推播給倉儲與採購人員，讓補貨決策在斷貨發生前就被提醒，而不是等顧客下單買不到才發現。

需要的工具與串接重點

• 平台（n8n / Make）：流程引擎，負責接收觸發、跑比對、回寫各通路與發送通知。n8n 適合品項多、想自架掌握資料、需要複雜比對邏輯的賣家；Make 介面直覺、上手快，適合通路與品項規模還不大的團隊。
• 各通路平台 API：庫存同步的關鍵。串接前務必確認每個通路都提供「讀取銷售/庫存」與「回寫庫存」兩種能力，並留意各平台的 API 呼叫頻率限制（rate limit），高頻同步時要設計合理的批次與間隔避免被限流。
• AI 比對節點：處理 SKU 對應、訂單去重、組合品拆算等比對工作。重點是先建立一份各通路 SKU 與內部主檔的對照表，讓比對有明確依據。
• 庫存資料庫：作為唯一真相來源（single source of truth），所有通路的可售量都從這裡推算與回寫，避免讓某個通路後台變成事實上的主檔造成混亂。
• Google Sheet：適合中小規模當作輕量庫存主檔與人工抽查介面，方便非技術人員直接看數字、做盤點。
• Slack / LINE：補貨預警的推播管道，依團隊習慣選擇。

串接重點有三：一是先指定唯一主檔，所有同步都以庫存資料庫為準，單向回寫到各通路，切忌讓多個通路互為來源造成數字打架；二是SKU 對照表必須先建好且維護到位，新增商品或改料號時要同步更新對照，否則比對會錯位；三是回寫要有失敗重試與紀錄，某通路 API 一時失敗時能自動補寫，並留下變更軌跡供稽核。

常見錯誤與注意事項

• 上線初期務必人工抽查比對結果：庫存回寫直接牽動各通路的上下架與可售數量，一旦同步邏輯有誤（例如組合品拆算錯、SKU 對應錯），可能造成大量品項數字全錯、引發大規模超賣或全店誤下架。導入初期請先以人工抽查每日比對結果，確認同步邏輯無誤後再切換全自動，AI 不取代上線前的人工驗證。
• 避免重複扣量：當 Webhook 與排程並用時，同一筆訂單可能被算兩次。務必以訂單編號做去重，否則庫存會被多扣，造成假性缺貨。
• 退貨與取消要回補庫存：只扣不補的同步是半套。退貨入庫、訂單取消都要把對應數量加回可售量，否則可售庫存會越同步越少。
• 保留合理安全水位：完全把緩衝壓到零，遇到 API 延遲或瞬間爆單仍可能超賣。安全水位可以收緊，但不建議歸零，尤其是出貨前置時間長、補不及的品項。
• API 限流要納入設計：通路繁多、品項眾多時若一次猛打 API，容易被平台限流甚至暫時封鎖。回寫要分批、控速，避開各平台尖峰。

台灣中小企業情境案例

台南一家販售手工皮件與配件的品牌，同款商品同時上架官網、蝦皮與 momo 三個通路，主力錢包與皮帶常常一檔活動就被搶購。導入前，老闆娘每天早上第一件事就是登入三個後台、把昨天的銷售抄到 Excel、再回頭一個一個改各通路的庫存，一忙就是快兩個小時。即使這麼勤勞，還是三天兩頭超賣——蝦皮限時搶購把某款錢包賣掉最後幾件，官網卻還顯示有貨，顧客下了單、付了款，最後只能道歉退款，店家評分被連扣好幾次。

導入這條流程後，三個通路任一筆銷售都即時觸發同步，系統用統一的庫存主檔算出真實可售量、回寫到全部通路，官網、蝦皮、momo 看到的數字永遠一致。上線前兩週老闆娘維持每天早晚各抽查一次比對結果，確認沒有任何品項對錯後才放手全自動。結果是超賣幾乎不再發生，因為不用再保守壓低庫存，原本被藏起來怕超賣的存貨重新放上來賣，可售率提升；而當主力皮帶的可售量低於安全水位時，LINE 會自動跳出補貨提醒與建議數量，她在斷貨前就先請師傅備料。原本每天近兩小時的抄數字工作，縮到只剩偶爾的抽查與補貨決策，省下的時間全拿去做新品設計與經營社群。

延伸應用

這條流程可以再往外擴充。庫存資料一旦集中且即時，就能延伸出更多應用：把累積的銷售與庫存數據導出，分析各品項的真實銷速與週轉率，作為下一季備貨與選品的依據；對長期滯銷、佔倉的品項自動標記，觸發清倉或組合促銷；也可以把安全水位設成動態——旺季自動提高緩衝、淡季收緊，讓資金不被壓在過多庫存上。想做更完整的營運閉環，可把它接到 電商訂單處理工作流 形成從售出、扣量到補貨的串接，搭配 數據報表配方 掌握熱銷與滯銷品，並透過 自動化中心 統一管理同步頻率、安全水位與各通路 API 設定，讓整套多通路庫存越跑越準、越省人力。

流程圖

用到的工具

更多「零售商店」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →