一份多店铺运营流程搭建教程：开单、库存、履约如何串起来

三店同促，库存池显示 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 就先用统一工作台把接口跑稳，别为了"一步到位"多付一倍年费。多账号环境隔离的完整判据和操作日志字段，可参考多账号管理专区。