把定價從逐店手動改成規則驅動：多店鋪價格統一管理方法實操拆解

大促第三天，同一個 SKU 在 TikTok Shop 標價 79 元、Shopify 獨立站 69 元、Lazada 馬來站摺合 85 元。買家截圖比價發到社交媒體，客服逐店登入後台改價，四幾十分鐘才把三家對齊。問題不在人手不夠，而是沒有一個共同的規則源——每改一次價，人腦都要重新算採購價、平台費率、促銷疊加，換個人就換個數。如果你同時運營 2 家店鋪以上且日均訂單過百，逐店手動改價已經是隱性成本最高的操作之一。

逐店手動改價兜不住的三個失效點

• 成本核算靠記憶。採購價上週更新了，但三家店的底價係數沒有同步刷新，Lazada 那家還在按舊成本跑促銷。
• 促銷疊加沒有上限。Lazada 滿減、平台券、店鋪券三層疊完，實際售價跌破成本線，但沒有人提前算過總折扣能疊到哪。
• 改價無留痕。誰改的、從多少改到多少、觸發原因是什麼，全靠翻聊天記錄，出糾紛時說不清。

這三個失效點指向同一件事：判斷邏輯散落在每個人腦子裡，沒有變成可執行的規則欄位。要解決的不是「多一個人盯價」，而是把判斷寫成規則讓系統跑。

三層規則各自寫什麼：核算、執行、異常

把定價拆成三條規則鏈，每層只解決一個問題，層與層透過 SKU 主鍵和渠道 ID 關聯。

核算層（定成本底線）

必填欄位：SKU 採購價、平台佣金率、物流均攤成本、渠道係數（例如 TikTok Shop 係數 1.0，Shopify 係數 1.15）。輸出公式：該 SKU 在該渠道的最低售價 =（採購價 + 物流均攤）÷（1 − 佣金率）× 渠道係數。這一層只做一件事：算出「不能低於多少」，不碰促銷決策。

執行層（各店定價公式）

必填欄位：核算層底價、促銷疊加上限（如 Lazada 滿減+券總折扣不超過 35%）、生效時間視窗。輸出各店實際售價，系統自動校驗是否低於核算層底線，低於則攔截並推送告警。關於 Lazada 促銷疊加上限的具體數值與衝突處理，可對照多站點價格與促銷節奏一文中的處理順序。

異常層（衝突與越權）

必填欄位：觸發規則 ID、操作人、原值、新值。越權改價自動攔截並推送通知；兩條規則同時命中時按優先級取高，低優先級規則標記為「已覆蓋」而非刪除。

兩條規則同時命中怎麼辦：衝突順序與改價留痕

實操中最常遇到的「規則打架」：促銷規則說「全場 8 折」，核算層底線說「這個 SKU 最低不能低於 72 元」。處理原則按不可逆程度排序——已扣庫存 > 已改價 > 僅標記。庫存一旦扣減不可自動回退，改價可回滾，標記可隨時清除。衝突時先保留高不可逆規則的結果，低不可逆規則標記為「已覆蓋」。

這套衝突順序在 Shopee 多店鋪大促場景中尤其高發，如果你正在搭大促分單邏輯，可對照大促訂單暴增時如何用規則減少漏發中的認領與庫存兩條鏈。

什麼時候切規則驅動，什麼時候還該手動

判斷線很具體：SKU 總數低於 100 且商店 ≤ 2 家，用帶公式的共享表格加人工維護就夠了，規則引擎的建置成本高於它省下的時間。SKU 到 200 以上、商店 ≥ 3 家、日均訂單過 100，手動維護的出錯率開始超過規則維護成本，這時候把核算層和執行層寫進系統。不要一上來就搭全套三層——先把核算層跑通（一張共享成本表加渠道係數列），執行層跟著上，異常層等你真的被「規則打架」卡住再補。切換節奏參考多店營運從單店到多店的階段任務，避免在 2 家店時就上 6 家店的工具。

如果你已經在用多平台統一管理工作台處理訂單和庫存，規則引擎可以直接掛在同一套欄位上，不需要另起一套系統。