去年秋天，我帮一个做家居品类的卖家做库存复盘。他手上有五个店铺：两个亚马逊站点、一个独立站、一个东南亚平台店、一个跨境分销渠道。系统里拉出来的账面库存是 187 万元，但当我让他把”能在 72 小时内发出、且是良品、且没有被其他店铺的促销活动锁定”的货单独算一遍时，这个数字变成了 96 万元。有将近一半的库存，在账面存在，在经营上不可用。
这不是个例。在我接触过的多店卖家里，“库存计划”和”多店经营”是两套人马、两张表、两个 KPI 的情况非常普遍。库存计划由供应链或财务负责，看的是总周转天数；多店经营由运营负责，看的是每个店铺的断货率和滞销率。两张表各自都”没错”，但合在一起就对不上。
这篇文章想解决的问题很具体：当你同时经营三个以上店铺、共享同一个供应链和同一批货的时候，库存计划该怎么定，才能让每个店铺既不饿死也不撑死。我会给出可以落地的模型、判断逻辑、真实数据观察，以及不同规模卖家该做的取舍。
我把话说在前面，这一节是全文的骨架，后面所有内容都是在展开它。
结论一：库存计划的对象是”SKU + 库存池”，不是”SKU + 店铺”。只要你承认多个店铺可以从同一个仓库、同一批采购里发货，那么按店铺独立做安全库存，数学上就是错的，因为它把共享的缓冲重复计算了三次或五次。
结论二：多店经营的核心动作不是”各店自己补货”，而是”分配”。补货解决的是”总量够不够”，分配解决的是”这点量给谁”。绝大多数多店卖家在总量上其实做得不差，真正亏钱亏在分配上，A 店断货的同时 B 店在清仓。
结论三：衔接这两个动作的最小可行结构是”一个库存池 + 三条规则”。三条规则分别是分层补货规则、调拨优先级规则、清库存分工规则。少了任何一条，库存计划都会在多店经营面前失效。
我用一个最简单的算术说明这件事。假设你有一个 SKU，三个店铺的日销量分别是 20、10、5 单，采购提前期 30 天，你给每个店铺按照”提前期需求 + 20% 安全库存”来备货。
那么三家店分别需要备 720、360、180 件，合计 1260 件。但如果把三个店铺看成一个整体，总日销 35 单，提前期总需求 1050 件，加 20% 安全库存是 1260 件，数字看起来一样，可风险完全不同。
因为前一种算法里，A 店多出来的 120 件安全库存不能救 B 店的缺货，B 店的 60 件也救不了 A 店。而后一种算法里，这 210 件安全库存是可以互相调剂的共享缓冲。同样的资金，后者能扛住的销量波动幅度，实测大约是前者的 1.6 到 2.2 倍。
这就是撕裂的根源：按店铺做计划，等于把同一份风险准备金买了三遍，而且每一遍都不够用。
如果你想立刻改，不需要上系统，先在表格里做三件事：
第三步是 90% 的卖家缺失的部分。而它恰恰是把库存计划和多店经营真正缝在一起的那根线。
我见过太多卖家把问题归结为”数据不准”。但绝大多数时候数据是准的，乱的是口径。
第一类，起步型多店卖家（2-3 店，月销 5-20 万）。典型特征是老板一个人用 Excel 管库存，各店库存靠”我记得 A 店还有两百个”。这类卖家的问题不是计划不精，而是根本没有计划，全靠记忆和感觉。
第二类，成长期卖家（4-8 店，月销 20-200 万）。有了专职供应链，也开始用工具，但工具是分着的：ERP 管采购和总库存，平台后台管各店可售，广告后台管投放。三套数据各说各话，每次补货决策都要人工拼表。这是最痛的一层，也是本文重点针对的层。
第三类，矩阵型卖家（10 店以上，多站点多平台）。已经有海外仓和本地履约，库存分布在多个物理节点上，问题从”算不清”变成”调不动”。这类卖家的核心矛盾是调拨成本和缺货损失之间的平衡。
我记录过一个 5 人运营团队的一天。上午 9 点半，亚马逊运营发现主力 SKU 可售天数只剩 11 天，在群里喊补货。10 点，供应链回复”总仓还有 800 件，够卖 40 天，不用补”。
11 点，独立站运营说要做促销，想拿 200 件。供应链说这 800 件里有 300 件已经被东南亚店的活动占用了。下午 2 点，东南亚店说活动效果不好，只出掉 60 件，剩下 240 件要退回总仓。
下午 4 点，所有人重新对一次数，发现这 800 件里真正的自由库存只有 260 件。一天下来，没有一个动作是错的，但加起来就是：一个店铺在缺货，另一个店铺在退货，而中间的时间全花在对数上。
这个场景的本质，是缺少一个实时口径的”可分配库存”。账面库存是静态的，可分配库存是动态的，多店经营需要的是后者。
回到开头那个案例。我们花了三天把五个店铺的库存拆成了六类：正常在售、活动预占、在途未到、退货待检、滞销待清、残次品。结果如下。
| 库存状态 | 金额（万元） | 占比 | 是否可立即分配 |
|---|---|---|---|
| 正常在售 | 96.2 | 51.4% | 是 |
| 活动预占 | 24.8 | 13.3% | 否 |
| 在途未到 | 29.1 | 15.6% | 否 |
| 退货待检 | 11.4 | 6.1% | 否 |
| 滞销待清 | 19.6 | 10.5% | 是（但需折价） |
| 残次品 | 5.9 | 3.1% | 否 |
真正值得关注的是”滞销待清”这 19.6 万。它占用了资金，但在库存周转率的计算公式里，它和正常库存是混在一起的，所以从总周转天数上完全看不出来问题。
我们把口径改成”可分配库存周转天数”之后，这个 SKU 池的真实周转从 96 天变成了 132 天。总口径掩盖了 36 天的真实压力，而这 36 天恰好就是多店经营该去处理的部分。
这一节列的五个误区，是我在至少三十家卖家的复盘里反复见到的。它们不是能力问题，而是结构问题。
这是最普遍也最贵的一个。安全库存的本质是”对抗不确定性”，而不确定性的来源是销量波动和提前期波动。
当三个店铺共享同一个采购批次和同一个仓库时，它们的销量波动会部分互相抵消，A 店卖爆的同时 B 店可能正好滞销。合并计算之后，需要的安全库存比例通常能下降 25% 到 40%。
按店铺独立设置，等于主动放弃了这个抵消效应。我见过的极端情况是，一个卖家在同一个 SKU 上，五个店铺各自压了相当于 18 天销量的安全库存，合计 90 天，而实际需要的共享缓冲不到 30 天。
总周转率是个平均数，而平均数在多店场景里是最没用的指标。它会让一个健康店铺和一个重度滞销店铺互相掩盖。
更麻烦的是，总周转率会掩盖结构性问题。一个卖家总周转 68 天，听起来不错，但拆开看是：两个店 32 天（缺货边缘），一个店 180 天（滞销）。总数字好看，实际上一半的店在流血。
正确的做法是双层指标：上层看库存池的总周转和总资金占用，下层看每个店铺的”可分配库存覆盖天数”和”滞销金额占比”。两层必须同时看。
补货点的标准公式是”提前期日均需求 + 安全库存”。但在多店场景里，提前期不是一个数字，而是一个分布。
同样是 30 天的采购提前期，如果供应商有 15% 的概率延误到 45 天，那么你在第 30 天到第 45 天之间的这段时间，实际上是在用共享安全库存硬扛。这时候如果三个店铺同时补货，安全库存会在同一周被击穿。
我的建议是：把”在途量”作为补货点计算的一等公民，而不是事后扣减。补货点应该基于”可用 + 在途”的总覆盖天数触发，而不是基于账面可用库存触发。
清库存最贵的不是折扣，是决策延迟。我见过一个卖家，一批 400 件的过季品，从发现滞销到真正降价清掉，花了 71 天。
这 71 天里发生的动作是：运营提报 → 主管审批 → 财务核价 → 各店分别设折扣 → 观察两周 → 再降。每一步都不算长，加起来就是两个月，而两个月的仓储成本加上最终的清仓折扣，让这批货的毛利率从 38% 变成了 -6%。
多店场景下，清库存慢的另一个原因是”比价”。五个店都要看别人卖多少，谁都不愿意先降。这件事应该由规则解决，而不是由人协调解决。
这是我最后想说、也是最重要的一条。很多公司把库存计划放在财务或供应链部门，按季度或月度做一次。但多店经营的变量是按天变的。
一个店铺今天开始投广告、明天参加平台活动、后天改价，这些动作都会在 3 到 7 天内改变销量曲线。如果库存计划一个月才更新一次，那它不是计划，是历史记录。
库存计划必须是一个高频的、被运营动作实时影响的运营动作，而不是一个低频的财务动作。这不是说要每天重算安全库存，而是说分配规则要能以天为单位响应。
下面这四个接口，是我在实际项目里总结出来的框架。如果只记一件事，请记住：这四个接口都要有明确的、写下来的规则。
ATP 是这个框架的地基。我的定义是：ATP = 良品现货 − 已确认订单占用 − 活动硬预占 − 质量待检 − 已在途但已被他店计划的量。
因为活动预占一旦生效，这批货在物理上还在仓里，在经营上已经不属于自由库存了。如果不扣，就会出现”每个店都以为自己有货”的经典事故。
这是多店场景特有的坑。一批 500 件的在途货，A 店已经按它排了上架计划，B 店如果不知道，就会重复计算一次，最后到货时两边都不够。
我的建议是：T+0 按小时刷新，用于日常调拨和活动报名；T+1 按天刷新，用于补货点判断；T+7 按周刷新，用于总量采购决策。三个频率对应三类决策，不要混用。
不是所有 SKU 都值得精细管理。我的分法是按”销量贡献 + 销量波动”分成四层，每层用不同的补货逻辑。
| 层级 | 特征 | 补货方式 | 安全库存系数 | 复盘频率 |
|---|---|---|---|---|
| A 层（爆款稳定） | 贡献 60% 销量，波动 <30% | 自动补货，固定周期 | 1.15-1.25 | 每周 |
| B 层（成长款） | 贡献 25% 销量，波动 30-70% | 半自动，人工确认 | 1.3-1.5 | 每两周 |
| C 层（长尾款） | 贡献 12% 销量，波动大 | 小批量高频补 | 1.5-1.8 | 每月 |
| D 层（测试/尾货） | 贡献 3% 销量 | 不补，售完即止 | 不设 | 每季度清理 |
这张表的价值在于：它让你把管理精力从”所有 SKU 平均用力”变成”把 60% 的精力放在 A 层和 B 层”。我见过太多卖家在 D 层 SKU 上花的时间和 A 层一样多，结果 A 层断货、D 层积压。
这是多店经营和库存计划真正缝合的地方。当可分配库存不足以满足所有店铺时，谁先拿？
这是最常见的默认规则，也是最差的。它奖励嗓门大的人，惩罚老实做计划的人，长期结果是所有运营都学会提前喊、超量喊。
我推荐的排序逻辑是：先保”贡献毛利额最高的店铺”，再保”可售天数最低的店铺”，最后才考虑”补货成本最低的店铺”。
具体算法可以简化为一个排序分数：单件毛利 × 近 14 天日均销量 ÷ 当前可售天数。分数越高，优先级越高。这个公式的好处是它同时考虑了赚钱能力和紧迫程度。
任何纯算法规则都会在特殊情况下犯错。所以我会建议留 10%-15% 的库存不进入自动分配，由运营负责人手动处置，用于应对突发的平台活动或大客户订单。
清库存的关键不是降价幅度，而是”哪个渠道承担什么角色”。我的做法是给不同店铺分配不同的清货职能。
把清货职能明确分配到不同店铺之后，你会发现清货决策的速度会明显提升，因为不需要再讨论”要不要在主店降价”这个伤筋动骨的问题了。
前面讲的是逻辑，这一节讲怎么落地。我拿一个实际用过的工具来举例说明具体操作，这样比抽象讲模型更有参考价值。
我先说清楚选择的理由。这个案例的核心需求是三件事：把多店铺 SKU 归并到一个主库存池、按统一口径算可分配库存、把补货和调拨建议按规则输出。
数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）在这三件事上的处理方式比较贴合我前面讲的框架。它的思路不是”给每个店铺单独算一套库存指标”，而是先做商品和库存的口径统一，再在这个统一口径上做补货和分配建议。
我把这个思路概括成一句话：它先解决”数据是不是同一个口径”，再解决”该不该补货”。这个顺序是对的，因为顺序反了的话，再准的算法也是在错的口径上算。
这是整个流程里最脏最累但最有价值的一步。我的做法是先建一张主 SKU 映射表，字段包括主 SKU 编码、店铺、店铺 SKU、平台、是否共享库存、优先级权重。
主SKU编码,店铺,店铺SKU,平台,共享库存,优先级权重
HOME-001,A店,AMZ-B0XXXX,亚马逊US,是,0.35
HOME-001,B店,AMZ-B0YYYY,亚马逊DE,是,0.25
HOME-001,独立站,SHOP-1001,自建站,是,0.20
HOME-001,东南亚店,SP-2201,东南亚平台,是,0.15
HOME-001,分销渠道,DS-3301,分销,是,0.05
优先级权重不是拍脑袋定的，应该由近 90 天的毛利贡献占比反推。这个权重的用途是：当 ATP 不足时，按权重决定分配顺序。
这张表建好之后，你会发现一个立竿见影的变化，所有关于”这个 SKU 到底还剩多少”的争论会瞬间消失，因为大家看的是同一行数据。
在口径统一之后，可分配库存的计算就可以写成一段明确的逻辑。我用伪代码表示，方便你和自己的系统对照。
def calculate_atp(master_sku):
spot = get_good_inventory(master_sku) # 良品现货
confirmed = get_confirmed_orders(master_sku) # 已确认未发货订单
locked = get_campaign_lock(master_sku) # 活动硬预占
inspection = get_qc_pending(master_sku) # 质量待检
pledged = get_planned_inbound_flag(master_sku) # 在途已被他店计划的量
atp = spot - confirmed - locked - inspection - pledged
return max(atp, 0)
每个店铺的可售天数 = 该店可分配到的量 / 该店近14天日均销量
def allocatable_days(store, master_sku, atp):
weight = get_priority_weight(master_sku, store)
allocated = atp * weight
daily_sales = get_avg_daily_sales(store, master_sku, days=14)
return allocated / daily_sales if daily_sales else float('inf')这段逻辑的价值在于它把”共享”这件事显式化了。每个店铺拿到的不是”仓库里所有的货”，而是”按权重应该分到的货”。这是多店库存管理里最关键的一次认知转换。
补货和调拨是两件事，必须分开跑，否则会互相打架。我的处理顺序是：先判断总量是否要补货，再判断现有库存是否要调拨。
补货触发条件是：（ATP + 在途）/ 库存池整体日均销量 < 提前期 + 安全天数。注意分母是库存池整体日均销量，不是单店销量。这一点是很多工具和个人表格做错的地方。
调拨触发条件是：某店可售天数 < 门槛值，且另一店可售天数 > 门槛值的 2 倍，且调拨成本 < 预计缺货损失。
把这两个条件写成规则之后，每天早上的运营会从”对数吵架”变成”看建议清单确认”，这是我在实际项目里感受到的最大变化。
这个卖家从 5 月开始做上述改造，我记录了改造前（4 月）和改造后（7 月）的关键数据。
需要说明的是，这些数据来自一个中型卖家的实际记录，样本量为 1，不能当作行业基准。但它反映的趋势，缺货率和人工耗时先改善，资金占用最后改善，在我后续的复盘里一再出现。
原因不难理解：缺货和人工耗时是流程问题，改口径就能改；而资金占用是物理问题，要等已经买进来的货慢慢卖掉才能改善。
同样是多店库存衔接，不同体量的卖家该做的事情完全不同。下面按四类情况给建议。
这个阶段不要上任何复杂模型，你真正需要的是”不要再买错货”。
这四件事用一张表就能完成，不需要工具。做完之后，你的缺货率通常能降三分之一。
这是最需要系统化的一层。核心矛盾是数据源太多、口径不统一。
这个阶段我的经验是：改造周期 6-10 周，投入产出比最高的不是算法，而是口径统一和数据录入的规范化。
这个阶段的问题从”算不清”升级为”调不动”，重点转向物理节点的布局和成本平衡。
这一层最容易被忽略的是跨池调拨的隐性成本。一次跨洲调拨的单位成本，通常是本地仓间调拨的 8-15 倍，这个数字必须进入调拨决策公式。
如果你的 SKU 数量在 2000 以上，上面所有按 SKU 精细管理的方法都会失效，因为你根本没有那么多人力。
这类卖家的正确做法是反向操作：先按类目和供应商分组，再在组内做库存计划。同一供应商、同一类目、同一价格带的 SKU，其销量波动有很强的相关性，可以整组设置安全库存。
我一贯的观点是：SKU 数量超过 2000 的卖家，管理颗粒度应该从 SKU 降到”品类 + 供应商”，否则管理成本会吃掉全部利润。
任何方法都有代价。这一节讲清楚在哪些地方你必须做选择，以及我建议怎么选。
集中库存的好处是共享缓冲，坏处是履约时效变长、跨区运费变高。分散库存反过来。
我的判断标准是：如果某个区域的销量占比稳定超过 25%，且客单价高于 30 美元，就值得设独立库存池；否则应该集中。因为低于这个门槛时，独立池带来的时效收益覆盖不了重复安全库存的成本。
高频小批量补货能降低缺货和滞销风险，但物流成本会明显上升。这两者的平衡点在哪里，取决于你的毛利率。
按上图的模拟数据，月度补货 4-6 次是多数毛利率在 30%-45% 区间的卖家的最优区间。超过 8 次之后，物流成本的边际增长会超过缺货损失的边际减少。
统一价格能保护品牌和 Review 曲线，但会浪费不同渠道的流量特性。差异化定价能最大化每个渠道的产出，但有价格穿帮风险。
我的建议是：主力店铺和独立站保持价格一致，新兴平台店和分销渠道允许 10%-20% 的价差，但必须用不同的型号或套装做区隔。同款同型号在不同渠道卖不同价，长期一定会出问题。
这是个纯算术问题，但很多人算错了。算错的原因是只算了工具的订阅费，没算不买工具时的隐性成本。
隐性成本包括：对账人工时间、因缺货损失的销售额、因滞销占用的资金成本、因决策延迟造成的折扣加深。这几项加起来，通常远高于工具费用。
我的经验阈值是：当多店库存相关的每周人工耗时超过 12 小时，或者年库存规模超过 200 万元时，工具投入几乎总是划算的。
这是库存管理永恒的矛盾。我的取向是：在毛利率高于 35% 的品类上，宁可略微超储，也不要缺货；在毛利率低于 20% 的品类上，宁可偶尔缺货，也不要积压。
原因很简单。高毛利品类缺货一次，损失的是排名、Review 增长和未来几个月的自然流量，代价远高于多备一点货的仓储成本。低毛利品类反过来，积压一次可能直接吃掉三批货的利润。
方法讲完了，最后讲节奏。我见过太多卖家把库存管理体系做成一次性项目，做完就放在那里。它应该是循环。
每日动作的原则是：只处理异常，不处理常规。如果每天要看 100 条，说明规则设置得太宽松，需要重新调阈值。
每周动作里最重要的是第二条。权重如果三个月不更新，规则就会慢慢偏向原来的结构，最终失真。
如果你是第一次做这件事，下面这组阈值可以直接用，再根据自己的数据微调。
这组数字不是标准答案，但它是一个能跑起来的起点。先跑起来，再根据实际缺货率和滞销率的反馈微调，比一开始就追求精确参数要有用得多。
回到最开始那个 187 万账面库存、96 万可用库存的案例。改造完成之后，这个卖家跟我说了一句话，我觉得很准确：“以前我以为我在管库存，其实我是在管五个人怎么吵架；现在我知道我在管一件事，这点货该给谁。”
这句话点出了整篇文章的核心。库存计划解决的是”要买多少”，多店经营解决的是”给谁卖”，而衔接它们的，是分配规则。规则清晰，库存计划才有意义；规则模糊，再精确的预测也落不了地。
我的独特判断有三条，值得重复一遍：
如果你的下一步是要动手，我建议按这个顺序来：先用一到两天把主 SKU 映射表建好，然后用一周时间把可分配库存的口径统一，再用两周把调拨优先级规则写下来并试运行。工具可以在这个过程中同步选型，但不要等工具上线才开始整理口径，那样会浪费大量时间在等待上。
库存计划的水平，往往不体现在预测有多准，而体现在多店之间分配得有多顺。这件事做对了，你会发现缺货和滞销不是两个需要分别解决的问题，而是同一个问题的两个面。
读者评论
我们做亚马逊加独立站，共享库存理论上对，但落到FBA就卡住了。FBA里的货没法直接调给独立站，海外仓和国内仓时效差很多。文章说的库存池我理解，可物理位置和平台政策不打通，共享安全库存只能算半个池子。想听听多节点下具体怎么设分配优先级。
共享安全库存能降25%到40%这个数，我持保留意见。我们做服装，季节性很强，几个店经常同时爆或同时滞，波动并不抵消。合并后安全库存是降了，但一旦判断错趋势，缺货更集中。这个比例可能因品类差异很大，最好别当通用结论。
小卖家看完最大感受是，主SKU映射表听着简单，实际SKU一多、平台改一次编码就乱。我们之前也想做库存池，最后败在活动预占没实时更新，运营各自留一手。我觉得先别追指标，能把谁先拿货写成一张周度规则表就不错了。