去年11月，一个做家居品类的卖家朋友贴了张截图给我：亚马逊后台显示某ASIN可售库存976件，ERP里在途1500件，运营自己的补货表上写着"本周应到货"，而采购的回复是"供应商还没确认排产"。三天后这个SKU断货，广告暂停，类目排名从第18掉到第140位，恢复到原位置用了六周，损失大约23万元销售额。
这个场景我不陌生，因为我自己踩过一模一样的坑。过去两年我经手和复盘的37次断货事件里，只有9次属于"真的卖超了、补不上"，剩下28次都能在断货前72小时被某个环节的人发现，问题是，没有任何人被要求在"那个时间点"做"那个动作"。
所以这篇文章不讲安全库存怎么算，也不讲FBA补货公式怎么套。我要讲的是库存管理落到团队层面之后，到底由谁、在什么时间、基于哪一份数据、做什么动作、留下什么记录。我会把阈值设定、角色划分、工具配置、不同规模的取舍全部展开，包括我用数跨境把多角色库存视图打通、把断货率压下来的完整过程。
先把我的核心判断放在最前面：库存管理的团队协同，本质上只解决三件事，让所有角色看到同一份数据、让每个动作带明确时限、让每次偏差被记录并回灌到阈值里。绝大多数团队的库存协同只做到了第一件事的一半。
他们把"看到数据"做成了"每个人都能看到自己那份数据"。运营看亚马逊后台，采购看ERP采购单，物流看货代群消息，财务看月度报表。四份数据来源不同、更新频率不同、口径不同，于是四个人对同一个SKU的库存判断可以差出300件。
这37次断货来自我服务过的6个卖家团队，时间跨度2023年初到2025年中，覆盖家居、户外、宠物、3C配件四个类目，单团队月销售额在80万到600万之间。我按"最后一次可干预的时间窗口内，最先出问题的环节"做分类，结果如下。
注意这个分布意味着什么：超过七成的断货不是"市场原因"，而是协同链条上某个环节的信息时滞。如果只优化补货公式，最多影响那24.3%，剩下75.7%的问题不会动。
我把库存协同拆成四层，每一层都有对应的失败模式。很多团队只建了第一层就以为流程跑通了，实际上漏洞全在后面三层。
| 层次 | 要解决的问题 | 缺失时的典型症状 | 责任人 |
|---|---|---|---|
| 数据层 | 所有人看同一份库存数字 | 会上对不上数，各说各的 | 运营负责人 |
| 决策层 | 谁在什么阈值下决定补多少 | 该补的时候在等审批 | 品类负责人 |
| 执行层 | 下单、跟单、改后台分别谁做 | 以为别人做了，没人做 | 采购 + 物流 |
| 反馈层 | 偏差记录与阈值修正 | 同一个坑连续踩三个月 | 团队负责人 |
我在一个户外品类团队里见过最典型的场景：数据层他们是有共识的，每周一上午的例会上大家看同一张表。但决策层没定义，运营认为"库存低于30天销量就该补"，采购认为"要等运营发正式采购申请"，结果两边都在等对方。这种情况持续了三个月，中间断货两次。
这可能是本文最反直觉的一个结论。我对比过6个团队的协同配置，发现流程环节越多、审批层级越深的团队，断货率反而更高。原因很简单：每个环节都是一次信息衰减和一次时间损耗。
一个需要"运营提报→主管审核→经理审批→采购下单"四步走完的补货流程，实际平均耗时是38小时。而一个"运营在系统里提交、超过阈值自动通知采购、采购24小时内下单"的两步流程，平均耗时是9小时。前者环节多，听起来更严谨，但38小时里任何一步卡住都会拖到第二天。
所以我的判断是：库存协同的优化方向不是"加控制点"，而是"把控制点前移到阈值定义上"。阈值定得准，流程就可以很轻；阈值定不准，才需要层层审批来兜底。
讲完结论，我把一个具体案例拆开。这是我2024年Q3接手的一个宠物用品团队，月销售额约180万元，SKU数74个，其中主推款12个，团队成员7人：运营主管1人、运营专员2人、采购1人、物流1人、财务1人、客服1人。
他们当时的库存协同方式是这样的：运营专员每天早上登录亚马逊后台看可售库存，手动复制到一张共享表格里；采购维护ERP里的在途数据；物流在微信群里同步货代反馈。每周一上午10点开一次补货会，运营主管根据表格判断哪些SKU需要补货，口头安排给采购。
这套方式在月销100万以下时是可以运转的，因为SKU少、补货频次低。但2024年Q3他们把主推款从4个扩到12个，广告预算翻了一倍，问题就集中爆发了。
我把这一个月的事件按时间还原出来，你可以看到每一次断货都不是单一原因，而是两三个环节叠加。
第一次断货（9月8日）：数据口径不一致。亚马逊后台显示可售412件，运营表格里写的是"可售412 + 在途600 = 可用1012"，但ERP里的600件在途实际还在供应商工厂，采购单状态是"已下单未排产"。运营主管看到1012件，判断够卖三周，没有触发补货。9月8日可售降到0，在途货9月19日才到仓。
第二次断货（9月17日）：决策卡在审批。9月12日运营专员发现另一款SKU可售只剩280件，按日均18件算只够15天，提交了补货申请。申请在主管那里放了两天（主管在出差），采购拿到时是9月15日，供应商回复"排产要等7天"。断货发生在9月17日。
第三次断货（9月26日）：在途信息未回流。这款SKU的补货本来安排得很稳，但货代在9月20日通知物流"清关查验，预计延迟5天"，物流把消息发在了微信群里，运营没看到（群消息太多被刷过去了）。运营按原计划准备了广告预算和站内活动，9月26日库存见底。
复盘下来，第一次断货是数据层问题：可售和在途被合并计算，但两者可用性完全不同。第二次是决策层问题：阈值存在，但触发后的执行路径没有时限约束。第三次是反馈层问题：异常信息产生了，但没有强制回传到决策人。
这里有个细节值得说：这三次断货都不是因为某个员工不负责。运营专员每天认真更新表格，采购认真跟单，物流也确实收到了货代消息并转发了。问题在于，每个人的动作都发生在自己的信息孤岛里，没有一条链路把这些动作串成"有时限的接力"。
很多团队遇到这种问题，第一反应是买工具。我的做法是先画一张图：把从"库存数据变化"到"补货单下达"的全过程拆成节点，每个节点标注输入、输出、责任人、时限。
这张图画完，团队自己就发现了两处空白：一是"在途状态变更"这个节点没有责任人，二是"审批超时"没有兜底机制。这两处空白补上之后，断货率在没上任何新工具的情况下，从每月3次降到1次左右。
讲完案例，我把这几年来见过的误区集中拆一遍，这些误区我在不同团队反复见到，有些甚至被写进了SOP，看起来很有道理，实际在制造风险。
亚马逊后台的"可售库存"是结果指标，不是过程指标。它只告诉你现在能卖多少，不告诉你三周后能卖多少。真正决定会不会断货的，是"可用库存"这个复合概念，可售 + 在途可用 + 计划内补货 – 已锁定订单。
我见过太多团队把后台数字直接当决策依据。问题是后台数字只有在"补货周期短于可售天数"时才有决策价值，一旦补货周期是30天，你盯着一个只反映今天的数字，等于闭着眼睛开车。
微信群能传递信息，但不能承载流程。区别在于：流程需要"可追溯""有时限""有责任人""有状态机"。微信消息发出去之后，没有人知道对方看没看到、什么时候处理、处理结果如何。
我做过一个粗略统计：在6个以微信群为主要协同渠道的团队里，关键库存信息的平均"已读确认延迟"是4.7小时，而在有系统消息+待办确认机制的团队里，这个数字是22分钟。差距不在人，在信息是否需要"主动点开自己那份"。
很多SOP里写着"补货周期35天"，然后所有人按35天倒推。但真实的补货周期是波动的：供应商排产在旺季可能从7天变15天，头程海运在旺季可能从28天变40天，清关在节假日前后可能多出5到7天。
我建议的做法是用"分位数周期"而不是"平均周期"。具体来说，记录每次补货的实际耗时，取P75（75%的情况下能在这个时间内完成）作为计划周期，取P95作为安全库存的覆盖天数。这样做的代价是常态下库存周转会慢一点，但换来的是不容易断货。
74个SKU里，真正决定80%销售额的可能只有12个。如果用同一套高频协同节奏管理所有SKU，团队精力会被大量低价值SKU消耗掉，反而在主推款上反应变慢。
我的分类逻辑是按"日均销量 × 毛利率 × 断货可恢复性"三个维度打分，把SKU分成A/B/C三档。A档SKU每天检查库存、专人负责、补货决策不超过4小时；B档每三天检查；C档每周检查，允许短期断货。
这一节讲我实际在用的方法框架。它不是理论模型，是我在多个团队落地后不断简化的结果。核心就两个概念：三张表、两个时间戳。
为什么是三张而不是一张？因为这三类库存的"可用时点"完全不同。可售库存是当下可用，在途库存是未来某个时点可用，锁定库存是已经承诺出去、不可再分配的量。把它们混在一张表里，一定会出现前面案例里的"412 + 600 = 1012"式误判。
| 表名 | 数据内容 | 更新频率 | 责任人 | 关键字段 |
|---|---|---|---|---|
| 可售表 | 亚马逊各站点FBA可售 + 海外仓可发 | 每日 | 运营专员 | ASIN、站点、可售量、日均销量 |
| 在途表 | 已下单未到仓的采购单、头程批次 | 每两日 | 采购 + 物流 | 批次号、数量、预计到仓日、当前状态 |
| 锁定表 | 已分配给活动、已被订单占用、不可挪用的量 | 每日 | 运营主管 | ASIN、锁定量、锁定原因、释放日 |
三张表之间通过ASIN和站点关联，最终计算出的核心指标是"可用库存天数"：
可用库存天数 = (可售量 + 在途可用量 – 锁定量) / 近7日日均销量
其中：
在途可用量 = 预计在"补货周期P75"内能到仓的在途数量
锁定量 = 已分配给站内活动、促销、批发订单的数量
日均销量 = 取近7日，遇到大促峰值用近14日剔除峰值后重算
这个公式看起来简单，但关键在"在途可用量"的过滤条件上。只把能在补货周期内到仓的在途算作可用，那些还在供应商工厂未排产的，不能算。这一条规则就消除了我前面说的第一次断货。
这是我认为最被忽视、但价值最高的一个设计。每一份库存数据都必须带两个时间戳：数据是什么时候采集的，基于这份数据的决策是什么时候确认的。
为什么？因为库存数据是有保质期的。一份8小时前的库存快照，在日均销量18件的SKU上，误差已经达到135件。如果决策者不知道数据有多旧，就无法判断决策是否还成立。
我要求团队在补货决策上必须标注"数据采集时间"和"决策确认时间"，两者相差超过12小时的决策需要重新验证数据。这条规则执行后，因为"用了过期数据"导致的错误补货决策下降了约六成。
大部分团队的SOP是按部门写的："运营部负责库存监控，采购部负责下单，物流部负责跟单。"这种写法的问题是，它描述的是范围，不是动作，更不是时限。
我要求把SOP改写成三段式：角色 + 动作 + 时限。举几条实际的例子。
写成这样，每个动作都能被检查、被追责、被优化。团队新人也知道每天第一件事做什么。
很多团队的安全库存阈值是"老板觉得应该备45天"。我的做法是用历史数据反推：把过去12个月的补货记录拉出来，计算每次补货的实际耗时分布，取P75作为计划周期，取P95作为缓冲上限。
假设某SKU过去12个月的补货耗时分布是：最短22天，中位数31天，P75是36天，P95是48天。那么计划周期用36天，安全库存覆盖天数用48天。这样在95%的情况下不会断货，代价是常态下多压12天的库存资金。
这个取舍必须由老板或负责人明确决策，因为它是资金效率和断货风险之间的权衡，运营和采购都不该单方面决定。
前面讲的方法论，落地时最大的阻力是"数据分散在不同系统里，人工汇总太慢"。这也是我后来引入数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）的直接原因。
在选工具之前我先明确了需求，一共四条：第一，能同时接入多个亚马逊店铺和站点的库存数据，不需要人工导出；第二，能把我前面说的三张表（可售、在途、锁定）在一个视图里关联起来，而不是分散在三个模块；第三，能给不同角色分配不同权限，运营看全量、客服只看可售、采购只看在途和采购单；第四，能设置阈值并在触发时把提醒推给具体的人，而不是推给一个群。
市面上做亚马逊ERP和库存管理的工具不少，我实际试用了4款。筛选时我放弃了两类：一类是功能很全但操作路径太深，一个补货决策要点七次才能完成，团队根本不会用；另一类是数据接入没问题，但协同层几乎没有，本质还是给运营一个人用的工具。数跨境是我试用后留下来的，主要原因是它的库存视图可以按角色配置，而且从库存数据到补货动作的链路是连贯的，不用在几个模块之间跳。
我把当时的落地过程完整记录下来，如果你要复制，可以按这个顺序走。
整个配置过程我用了大约3个工作日，其中第2步字段映射占了将近一半时间。如果你团队的数据源更复杂，建议预留一周。
工具上线后我跟踪了90天的数据，对比上线前的90天，几个核心指标变化如下。这些数据来自该团队的实际运营记录，我做了脱敏处理。
| 指标 | 上线前90天 | 上线后90天 | 变化幅度 |
|---|---|---|---|
| 月均断货SKU次数 | 3.0次 | 0.7次 | -76.7% |
| 库存数据核对耗时（周） | 6.5小时 | 1.2小时 | -81.5% |
| 补货决策平均响应时长 | 26小时 | 7小时 | -73.1% |
| 库存周转天数 | 62天 | 54天 | -12.9% |
| 滞销库存占库存金额比 | 19% | 13% | -6个百分点 |
| 因数据错误导致的错误补货次数 | 4.3次/月 | 0.8次/月 | -81.4% |
需要说明的是，断货次数下降不全是工具的功劳。同期团队还做了三件事：把SOP改写成了角色-动作-时限格式、建立了每周偏差复盘会、给A档SKU指定了专人负责。工具的作用是让这些流程有了承载，不会被日常事务冲掉。
2025年Prime Day前的备货期，我用这套协同方式跑了一次完整的旺季备货。过程是这样的：提前50天启动备货规划，运营主管根据去年旺季销量和大促报名情况预估需求量，采购根据P95周期倒推最晚下单日，物流锁定头程舱位。
执行过程中出现了两次偏差。第一次是某款主推SKU的预估销量被上调了30%（因为站内秒杀报名通过），采购在4小时内追加了第二张采购单。第二次是其中一个批次因为船期调整延迟了6天到仓，物流在收到通知当天更新了在途表状态，系统自动触发了"可用库存天数跌破14天"的告警，运营据此提前把广告预算下调了35%，避免了断货前的无效花费。
这次旺季该团队12个A档SKU没有出现断货，B档中有2个SKU断货3天以内。对比上一年同期，断货SKU数是7个。
方法论讲完了，但不同规模的团队不能照搬同一套。下面我按四种典型情况给出具体建议，你可以对照自己的团队规模挑选。
这个阶段最大的问题是人手有限，每个人身兼多职。我的建议是不要建复杂流程，先把"每日一次数据对齐"做扎实。
这个阶段用Excel就够了，不需要上系统。真正需要系统是在SKU数超过50个、或者店铺超过2个之后。
这个阶段的核心矛盾是"数据分散，沟通成本快速上升"。我的建议是先统一数据源，再谈流程优化。
这个阶段我见过最常见的失败是：工具买了、数据接入了，但流程没改，大家还是按老习惯在群里沟通。工具不会自动改变协作方式，必须有人明确宣布旧渠道停用。
这个规模下，库存协同已经不是一个流程问题，而是组织问题。我的建议是分层管理、明确接口人。
这个阶段最容易出现的是"各站点抢货"。解决方式不是靠开会协调，而是在系统里把"库存锁定表"做成硬约束，谁锁定了什么、什么时候释放，全部可见。
如果你的销量高度集中在几个大促节点，日常的库存协同逻辑要调整。我的建议是把全年分成"蓄水期"和"放量期"两种模式。
| 维度 | 蓄水期（大促前60-90天） | 放量期（大促前30天至结束） |
|---|---|---|
| 库存检查频率 | 每3天一次 | 每日一次 |
| 补货决策时限 | 24小时 | 4小时 |
| 安全库存覆盖 | P75周期 | P95周期 + 20%缓冲 |
| 在途信息更新 | 每周两次 | 每日一次 |
| 责任人 | 运营专员 | 运营主管直接负责 |
另外，蓄水期要提前把"最晚下单日"算出来并锁死。一旦超过最晚下单日还没下单，就必须放弃这批补货，转而考虑空运或海外仓调拨。这个决策要提前做好预案，不要在时间压力下临时拍板。
库存协同里没有"最好的方案"，每一个选择都在拿一种成本换另一种成本。这一节我把四个最常遇到的取舍讲清楚，帮你判断自己该往哪边偏。
数据同步频率越高、告警越及时，系统成本和你团队的响应人力成本就越高。每15分钟同步一次和每天同步一次，年费可能差出好几倍，而且高频告警会带来"告警疲劳"，团队开始忽略提醒。
我的判断标准是：根据SKU的日均销量决定同步频率。日均销量超过50件的SKU，值得用小时级同步；日均销量低于5件的SKU，天级同步足够。把高频资源集中在高动销SKU上，是性价比最高的配置。
集中决策的好处是库存资金全局最优，坏处是响应慢；分散决策的好处是快，坏处是各站点可能重复备货、抢占同一个供应商的产能。
我的建议是分场景：常规补货分散决策，跨站点调拨和大额备货集中决策。具体来说，单次补货金额低于5万元的由品类负责人决定，超过5万元的由团队负责人决定。这个阈值可以根据团队的资金规模调整。
很多工具都提供自动补货功能，但我在实际使用中不建议全自动。原因是补货决策涉及供应商选择、账期、促销计划等多个工具不知道的变量，全自动容易在异常情况下放大错误。
我的做法是"系统生成建议 + 人工确认"：系统根据阈值和销量预测自动生成补货建议单，包含建议数量和最晚下单日，人工在4小时内确认或修改。这样既保证了速度，又保留了人工判断。异常情况（比如预测销量突然翻倍）时，系统会把建议标记为"需人工复核"，不进入快速通道。
有些团队已经在用多个工具，运营用一个、采购用一个、财务用一个，每个工具都各有优点。这时候要不要统一到一个平台？
我的判断标准是看"数据交接成本"。如果跨工具的数据交接每周花费超过5小时，或者每月因为数据不一致产生2次以上的决策错误，就值得统一。但如果现有组合运转良好，为了统一而迁移的代价可能大于收益，尤其是迁移期间的数据断层本身就是断货风险。
折中方案是：保留工具组合，但把"库存主数据"集中到一个地方，其他工具通过接口或人工同步到这里。这样既不用大迁移，又能保证所有人看的是同一份数。
回到开头那个数字：37次断货里，只有9次是真的卖超了。剩下的28次，问题不在预测不准、不在备货不足，而在信息在团队内部传递时被衰减、被延迟、被遗漏。
我的核心观点可以浓缩成三句话。第一，库存协同的目标不是让数据更全，而是让所有人对同一个数字达成共识。
第二，流程的价值不在控制点多，而在每个动作都有明确的时限和责任人。
第三，真正让团队变强的是反馈层，每一次偏差都被记录下来，并转化成阈值的修正。
第三点最容易被忽略，但它的复利效应最强。我见过一个团队坚持做了18个月的偏差复盘，他们的补货周期估算误差从最初的±11天收窄到±3天，安全库存因此可以下调约15%，释放出的库存资金接近80万元。这不是靠工具实现的，是靠每一次断货、每一次延期、每一次误判都被认真记录和分析。
如果你现在要开始动手，我建议按这个顺序走：第一步，今天就把团队现在用的库存数据来源列出来，看看有几种口径；第二步，本周内把三张表（可售、在途、锁定）的定义和责任人定下来；第三步，下周把SOP改写成角色-动作-时限格式；第四步，评估是否需要引入统一平台，如果你已经在用多店铺、SKU超过50个，我建议认真看一下数跨境的库存协同能力（https://shukuajing.jiushuyun.com/?
utm_source=seo&utm;_plan=est&utm;_unit=gys）；第五步，建立一个雷打不动的周度偏差复盘会。
库存管理这件事，没有一次性的完美方案。它更像是一次次小的修正，每次修正都很微小，但累积一年，就是断货率从6.8%到2.3%的差距，就是六周的排名恢复期变成三天的差距。
我之前做亚马逊的时候，库存这块基本是运营一个人在表格里拍脑袋，采购只管下单、仓储只管收发货，结果去年旺季断货和滞销同时出现，一边空运补货一边清仓打折。我现在特别想知道，一套能落地的库存协同流程到底长什么样，而不是那种“加强沟通、密切配合”的空话。
我实操下来把它拆成五个有明确交付物的步骤，比按部门分工更好落地。
第一步数据归口：每天上午10点前由固定一人从后台导出可售库存、在途库存（FBA在途＋海外仓在途＋国内待发）、近7日与近30日日均销量，生成一张主表，字段固定为SKU、站点、可售、在途、日均销量、可售天数DOS（可售÷近7日日均）、补货点。
第二步做补货建议：运营只负责提供促销、广告、季节性的销量调整系数，比如大促前把日均乘1.5到2.5，不负责算数；采购按统一公式算出建议下单量。第三步审批与下单：单SKU下单金额超过5000美元、或补货量超过60天销量的，必须走留痕审批。
第四步执行与在途跟踪：采购更新预计到仓日期，仓储更新实际收货数量，差异超过5%当天回报。第五步周度对账复盘：库存周转、断货SKU数、滞销（DOS大于90天且30天无销量）三项指标落到具体人。判断依据很简单，每一步必须有唯一的交付物加截止时间，否则协同一定会退化成在群里说话。
我们三个人管两个店铺，老板一直说要上ERP，我觉得Excel明明够用。但上个月两个表里的库存数对不上，超卖了十几单，赔了钱还掉了绩效。我现在很纠结，是不是SKU一多就必须换工具，还是我们流程本身就有问题。
判断门槛我一般看三个可量化的信号，满足两个就该换工具。SKU数超过200、站点超过2个、参与库存决策的人超过4个。低于这个量级，Excel加一张云文档完全够用，但必须做到单一数据源：所有人在同一张表上看同一个数，主表只读，修改走变更记录页签，不许各自另存副本。
一旦超卖或断货造成的损失，一个月内能超过工具成本（轻量项目管理工具通常人均每月几十元），就别再省这个钱。
真要上工具，我建议先别all in大型ERP，而是用某项目管理工具把补货任务流程化：每个SKU的补货就是一条任务卡片，字段写清SKU、站点、建议下单量、审批人、预计到仓日、状态（待审/已下单/在途/已到仓），看板拖拽即可。
这样做最大的好处是留痕，谁在什么时候把补货量从500改成300一查就知道，不用在聊天记录里翻。等SKU过千、多平台多币种的时候再升级专业ERP，前面的字段定义还能直接复用，不白做。
每次开会运营说快断货了，采购说还有40天库存，两边看的根本不是同一组数字。我吃过亏，按运营的口径急急忙忙空运了一批，结果货到了发现国内仓还压着一堆。我想找一个全团队都认可、能直接写进表格的口径。
口径打架的根源是可售库存定义不同：运营看FBA可售，采购看国内仓加在途，两边都没错，放在一起看就会吵。我的做法是三段式统一。第一，明确可用天数DOS等于可售库存除以日均销量，日均销量统一用近7天（快消、旺季）或近30天（长尾、淡季），并在表头注明用的是哪个口径，全公司只准用一个。
第二，补货点等于（采购交期加头程天数加入仓上架天数加安全天数）乘以日均销量，这三个天数必须实测填进去，头程别拍脑袋写30天，查最近3批货的实际入仓时间取平均，我见过标称35天、实际平均47天的。
第三，安全库存等于日均销量乘波动系数乘补货周期，波动系数按历史销量标准差来，销量稳定给1.2，有大促或广告波动大的给1.5到2.0。触发规则定死：DOS低于补货点自动生成补货任务，高于预警线（比如90天）自动进清库流程。
这套数不用很精确，关键是全团队用同一套，并且每月用实际断货和滞销结果回测一次，误差大就修参数。
断货了运营怪采购没下单，采购说运营没报需求，仓储说货到了没人通知上架，最后老板发一顿脾气，问题还在原地。我每个月都要经历一次这种会，很想找到一个能把责任说清楚的机制，而不是靠人情和嗓门。
甩锅的本质是共同责任等于没有责任，解法是把每个动作绑到唯一责任人和时限上，而不是笼统分给部门。我落地的做法是，每条库存协同动作都写成动词加人加时限加交付物，例如运营在每周一12点前提交大促销量调整系数表，采购在收到系数表后24小时内出下单计划并发起审批，仓储在实际收货后2小时内更新收货差异。
结果类指标只追一个归属人：断货率由采购和运营共背，滞销库存金额归属运营，收货差异率归属仓储，写进月度考核而不是口头说说。第二是升级机制，异常超过24小时没解决就自动升级到上级，别等到周会才提。
第三是留痕，所有调整都发生在系统或共享表的记录里，最好用某项目管理工具把每条补货任务做成卡片，改动有历史可查。我的经验是，扯皮最凶的团队往往不是人不行，而是流程里没有谁在什么时候必须交出什么这层定义；把这三样写清楚，吵架会少一大半，剩下的分歧也能拿数据说清。
读者评论
小团队运营视角：先画责任交接图我认同，但我们3个人里运营、采购、物流几乎同一个人兼，交接图最后变成自己给自己设提醒。真正的卡点不是没流程，而是每天没时间核对在途和审批。想问下，SKU少但角色重叠的团队，怎么避免结构化协同变成额外负担？
阈值前移我有点保留。我们做季节性品类，去年按固定销量阈值设补货提醒，旺季前连续误报，后来还是靠人工看广告排期和竞品动销调整。系统能解决时滞，但阈值本身很依赖市场判断，不是配一次就完事，尤其新品没历史数据时更明显。
统一数据源方向对，但落地最难。亚马逊后台、ERP、货代更新频率不同，ERP在途如果包含供应商未确认排产，统一展示反而会放大虚假可用量。我们后来强制把在途拆成已排产、已发货、已清关三段，才敢用来做补货判断，不然数据层只是看起来一致。