一份多店舖營運流程搭建教程：開單、庫存、履約如何串起來

三店同促，庫存池顯示 200 件。A 店鎖了 120，B 店鎖了 120，C 店揀貨時發現可發只剩 56 件，時效倒數計時已經跑進第四小時。這不是「庫存不準」，而是開單、庫存、履約三個環節之間的交接介面沒有顯式定義——誰扣、誰放、誰兜底，全靠口頭和感覺。把交接介面拉成字段級契約，是多店舖營運流程搭建的核心動作。下面按「開單→庫存→履約」的流向，逐個介面給出最小字段集、觸發條件和超時升級路徑，最後按 SKU 規模和日單量匹配工具檔位。

開單到庫存：把「誰扣、誰放、誰兜底」寫成字段契約

開單和庫存之間最容易出問題的，不是「沒連上」，而是連上了但字段對不齊。最小交接字段集只有五個：SKU、店舖 ID、數量、SLA 截止時間、訂單狀態。訂單側在生成時把店舖 ID 和 SLA 截止時間一併寫入庫存扣減請求；庫存側只認這五個字段，不認「哪個平台、哪個活動」——那些是開單側的事。

庫存釋放的觸發條件必須顯式列出來，否則就是「殭屍鎖」：超時未揀（預設 2 小時）、買家取消、退貨入庫。每個觸發條件綁定一個庫存狀態變更（已鎖→可用），並寫回訂單狀態字段。超賣兜底責任人按店舖 ID 歸屬——誰鎖的誰兜，跨店占用超過 15 分鐘未釋放的，升級至庫存管理員而非當班揀貨員。

如果同步日誌全綠但對帳差出十幾件，問題大概率不在腳本本身，而在欄位映射、時序競態或平台規則層。逐層排查的判據和最小修復動作見介面沒報錯但庫存對不上：多店鋪庫存同步失敗的 4 層排查思路。

庫存到履約：把時效承諾拆成三個可檢查節點

"發出去就完了"是多店履約最常見的認知偏差。時效承諾不是物流簽收那一刻才生效，它從庫存狀態變為"已鎖"就開始倒數計時。把承諾拆成三個節點，每個節點綁定庫存狀態變更和檢查窗口：

1. 揀貨確認（庫存：已鎖→已扣）。檢查窗口 30 分鐘。判斷標準：揀貨單掃碼成功且數量與訂單一致。異常：超 30 分鐘未掃碼，系統提醒當班揀貨員；超 1 小時未處理，升級至倉管負責人並釋放該 SKU 回可用池。
2. 打包完成（庫存：已扣→已出庫）。檢查窗口 2 小時。判斷標準：面單打印且包裹稱重通過。異常：超 2 小時未打面單，檢查是否缺輔料或地址異常；超時自動釋放庫存並標記訂單為"待補打"。
3. 攬收簽收（庫存：已出庫→已釋放）。檢查窗口 4 小時（同城）或 8 小時（跨城）。判斷標準：物流商掃描攬收。異常：超時未攬收，觸發物流商超時罰則並回滾庫存狀態為"已扣"，等待二次攬收或走退貨流程。

每個節點的檢查窗口不是「建議」，是系統告警閾值。窗口值按實際倉配能力設，但必須寫進 SOP 並綁定責任人——否則超時了沒人接，庫存就停在「已鎖」變成殭屍數據。多平台多店铺的訂單、庫存、消息集中收口邏輯，詳見把訂單、庫存和消息集中處理，多平台商店怎麼統一管理。

工具檔位：SKU 數量與日單量決定你該用哪一層

流程跑通之後，工具選型的核心判斷不是「功能多不多」，而是你的庫存規模和日訂單量夠不夠得著下一檔。按 SKU 總數、日均訂單量、在運營平台數三個硬指標對照：

選型時別被功能清單牽著走。先將三個硬指標算清楚，再對照多店鋪管理工具怎麼挑？按庫存規模和日訂單量選對方案比堆功能更重要裡的能力邊界，確認自己卡在哪個檔位、升級後能解掉哪三個具體問題。夠不上 ERP 就先用統一工作台把接口跑穩，別為了「一步到位」多付一倍年費。多帳號環境隔離的完整判據和操作日誌欄位，可參考多帳號管理專區。