多通路價格庫存同步流

🎯 這條流程解決什麼

只要你在兩個以上的通路賣東西，價格和庫存的同步就是一場永遠打不完的仗。同一款商品同時掛在官網、蝦皮、momo、Line 購物，每個平台都有自己的後台。今天進貨成本漲了要調價，你得登入每一個平台、找到那支商品、一個一個改；某個爆款剩最後三件，你得趕在每個通路都賣超之前把庫存改對。漏改一個通路，後果不是標錯價被顧客截圖客訴、就是超賣後被迫取消訂單、被平台扣信用分。

現在純人工做要付出多少代價？假設一間店有三百支 SKU、掛在四個通路，光是要把一次全面調價同步到所有平台，逐站逐品手動改下來，沒有一整個工作天根本做不完，而且改到後面眼睛都花了，錯誤率直線上升。更現實的是日常的庫存波動：每一筆訂單成立，理論上四個通路的庫存都該即時同步扣減，人工根本不可能跟得上，於是大家只能靠「保守留庫存」這種笨辦法——每個通路都只敢放實際庫存的一部分，結果就是熱賣商品在 A 通路顯示缺貨、其實倉庫還有貨堆在 B 通路的額度裡賣不掉，白白損失營收。

這條流程以一份商品主檔當作「唯一真相來源」，任何價格或庫存的異動，自動推送到所有通路。系統比對各通路現值、只更新真正有差異的品項，庫存低於安全量時主動告警甚至自動下架避免超賣，每一筆同步成功或失敗都逐筆留痕供稽核。旺季調價、補貨、清庫存，再也不用一站一站手忙腳亂。更多電商營運自動化的搭配，可以先看 自動化專區。

導入後的改變

導入前，多通路經營的真相是「永遠有某個通路的資料是錯的」，只是你還沒發現而已。價格不同步導致同一商品在不同平台不同價，顧客比價後覺得被當盤子；庫存不同步導致超賣，被迫向顧客道歉取消訂單，平台評分跟著掉。營運人員每天花大把時間在各後台之間來回核對，做的卻是毫無產值的搬資料工作。

導入後，主檔成為單一控制台，改一個地方、全通路同步。效益估算上，原本一次全面調價要耗掉近一整天的人工，壓縮到幾分鐘自動完成，相關工時可省下八成以上。超賣事故因為庫存即時同步而大幅下降，常見可從每月數起降到趨近於零，省下的不只是道歉的時間，還有被平台扣分、影響曝光的隱形損失。庫存利用率也提升：因為不再需要「保守留庫存」，每個通路都能放到接近實際可售量，熱賣商品不再假性缺貨，等於用同樣的庫存賣出更多訂單。對營運人員來說，最大的改變是終於可以把腦力花在選品、定價策略這些真正重要的事，而不是當人肉同步機器。

流程怎麼運作

第一步・觸發主檔更新。 當商品主檔（Google Sheet 或 ERP）的價格或庫存欄位有變動，透過 Webhook 即時觸發；若主檔系統不支援推送，就用排程定時掃描主檔、找出有異動的列。每一筆訂單成立也會回頭扣減主檔庫存，讓主檔永遠是最新的真相。

第二步・計算差異。 系統不會無腦把全部商品重推一遍，而是先讀取各通路目前的價格與庫存，和主檔比對，只挑出真正有差異的品項。這一步能大幅減少 API 呼叫量，避免觸發平台的流量限制，也讓同步更快。

第三步・推送各通路。 針對需要更新的品項，分別呼叫蝦皮、官網、momo 等通路的 API，更新價格與庫存。每個平台的 API 規格與商品對應 ID 不同，流程裡用對應表把主檔 SKU 映射到各通路的商品編號。

第四步・庫存告警。 當某商品庫存低於預設的安全量，系統自動發出告警通知，提醒補貨；若已歸零，則可設定自動在各通路下架，從根本杜絕超賣。

第五步・同步紀錄。 每一筆同步動作，無論成功或失敗，都逐筆寫入紀錄表，包含時間、品項、通路、結果與失敗原因，供事後稽核與排錯。

需要的工具與串接重點

平台用 n8n 或 Make 搭建。商品主檔可以是 Google Sheet（小規模）或 ERP 系統（規模較大），它是整套流程的核心，所有資料以它為準。各通路 API（蝦皮、官網平台、momo 等）負責實際更新，事前要申請好串接權限與金鑰。排程模組負責定時掃描與差異比對。Line 或 Email 則是庫存告警與失敗通知的通道。

串接重點有三：一是務必建好 SKU 對應表，主檔的一支商品要能正確對應到每個通路的商品 ID，對錯就會改錯商品；二是各平台多半有 API 呼叫頻率限制，要做好批次與節流，避免被擋；三是同步一定要「先比對差異再推送」，全量重推不但慢、還容易踩到流量上限。

常見錯誤與注意事項

串接各通路 API 一律使用最小權限金鑰並妥善保管，避免外洩造成商品被惡意竄改。最高風險的兩個操作是「大幅調價」和「批次下架」：一個價格欄位多打或少打一個零，自動同步出去就是全通路一起標錯價，可能造成真實的金流損失；批次下架若邏輯誤判，會讓正常在賣的商品突然全部消失。因此這兩類操作強烈建議先進審核佇列，由人工確認異動清單無誤後再推送，這種直接牽動售價與上架狀態的環節需人工把關，不可全交給自動化裸跑。另外，價格涉及促銷活動、平台抽成與毛利計算，定價策略本身是專業判斷，AI 或自動化只負責「忠實同步主檔」，不應自行運算或調整售價。同步失敗的品項一定要有告警與重試，不能默默漏掉造成資料長期不一致。

台灣中小企業情境案例

台南一間賣手工皮件的工作室，商品同時掛在官網、蝦皮和一個寄賣的選物平台。導入前，老闆娘最怕的就是熱賣的卡夾——同一款只做得出有限數量，三個通路各自顯示庫存，常常蝦皮和官網同時各賣出一個，實際只剩一個，只好硬著頭皮跟其中一位顧客道歉退款，對方氣到給了負評。調價更是惡夢，皮料成本漲價要全面調整售價，她得熬一整晚逐站逐款改。導入這條同步流程後，她只改一份主檔，價格和庫存自動推到三個通路；某款剩最後一件時，賣出的瞬間其他通路同步歸零下架，超賣從此沒再發生。一次皮料漲價的全面調價，從熬夜一整晚變成喝杯咖啡的時間，她說最有感的是「終於敢把庫存全部放出來賣，不用再每個通路藏一點」。

延伸應用

這條流程的架構可以往幾個方向擴充。把「庫存同步」延伸成「自動補貨建議」，當庫存低於安全量時，不只告警，還能依過往銷售速度推算建議補貨量。把「價格同步」延伸成「動態定價」分支（務必保留人工審核），依各通路的競品價格與庫存水位給出調價建議。也能接上前面的出貨流程，讓每一筆出貨即時回扣主檔庫存，形成「賣出—扣庫存—同步全通路」的完整閉環。想把選品、定價、庫存、出貨串成一整套多通路營運系統，可以逛逛 任務食譜 與 工作流總覽，依自己的通路數與規模挑模組組裝。

流程圖

用到的工具

更多「零售商店」工作流

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