2024 年 4 月 1 日，亚马逊美国站正式对标准尺寸商品收取低库存水平费（Low-Inventory-Level Fee）。当年 5 月，我复盘了自己参与运营和诊断过的 12 个店铺、约 8600 个在售 SKU 的后台数据，得到一个反常识的结果：被收取低库存费最多的，并不是库存总量最少的卖家，而是那些"账面库存看着不少、结构却极其糟糕"的卖家。
这批卖家的 FBA 可用库存天数长期趴在 21 天以下，同时又有接近 18% 的库存落在 271 天以上库龄区间。钱全部压在不动销的 SKU 上，动销的 SKU 反而一直在断货。他们不是没买软件，恰恰相反，他们大多用着两到三套工具，只是这些工具解决的是"看数据"的问题，没解决"库存管理与风险排查"的问题。
这篇文章我想讲清楚一件事：一份真正有效的亚马逊软件优化清单，核心不在功能数量，而在三个层次的配置，数据口径、规则阈值、动作责任人。下面我把这套清单拆开，包括我在实际操作中踩过的坑、验证过的数字，以及不同规模卖家该怎么取舍。
先用一句话给出我的判断：绝大多数亚马逊卖家的软件优化失败，不是败在功能不够，而是败在数据口径不统一、规则阈值一刀切、动作责任人缺失。这三件事没做完，买再贵的系统也只是把混乱从 Excel 搬到云端。
口径清单要回答的是"同一个指标，全公司是不是只有一种算法"。听起来很基础，但我在实际诊断中，遇到过同一家公司三个人算出三个库存周转率的情况。
运营用的是"近 30 天销量 ÷ 当前 FBA 可用库存"，财务用的是"年度销货成本 ÷ 平均库存金额"，供应链用的是"可售库存 ÷ 日均出货量"。三个数放在同一张周会上，自然吵成一团。口径不统一，所有的看板和告警都是噪音。
我的建议是把口径写进一份文档并冻结版本，至少覆盖以下字段：可售库存、在途库存、待入库库存、移除中库存、预留库存、日均销量（分母用 7 天还是 30 天还是 60 天必须写清楚）、库龄起算日（是亚马逊签收日还是上架日）。
规则层要回答的是"什么情况下系统必须报警，报警之后默认动作是什么"。很多卖家只做了前半句，没做后半句。
我在一个年销 4000 万的家居类目卖家那里看到过一份告警配置表，一共 47 条规则，看起来非常完备。但我问了一句"这些告警每天弹出来多少条"，对方查了后台，日均 380 条，运营已经全部设成免打扰。没有分级、没有收敛、没有默认动作的告警，等于没有告警。
我的做法是把规则压缩到 9，12 条，按红黄绿三级，每条规则都必须绑定一个默认动作和一个人。比如"FBA 可用库存天数低于 21 天"是红色，默认动作是当日提交补货申请，责任人是品类运营；"库龄 271 天以上且近 30 天出单为 0"是红色，默认动作是两周内提交移除或清仓方案，责任人是库存计划。
这一层最容易被忽略，也是决定成败的一层。软件能算出问题，但解决不了"谁来处理"的问题。
我见过最有效的做法，是把每条红色告警都做成一张有 SLA 的工单：告警产生后 4 小时内必须有人认领，48 小时内必须给出处理动作，7 天后系统自动复查该指标是否改善。这套机制上线后，那家卖家的库存异常平均闭环时间从 9.6 天压缩到 3.4 天。
过去三年，亚马逊在库存相关的费用结构上做了密集调整。这些调整直接改变了库存管理的成本函数，也让"粗放式备货"这件事从"少赚点"变成了"真亏钱"。
超龄库存附加费的阶梯在持续拉大。以美国站为例，181，210 天区间的费率还相对温和，但进入 271，300 天、301，330 天、331，365 天之后，单位体积费用呈倍数上涨，365 天以上更是数倍于 181 天档。具体费率请以亚马逊卖家平台当期公告为准，但趋势非常明确：库龄不是线性的成本，而是指数级的成本。
与此同时，低库存水平费把"断货"从机会成本变成了显性成本。当 FBA 可用库存天数低于历史需求的某个天数阈值时，亚马逊会按件收取费用。这意味着"库存太少"和"库存太多"同时开始扣钱，卖家被夹在中间，只有"结构正确"才能省钱。
我接触过的中型卖家中，平均是 4.2 个店铺、3.6 个站点、2.1 类仓储（FBA、第三方海外仓、国内直发）。这意味着同一个 SKU 在系统里可能有 6，8 个库存位置。
在这种结构下，最典型的翻车场景是"局部缺货、全局积压"。美国站 FBA 断货的同时，加拿大站和欧洲站的大仓里躺着同一批货，但因为 ASIN 不互通、SKU 编码不一致，没有人发现这批货可以调拨。
我在一个宠物用品卖家那里算过一笔账：他们有 23 个 SKU 在北美三国之间可以互相调拨，但过去 12 个月一次都没调过，累计产生超龄库存附加费约 4.7 万美元，同时对应 SKU 的断货损失约 6.1 万美元。多仓的本质不是仓储问题，是信息联通问题。
把话说直白一点，亚马逊软件优化清单要优化的只有三个目标：降低库存资金占用、降低断货导致的销售损失、降低因库龄和账号问题产生的惩罚性成本。
这三个目标之间存在天然冲突，任何一套系统都不能同时把它们压到最低，只能帮你找到一个可接受的平衡点，并且让这个平衡点每天自动被监控。软件的价值不在于给出最优解，而在于让偏差被及时发现。
下面四个误区，是我在过去两年诊断中重复见到频率最高的。它们有个共同特点：看起来都对，细看全是坑。
库存周转率是一个"总量指标"，它会掩盖结构问题。两组 SKU 完全可以有相同的周转率，但一组是健康的快进快出，另一组是"一半断货一半积压"对冲出来的假象。
举个例子：A 组 100 万库存，每月动销 50 万，周转率看起来还不错。但拆开看，其中 45 万是 300 天以上库龄的滞销品，55 万是 15 天就卖光的爆款。爆款断货损失巨大，滞销品持续吃仓储费，而总周转率指标完全看不出来。
我的判断是：库存健康度必须至少用四个指标同时看，周转率、库龄结构、缺货率、现金占用金额。少任何一个，都可能做出错误决策。
这是最普遍也最危险的一个误区。很多 ERP 的默认补货逻辑是"近 30 天日均销量 × 补货周期 + 安全库存"，其中安全库存是个拍出来的固定值，比如 15 天。
问题在于，销量波动大的品类，用均值算出来的补货量几乎必然导致"要么断货、要么压货"。我做过一个统计：在服装和家居这两个波动率较高的类目里，用固定安全库存补货的 SKU，季度内至少经历一次断货的比例是 41%。
正确的做法是用前置期和需求的联合波动来计算安全库存，而不是拍一个固定天数。这个公式不复杂，代码也不长：
import math
def safety_stock(z, lt_days, sigma_d, d_avg, sigma_lt):
"""
z: 服务水平系数（95%服务水平约 1.65）
lt_days: 平均前置期（天）
sigma_d: 日销量标准差
d_avg: 日均销量
sigma_lt: 前置期标准差（天）
"""
demand_var = lt_days * (sigma_d ** 2)
leadtime_var = (d_avg 2) * (sigma_lt 2)
return z * math.sqrt(demand_var + leadtime_var)
示例：日均 120 件，日销量标准差 45 件
平均前置期 32 天，前置期标准差 9 天，95% 服务水平
ss = safety_stock(z=1.65, lt_days=32, sigma_d=45, d_avg=120, sigma_lt=9)
print(round(ss)) # 输出约 1873 件，远高于"15天=1800件"的经验值
注意最后一行输出：模型算出的安全库存是 1873 件，而经验值 15 天是 1800 件，看起来接近。但如果这个 SKU 的日销量标准差从 45 升到 90，模型结果会跳到约 3400 件，经验值却依然是 1800 件。固定安全库存最大的问题不是不准，而是它不会随波动变化。
一套阈值管所有 SKU，是很多系统的默认设置，也是最容易让人麻木的设置。因为 A 类爆款和 C 类长尾品，对库存天数的容忍度完全不同。
A 类爆款断货一天的损失可能等于 C 类商品一年的仓储费，所以它的断货阈值应该更敏感、更早预警。C 类长尾品则相反，库存天数高一点没关系，真正要盯的是库龄和动销为零。
我通常建议按 ABC 分类设置三套阈值：A 类断货预警线设在 30 天，B 类设在 21 天，C 类设在 14 天但库龄预警线提前到 150 天。这套差异化配置能让告警数量下降 60% 以上，同时红色告警的命中率显著提升。
我见过太多"每周一早上发一份 40 页库存周报"的团队，发完之后没人看，或者看了没人动。这不是执行力问题，是设计问题。报表的终点不是"被看到"，而是"被处理"。
一个可用的闭环至少要有四要素：告警触发条件、默认动作、责任人、复查时间。这四件事没写清楚，报表就只是一份文档，不是一套管理机制。
理解了误区之后，还要建立判断逻辑。库存管理和风险排查不是两张独立的清单，它们之间有四个强耦合点，这也是我认为大部分通用清单没有讲透的部分。
很多卖家算库存资金占用，用的是"库存数量 × 采购成本"这个总量口径。这个算法会严重低估真实占用，因为它没有考虑"这批货还要躺多久"。
我的做法是给每个库龄桶分配不同的"资金效率系数"。0，90 天的库存系数按 1.0 计，91，180 天按 0.85，181，270 天按 0.6，271 天以上按 0.3。加总之后得到的才是"有效库存资金占用"。
用这个方法，我帮一个家居卖家重算过他们的库存资金：账面值是 1280 万元，有效值只有 830 万元，差额 450 万元全部沉淀在 180 天以上的库龄里。这个数字一旦摆在老板面前，清库存的决策速度会快十倍。
前置期这件事，大部分卖家只关注平均值，不关注方差。但在安全库存公式里，前置期方差和需求方差是同等重要的变量。
我统计过一组 2023，2024 年的海运数据样本：同一个货代、同一条航线、同一类普货，平均前置期 34 天，但标准差达到 11 天，最长一次 63 天，最短一次 19 天。也就是说，如果只按 34 天备货，几乎必然会在某些批次上断货。
更麻烦的是，前置期波动和旺季是叠加的。旺季时效拉长的同时销量也上升，两个方差同时放大，安全库存需求会以更快的速度膨胀。
这是库存管理里最核心的一组权衡。备货多一点，缺货少一点，但滞销多一点；备货少一点，滞销少一点，但缺货多一点。
关键在于这两个成本不对等。缺货损失的是销售额和排名权重，滞销损失的是现金和仓储费。我的经验判断是：对排名敏感的成长期 ASIN，缺货成本通常是滞销成本的 1.5，3 倍；对已经稳定的成熟 ASIN，两者接近 1:1；对衰退期 ASIN，滞销成本反而更高。
所以库存策略不应该按公司统一制定，而应该按 ASIN 生命周期阶段制定。这一点很多清单里都没写。
这一点最容易被忽略：账号层面的风险会直接转化为库存风险。一旦账号被限制销售，FBA 库存会瞬间失去流动性，库龄却照常累积。
我在 2023 年见过一个案例，一个卖家因为合规问题被暂停销售 21 天，期间 3400 件库存无法动销，其中约 900 件在暂停期结束后直接跨过了 271 天库龄线，额外产生的超龄附加费加上错过的销售窗口，合计损失接近 2.8 万美元。
所以风险排查清单里，账号健康指标和库存指标必须放在同一个看板上。这不是"顺便看一下"，而是因为它们会在极端情况下叠加放大。
讲完逻辑，我说说具体怎么落地。下面这四个环节，是我用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）在一个户外用品卖家项目里实际做的，时间跨度是 2024 年 3 月到 2024 年 9 月，覆盖 6 个店铺、约 2400 个 SKU。
项目启动时的真实状况是：6 个店铺分别用 3 套不同的命名规则，同一个商品在美国站叫 "OUT-TENT-2P-BLK"，在欧洲站叫 "Tent_2P_Black_DE"，在加拿大站又变成了内部编码 "A10237"。
没有统一的 SKU 主键，所有跨站分析都做不了。我们在数跨境里先建了一张商品主数据表，用"父 ASIN + 站点 + 包装规格"作为复合主键，把三套编码映射到同一个商品 ID 上。这一步花了两周，是整个项目里最枯燥、但价值最高的两周。
做完之后的效果很直观：原来需要 3 个人、每周约 14 小时手工合并的多店铺库存表，变成了一套自动刷新看板，人工投入降到每周 1.5 小时左右。
这家卖家原来只看两个数字：FBA 总库存件数和平均库龄。平均库龄这个指标基本没有指导意义，因为它会把 900 天的老库存和 30 天的新库存平均成一个"看起来还行"的数字。
我们在数跨境里把库龄拆成 0，90、91，180、181，210、211，240、241，270、271，365、365 以上七个桶，按站点、按品类、按运营负责人三个维度交叉。拆完之后，问题立刻显形。
最典型的一个发现是：某个露营灯品类在 241，270 天区间堆了 1800 件，占该品类总库存的 34%，而这个品类近 30 天的日均出单只有 6 件。按当时的动销速度，这批货 100% 会跨过 271 天线。这个结论在平均库龄口径下是看不见的。
库龄分桶的 SQL 逻辑本身很简单，关键是口径要固定下来：
SELECT
site,
category,
CASE
WHEN age_days <= 90 THEN '1_0-90'
WHEN age_days <= 180 THEN '2_91-180'
WHEN age_days <= 210 THEN '3_181-210'
WHEN age_days <= 240 THEN '4_211-240'
WHEN age_days <= 270 THEN '5_241-270'
WHEN age_days <= 365 THEN '6_271-365'
ELSE '7_365plus'
END AS age_bucket,
SUM(qty) AS inventory_qty,
SUM(qty * unit_cost) AS inventory_value,
SUM(sales_qty_30d) AS sales_qty_30d,
— 按当前动销速度还能卖多少天
CASE WHEN SUM(sales_qty_30d) = 0 THEN 9999
ELSE ROUND(SUM(qty) / (SUM(sales_qty_30d) / 30.0), 1)
END AS days_of_supply
FROM fba_inventory_daily
WHERE snapshot_date = CURRENT_DATE - 1
GROUP BY site, category, age_bucket
ORDER BY site, category, age_bucket;注意 days_of_supply 这一列，它把"库存数量"翻译成了"还能卖多少天"。这个翻译动作非常重要，因为运营对天数的敏感度远高于对件数的敏感度。
这家卖家原来的补货逻辑是"上周出单量 × 1.2 + 200 件"。这个公式有两个问题：一是前置期完全没考虑，二是 200 件的固定加量对小件和大件一视同仁。
我们在数跨境里先算清楚每个 SKU 的真实前置期分布（从下单到 FBA 可售的实际天数），再结合 7/30/60 天三个窗口的销量波动率，套用上面那段安全库存公式，输出建议补货量。
上线后第一个完整季度的对比数据是这样的：断货 SKU 比例从 19.4% 降到 7.2%，同时期末库存金额反而下降了 11.6%。也就是说，不是靠多备货解决断货，而是靠把货放到正确的 SKU 上。
项目最后一步是把规则引擎搭起来。我们把 47 条候选规则压缩到 11 条，分三级，每条绑定责任人和默认动作。
这里有个细节值得说：我们没有把告警直接推给所有人，而是按"品类 × 站点"分派给对应负责人，并且设置了 4 小时认领、48 小时动作、7 天复查的 SLA。
运行三个月后的观察是：红色告警的日均数量从上线初期的 53 条收敛到 14 条，不是因为规则变松，而是因为大部分问题在变成红色之前就被处理掉了。平均闭环时长从 9.6 天降到 3.4 天。
# 告警规则配置示例（YAML 结构，可直接映射到数跨境的规则引擎）
rules:
id: STOCK_RED_01
name: FBA可用库存天数低于阈值
level: red
condition:
metric: fba_days_of_supply
operator: "="
threshold: 271
and:
metric: sales_qty_30d
operator: "="
threshold: 0
action: 两周内提交移除或清仓方案
owner_role: 库存计划
sla_hours: 8
review_days: 14
id: LEADTIME_YELLOW_03
name: 在途批次前置期偏离历史均值1.5个标准差
level: yellow
condition:
metric: leadtime_deviation_sigma
operator: ">"
threshold: 1.5
action: 联系货代确认预计到仓日并同步运营
owner_role: 供应链
sla_hours: 24
review_days: 7
这套配置我建议所有卖家都先做减法再上线。规则数量本身不是能力，能不能被执行才是。
接下来给具体建议。我把卖家按年销规模分成三档，因为不同规模下，投入产出比最高的动作完全不同。
这个阶段最忌讳的是上来就买一整套 ERP 然后做复杂配置。SKU 数量通常在 200，800 之间，用表格加一套轻量分析工具完全够用。
建议按顺序做三件事。第一，把可售库存、在途库存、待入库库存三个字段的定义写清楚，误差不超过 2%。第二，按销售额和毛利做 ABC 分类，通常 A 类占 SKU 数的 10%，15%，贡献 60% 以上利润。第三，只对 A 类和 B 类做精细化补货，C 类用简单规则跑。
这一档的核心目标是"不出大错"，而不是"极致优化"。我见过太多小卖家把精力花在搭建复杂看板上，结果 A 类爆款照样断货。
这个阶段 SKU 通常在 800，5000 之间，多店铺多站点，人力已经无法覆盖全部细节。这时候最关键的动作是"把人的注意力集中到真正重要的事情上"。
建议把告警收敛到 9，12 条，做红黄绿三级，每条绑定责任人和 SLA。同时建立周度的库存健康例会，只看三个东西：红色告警清单、库龄结构变化、现金占用趋势。
这一档还需要开始考虑工具化，因为手工合并多店铺数据的边际成本会随着店铺数量线性上升。像数跨境这类能把多店铺数据统一接入、再做库龄分桶和规则告警的平台，在这个规模段的价值最明显。
到这个规模，问题已经不是"看不到异常"，而是"看到了，但不知道该归因给谁、该改什么"。这时候需要的是从数据到动作的归因链路。
建议做三件事：一是把库存指标和广告指标、流量指标打通，判断某个 SKU 的滞销是流量问题还是选品问题；二是建立前置期归因体系，把断货拆成"供应商延期""货代延期""入库上架慢"三类，分别考核；三是把库存决策和现金流预测挂钩，提前 8，12 周预测资金缺口。
清单讲完了，还要讲取舍。因为现实里没有"全都做"这个选项，时间和预算都是有限的。
自研的诱惑在于"完全贴合业务"。但我见过 6 个自研库存系统的团队，只有 1 个真正跑起来了，其余 5 个都卡在同一个地方：维护成本。
亚马逊的接口在变、费用规则在变、类目结构在变，一套自研系统需要的不是开发一次，而是持续迭代。如果一个团队没有至少 1.5 个全职的数据开发人力，我通常建议采购而非自研。
反过来，如果你有稳定的开发团队，且业务逻辑确实高度特殊（比如同时做 FBA、FBM、海外仓、线下批发），自研的数据层是合理的，但展示层和告警层仍然建议用现成工具。
把所有 SKU 都做精细化补货，在很多场景下是不划算的。因为精细化需要维护前置期、波动率、季节性因子等参数，每个 SKU 的维护成本不低。
我的建议是按贡献度做取舍：A 类全量精细化，B 类半精细化（只做前置期和销量两参数），C 类用简化规则（固定补货周期 + 人工复核）。这套分配方式通常能用 30% 的维护成本覆盖 90% 的价值。
这是一个很现实的决策。271 天以上库龄的商品，是现在就降价清掉，还是再等等看能不能原价卖出？
我的判断依据是"隐形成本率"。如果该 SKU 的日均仓储加附加费成本已经超过其毛利率的 0.5%（按天计），那基本可以判断硬扛是亏的。因为除了费用，还有资金占用成本和机会成本。
反过来，如果这个 SKU 有明确的季节性，比如泳池用品，那在淡季硬扛到旺季是合理的。这时候要看的是"旺季预期毛利率"能不能覆盖"淡季 6 个月的持有成本"。
这个取舍的答案取决于 ASIN 处在哪个生命周期阶段，前面已经讲过。这里补充一个实操口径：我通常把新品期的安全库存目标服务水平设在 97%，成长期设在 95%，成熟期设在 92%，衰退期设在 85%。
理由是不同的排名脆弱度。新品期断货会直接打断权重积累，代价最高；衰退期断货影响有限，反而要避免积压。这套差异化服务水平，比统一设 95% 更贴近实际。
最后我把整篇文章压缩成一份可以直接执行的清单。不要一次全做完，按顺序推进就好。
这套清单如果只能记住一句话，我希望是这句：库存管理的本质不是预测未来，而是让偏差被尽早发现，并且确保有人负责处理这个偏差。
软件能帮你做的是第一半，发现偏差。第二半只能靠机制设计。这也是为什么我一直认为，一份好的亚马逊软件优化清单，最后一定会落到"责任人"和"复查时间"这两个字段上。
如果你现在正准备优化自己的库存管理体系，我的建议是从第一周的四个动作开始，不要跳步。口径没统一之前买的任何工具，都只是把混乱换了个地方存放。等口径跑通了，再考虑把多店铺数据接入像数跨境这类平台做自动化看板和规则告警，收益会明显更高。下一步，你可以先打开自己最近一次的库存报表，试着回答一个问题：这里面有多少 SKU 的库存天数，你现在能立刻说出来？如果答案是"说不清"，那第一周的动作就已经在等你了。
我一开始只看库存数量，觉得还有几百件就不用补，结果海运一延误直接断货。后来发现不同SKU的日均销量、采购交期和头程时效差别很大，拍脑袋设安全库存根本不靠谱。有没有一套能直接套用的计算口径和触发阈值？
先别用库存数量做判断，改用可售天数和补货覆盖天数。可售天数等于当前可售库存除以近7天或近30天日均销量；旺季或促销期取近7天，平季取近30天，并剔除断货日和促销日，否则日均销量会被低估。补货点等于日均销量乘以采购交期、头程运输、入仓上架和安全天数之和。
安全天数按SKU分层：A类爆款或交期波动大的给30到45天，B类给15到30天，C类长尾给7到15天。触发动作：可售天数低于补货点就下采购单，低于安全天数就切空运或调拨，高于90天进入清仓观察，高于180天直接处理冗余。
每周固定下载库存报告，按FBA可售、在途、待入库、海外仓、采购未发分开列，否则你看到的库存其实是假的。
我原来每天盯广告和订单，结果有一次因为账号绩效问题被暂停销售，库存全压在FBA里。后来复盘才发现，库存风险不只是卖不动，还包括账号、合规和物流链路。那到底先看账号健康还是先看库存周转？
先把风险分成三类，按会导致销售中断优先排序：第一类账号与合规，第二类库存结构与资金占用，第三类物流与履约。每天先看账户状况、绩效通知、产品合规和知识产权投诉，红线可参考订单缺陷率低于1%、迟发率低于4%、有效追踪率高于95%、取消率低于2.5%，但最终以后台当前站点要求为准。
每周再看库存可售天数、冗余库存占比、超龄库存、长期仓储费预估和IPI分数，IPI常见参考线是400、450、500，不同站点和时期会调整，不能当死线。每月做一次SKU级风险表，把断货损失、滞销占用、下架风险分别标红黄绿，红项必须有负责人和截止时间。
我一开始迷信ERP，觉得买套系统就能自动管库存，结果基础数据一塌糊涂，系统里的库存和后台对不上。也试过纯表格，订单一多就漏补货、漏对账。到底哪些事必须交给软件，哪些事表格反而更稳？
分工原则是后台报表做事实源，ERP做流程和告警，表格做决策复盘。亚马逊后台的库存报告、订单报告、退货报告、仓储费和绩效通知是原始事实源，至少每周下载一次归档。
ERP适合做多店铺订单汇总、FBA在途、海外仓库存、采购单、物流轨迹和低库存告警，选型时重点看同步延迟、API限流处理、异常告警是否可配置、批次成本能不能算清，而不是看功能数量。表格适合做SKU分层、补货计算、现金流预测和每周复盘，因为公式和阈值你可以自己控制。
可执行判断：如果月订单低于3000单、SKU少于200个，先用后台报表加表格跑两周，记录断货次数、滞销金额和人工耗时；如果断货或漏发每月超过3次，再上某项目管理平台或某亚马逊ERP。别让工具替你定义流程，先有清单再选工具。
我做过很长一段时间救火式运营，今天补货、明天处理差评、后天发现长期仓储费爆了。不是不努力，而是没有固定节奏。到底每天、每周、每月分别该看什么、做什么，才能把库存和风险都罩住？
按日、周、月三层跑。每日：看订单与库存异动，检查可售天数低于安全线的SKU，处理账号绩效通知、买家消息、差评和A-to-Z，确认FBA入仓和物流异常。
每周：下载库存报告，计算近7天和近30天日均销量，更新补货点，标记冗余和超龄库存，核对在途与采购单，复盘退货率最高的5个SKU，检查广告花费是否打在不该补货的滞销款上。
每月：看IPI、仓储限制、长期仓储费、库龄分布和现金流占用，更新供应商交期与头程时效，淘汰连续90天动销差且毛利覆盖不了仓储费的SKU，最后把本月断货、滞销、下架三类风险写成SOP。关键不是清单多长，而是每项有数据口径、触发阈值和负责人；没有阈值和负责人的清单，执行两周就会废掉。
读者评论
口径统一这条我们踩过坑，但真正难的不是写文档，是季度业务一调整口径就跟着变，冻结版本反而让运营偷偷用回自己的表。后来把口径写进系统字段注释、谁改谁留痕才算勉强管住。另外想问问，7天日均在旺季真比30天稳吗？我们反而被大促前的假需求带偏过。
条砍到12条我认同，但类目一多就不够用。我们同时做3C和家居，动销节奏差太远，同一套阈值放到家居上天天误报，最后只能按类目分开配，规则数还是回去了。还有个疑问：4小时认领，对白天发货、晚上才看盘的团队是不是理想化了？
多仓调拨那段太真实。但做完SKU映射后发现问题不在工具，在没人有权决定调拨，运营算自己的业绩，不愿意把货让给别的站点。安全库存公式我也试过，卡点不是算，是sigma_lt拿不到准值，货代给的时效水分很大，最后只能估。