去年第四季度，一个做家居类目的亚马逊卖家找到我。他有四个站点、十一个店铺、一千多个在售 SKU，团队规模从三个人扩到十一人。他说自己每个月都做复盘，广告报表、Listing 优化记录、客服工单都看了，但结果一年比一年失控：旺季断货，淡季压货，年底一算，账上趴着的库存金额比全年净利润还高。我让他做一件很笨的事，把过去十二个月的库存流水、补货记录、广告花费、价格调整日志并排摊在同一个时间轴上。
三天后他自己找到了答案：每一次断货，前面都至少有十四天的可见征兆；每一次滞销，前三十天都出现过转化率下滑但没人动手。库存数字不是采购部的问题，它是整个日常管理体系投在墙上的影子。
先给结论，而且是我在过去几年里反复验证过的结论：在亚马逊这门生意里，库存管理是所有日常管理动作的最终结算口。选品判断、补货节奏、广告投放、价格策略、客服响应、物流选择，这六个动作每一天都在往库存这个池子里注水或放水，库存数字只是把结果显影出来。
所以当我看到一家店铺库存周转天数从 45 天涨到 78 天，我不会先去问采购是不是下错了单。我会往回倒推三十天，看那段时间里发生过什么：是不是有两个爆款被加了广告预算但转化没跟上，是不是竞品降价后自己没跟，是不是某批货的海运改成了空运但售价没调。库存管理的价值，恰恰在于它是一个可以被高频观测、并且能反推出管理漏洞的指标集。
我把这个判断拆成五条可执行的结论，后面所有章节都是围绕它们展开的。
第一，库存指标的波动，绝大多数来自日常动作的累积，而不是某一次单点失误。采购下错单只是表象，真正的问题是补货决策依赖的是人的记忆而不是规则。第二，库存管理的第一道门槛不是优化，而是可见性，如果你连在途、在产、海外仓、FBA 可售、FBA 不可售这五个池子都拼不到一张表上，后面所有讨论都没有意义。第三，软件解决的是"看得见、算得准、提醒得快"，管理解决的是"改得动、担得起、跟得住"，这两件事经常被混为一谈。
第四，验证顺序应该是结构优先于速度，速度优先于成本，成本优先于回报。反过来看数据，十次有八次会误判。第五，也是最容易被忽略的一条：库存管理没有终局，它是一条持续收窄误差的曲线，而不是一次上线就能解决的项。
我参与过一个家居类目店铺的完整改造过程，从 2021 年到 2024 年。这个案例很适合拿来讲库存与日常管理的关系，因为它的增长曲线和失控曲线几乎是同时发生的。
2021 年，店铺有 180 个在售 SKU，两个站点，三个人。那时候库存管理基本靠一张 Excel，每周更新一次 FBA 可售数量，补货靠老板拍脑袋加一点经验系数。这个阶段问题不大，因为 SKU 少，老板本人对每个产品的动销节奏心里有数。
2022 年，SKU 涨到 520 个，站点扩到四个，团队七个人。Excel 开始不够用了，因为出现了三个新变量：海外仓开始备货、部分产品走工厂直发、汇率波动影响采购成本。这时候周会上的库存数据需要两个人拼一整天，而且经常拼不上，FBA 后台的数字、海外仓的表格、工厂的在产清单，三个口径对不齐。
2023 年到 2024 年，SKU 突破 1100 个，团队十一人。矛盾彻底爆发。最典型的场景是：运营在周会上说某个产品库存健康，因为 FBA 可售还有 800 件；但实际上工厂还有 3000 件在产，海外仓压着 1200 件，而这款产品的日销已经从 60 件掉到 18 件。等到所有人反应过来，这批货已经变成了六个月以上的长期库存。
这里面有一个我特别想强调的点：这个团队当时并不缺数据，缺的是同一时刻、同一口径的数据。FBA 后台的数据是准的，海外仓的表格也是准的，工厂的微信消息也是准的，但它们是三个时间点的三个口径。
库存管理里有一个很朴素的物理规律：数据延迟一天，判断误差就会被放大一次。当你的补货周期是 45 天，判断偏差 3 天，误差率大约 7%；当补货周期拉长到 90 天，同样的 3 天偏差会带来接近 15% 的库存错配。SKU 越多、链路越长，延迟的代价越贵。
我后来把这个团队的问题总结成一句话：他们用管理 180 个 SKU 的方式，去管理 1100 个 SKU。管理方式没有跟着规模升级，库存只是第一个崩掉的地方。
在讲判断逻辑之前，我想先把几个高频误区说清楚。这些误区我在至少二十个卖家身上见过，包括我自己早期踩过的坑。
周转率是个好指标，但它是个"结果指标"，不是"操作指标"。我见过一个团队为了把周转天数从 60 天压到 40 天，直接砍掉了所有安全库存，结果旺季连续断货三周，断货损失远超节省的资金成本。
周转率的问题在于它可以被短期操纵。清一批库存、暂停补货、把滞销品打折甩掉，数字立刻变好看，但底层能力没有变化。我更倾向把周转率拆成三个过程指标来管：补货决策准确率、滞销识别及时率、在途可视率。这三个指标改善了，周转率自然改善；反过来不成立。
这是新手和老手都会犯的错。FBA 后台的数字最直观，所以大家天天看。但真正决定你未来 60 天库存健康度的，是那些还没上架的部分：海运在途、空运在途、工厂在产、海外仓待发、FBA 待接收。
我见过最夸张的一个案例：某卖家看到 FBA 可售只剩 200 件，紧急下单空运补货，货到之后才发现海运那批 4000 件已经到港一周，只是入仓延误没有更新。结果这批空运货直接变成新的滞销库存。
很多卖家说自己在做库存管理，其实是"每月看一次报表"。这个频率在 SKU 少于 200 个、补货周期短于 30 天的时候勉强够用。一旦 SKU 过千、链路拉长到 60 天以上，月度复盘就等于事后追认。
我自己的经验是：库存风险必须按"是否可逆"来设置监控频率。可逆的风险（比如轻度动销下滑）可以周级观察；不可逆的风险（比如已经下单在产、已经开始海运）必须日级预警，因为一旦错过窗口，你就只能承担后果。
这是我见过最多的资源浪费。团队花了几万块买了系统，上了两周发现数据填不进去，然后得出结论"工具不好用"。真实原因是没有先定义清楚几个基础问题：安全库存怎么算、补货触发点是什么、谁有权修改参数、异常由谁在多久内响应。
工具是流程的放大器，不是流程的替代品。流程清晰时，工具让效率翻倍；流程混乱时，工具让混乱翻倍，而且是更快地翻倍。
不断货听起来天经地义，但它是拿资金效率换来的。理论上你可以把每个 SKU 都备到 180 天库存，永远不会断货，但你的现金会被彻底锁死。
我自己的判断标准是：断货要分等级。引流款、利润款、新品期的核心 SKU，断货代价可能是排名和权重的永久损失，值得用高安全库存去保；长尾款、测试款、季节性尾款，断货的代价远小于压货，宁可冒一点断货风险。
讲完误区，进入我真正想分享的方法论。这部分内容不是教科书上的模型，是我自己在实操中反复修正出来的。
我把库存管理能力拆成三层，每一层的缺失都会导致完全不同的失败形态。
这一层解决的是"数据在哪里、口径是否统一、更新频率多高"。采集层的典型失败是数据孤岛，FBA 一套、海外仓一套、工厂一套、财务一套。判断标准很简单：你能不能在三分钟内回答"某个 SKU 在任意时点的全链路库存是多少"。如果不能，采集层就不合格。
这一层解决的是"多少算异常、什么时候该动手、动谁的手"。采集层做得好但判断层缺失，表现形式是"报表很全，但没人看，看了也不知道该怎么办"。判断层的核心是规则：安全库存规则、补货触发规则、滞销分级规则、清仓止损规则。
这一层解决的是"谁负责、多久响应、改不动怎么办"。很多团队前两层都不错，卡在执行层。典型场景是：系统提示某 SKU 需要降价清仓，但运营不敢降，因为降价会影响当月 GMV 考核。这就是执行层被组织机制卡住了。
我的判断是：三层能力缺一层，整体效果最多只能发挥三分之一。而且三层之间存在依赖，采集层不牢，判断层就是在算错数；判断层不清晰，执行层就是在瞎动。
这是我判断一家店铺库存健康度的固定顺序，顺序不能乱。
第一步看结构。库存结构指的是：畅销款、平销款、滞销款各占多少资金比例。如果滞销款占了 30% 以上的资金，那不管周转率多好看，都是不健康的。第二步看速度。这里的速度不只是周转天数，还要看动销率的分布，多少 SKU 在 30 天内有销量，多少在 90 天内有销量。第三步看成本。包括仓储费、长期仓储附加费、资金成本、降价损失。第四步才看回报。也就是库存资金带来的毛利回报率。
之所以强调顺序，是因为很多人一上来就看回报，然后被平均数骗了。一个店铺整体回报率 25% 看起来不错，但拆开看，20% 的 SKU 贡献了 80% 的利润，另外 40% 的 SKU 在净亏损。平均数会掩盖结构性问题，而结构性问题才是真问题。
我一直强调库存是"显影液"，那就必须把它变成可追溯的映射表。下面这张表是我自己在用的版本，它把日常动作和会影响的库存指标一一对应起来。
| 日常动作 | 影响的库存指标 | 典型滞后周期 | 可观测的前置信号 |
|---|---|---|---|
| 广告预算调整 | 动销率、库存周转天数 | 7-14 天 | 转化率连续 5 天下滑 |
| 售价调整（跟价或提价） | 日销件数、滞销占比 | 3-7 天 | 竞品价格变动、BuyBox 占有率下降 |
| 补货下单决策 | 在途库存、资金占用 | 30-60 天 | 库存可售天数跌破安全线 |
| 客服与评论处理 | 退货率、可售库存损耗 | 14-30 天 | 差评集中出现、退货原因关键词聚集 |
| 物流方式切换 | 入库时间、断货天数 | 15-45 天 | 货代时效波动、清关异常 |
| 清仓与促销决策 | 滞销占比、仓储成本 | 30-90 天 | 库存龄超过 180 天、动销归零 |
这张表的价值在于，它把"库存出了问题"这种模糊感知，变成"某天某个动作没有及时跟"的具体归因。
经常有人问我预警规则到底该怎么写。规则不必复杂，但必须包含在途、在产、日销波动、安全天数四个要素。下面是我常用的一个规则骨架，写成伪代码便于理解。
# 补货预警规则骨架（伪代码，非某款软件的真实语法）
for sku in all_skus:
if sku.tier == "core": # 核心款
safety_days = 45
elif sku.tier == "normal": # 常规款
safety_days = 30
else: # 长尾款
safety_days = 15
触发预警
if cover_days safety_days * 3 and sku.trend == "declining":
alert(sku, level="滞销预警", suggest_action="降价或清仓评估")
这个规则里有两个设计细节值得说明。第一，日销用了 7 天和 30 天的加权，而不是单纯取 30 天平均，因为大促前后 30 天平均会严重失真。第二，规则必须包含反向预警，也就是库存过深。大部分团队只做断货预警，不做滞销预警，结果防住了断货，压死了现金。
这是我特别想提醒的一点，因为它非常隐蔽。有四种情况会让库存数据表面正确、实际误导。
第一种是批次成本未更新。采购成本随汇率和原材料波动，如果系统里还是三个月前的成本，那么毛利判断会整体偏高。第二种是多店铺共享库存但未做分配规则，导致同一批货被两个店铺重复计入可用库存。
第三种是退货库存未及时回冲。亚马逊退货处理有周期，如果退货件数没有回冲到可售或不可售池，库存会被低估。第四种是预售或促销锁定量未扣除。这四种情况的共同点是：数据本身没坏，但口径错了，而口径错误比数据缺失更难发现。
讲完方法论，必须给一个能验证的样本。我拿"数跨境"这个工具作为观察对象，原因不是它有多特殊，而是它恰好覆盖了我前面强调的几个关键点：多店铺多平台的数据归集、在途与在产库存的纳入、批次成本核算、以及规则化的预警。官网在这里：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys
需要提前说明：下面的数据来自我参与的一次实际改造观察，涉及具体店铺的部分做了脱敏和区间化处理，部分指标为合理的情景推演，用于说明趋势而非精确统计。
我评估任何一个库存管理工具，都看四个问题：能不能把多店铺多平台的数据收到一处、能不能纳入非 FBA 的库存池、能不能做批次成本、能不能输出可执行的预警。前两个决定数据可见性，第三个决定判断准确性，第四个决定能不能落地。
数跨境在这四点上的表现是：多店铺多平台归集做得比较完整，在途、在产、海外仓这些容易被忽略的池子可以纳入统一口径，批次成本支持按批次核算并联动汇率，预警侧提供断货和滞销的双向规则。它的定位不是"报表工具"，更接近"库存中枢"。
这个店铺改造前的状态，我先给几个关键数字：在售 SKU 约 1080 个，四个站点，十一个店铺。库存数据需要三个人、每周花 1.5 天拼表。库存准确率（系统记录与实际盘点的一致率）约 82%。90 天以上无销量的 SKU 占比 24%。补货决策平均滞后 6.5 天。
更关键的一个数据是：在这个团队里，从"发现库存异常"到"实际做出调整动作"的平均时长是 9.5 天。这意味着即使数据是准的、判断是对的，窗口也已经被消耗掉了大半。
改造分三步推进。第一步是把十一个店铺的数据统一到一个 SKU 主数据下，这一步花了约三周，主要成本是人工核对而不是技术。第二步是补在途、在产、海外仓三个池子，这一步花了约两周。第三步才上预警规则，包括断货预警和滞销预警的两套规则。
90 天后的数据变化我整理成一张表，方便对比。
| 指标 | 改造前 | 90天后 | 变化幅度 | 归因说明 |
|---|---|---|---|---|
| 库存准确率 | 82% | 96% | +14 个百分点 | 多口径统一后的直接收益，人工拼表误差被消除 |
| 90天以上无销量SKU占比 | 24% | 13% | -11 个百分点 | 滞销预警先于人工发现，平均提前 22 天介入 |
| 月度断货SKU数 | 37 个 | 11 个 | -70% | 核心款安全天数从统一值改为分级值 |
| 库存周均盘点耗时 | 1.5 天/周 | 0.3 天/周 | -80% | 数据自动归集，人工只做异常抽查 |
| 异常到动作的平均响应时长 | 9.5 天 | 2.8 天 | -71% | 规则化预警替代人工巡检，但需配套责任人机制 |
| 库存资金占用（同销售规模下） | 约 1720 万元 | 约 1280 万元 | -25.6% | 结构优化带来的释放，未牺牲断货率 |
这里有一个必须诚实说明的点：库存资金占用下降 25.6%，并不是靠砍库存砍出来的。实际上同期的销售额还增长了约 12%。下降来自两个结构性来源：一是滞销库存的提前清理，二是重复补货的消除。后者尤其容易被忽略，十一个店铺各自补货时，同一个 SKU 可能被重复下单两次。
我觉得比"哪些变好了"更有价值的问题是"哪些没变"。诚实地说，有三类指标在 90 天内几乎没有改善。
第一类是毛利率。库存管理优化的是周转和资金占用，它不直接改善毛利率，甚至在清仓阶段会短期拉低毛利。第二类是单 SKU 的动销波动。这是市场需求问题，不是库存管理问题。第三类是组织响应速度的上限。人的决策速度有物理极限，规则可以减少漏判，但不能让一个人同时处理两百个 SKU 的决策。
这三类"没变"的指标，恰恰是判断库存管理工具边界的关键。它能让你看得更清楚、算得更准、提醒得更快，但它不能替你判断市场，也不能替你做组织决策。
讲一个我想得起来的细节。改造进行到第 11 周时，系统对一款户外类核心产品发出补货预警。当时 FBA 可售还有 640 件，按运营的人工判断属于"库存充足"。
但系统计算的全链路可用库存是 640（FBA）+ 180（海外仓）+ 0（在途），日销加权值从 30 天前的 38 件涨到了 52 件。覆盖天数 = 820 / 52 ≈ 15.8 天，而这款产品的安全天数是 45 天，因为它是核心款，海运周期要 38 天。
如果按人工判断，等到 FBA 可售跌破 300 件再补货，已经来不及了，因为下单到入仓至少 45 天，中间会断货约 20 天。这次拦截的直接价值，是避免了一次核心款约三周的断货。按这款产品当时的日均利润估算，三周断货的机会成本在六位数。
这个案例的关键不在于工具多聪明，而在于它把"在途、日销趋势、安全天数"三个变量放在一起算，而人工判断通常只看第一个。
必须说几个坑，不然就成了软文。第一个坑是主数据没统一就急着上规则。一开始我们把十一个店铺的数据直接导进去，同一款产品在四个站点有不同的 SKU 编码，结果系统把它当成四个产品分别计算，预警数量直接翻了四倍，团队被无效预警淹没了两周。
第二个坑是预警阈值设得太紧。初期为了"不漏报"，把安全天数普遍上调了 10 天，结果补货量暴增，库存资金占用反而上升了约 9%。后来做了分级才纠回来。
第三个坑，也是最难的一个：预警有了，但没人认领。系统每天推送几十条预警，运营看着烦，慢慢就忽略了。后来我们加了一条硬规则，每条预警必须有责任人、有处理时限、有时限内必须给出结论（补货、降价、清仓、忽略并说明理由）。这一条落地之后，预警的实际处理率才从 40% 出头提到 90% 以上。
方法论讲完，必须落到具体行动。因为不同规模的卖家面临的约束完全不同，我给的建议也必须有差异。下面按四类情况分开说。
这个阶段我不建议上复杂系统。核心动作只有三个：第一，把 FBA 可售、在途、工厂在产三个数字放在同一张表上，每周更新两次。第二，给每个 SKU 标一个等级（核心、常规、长尾），不同等级用不同安全天数。第三，设一条硬线：库存龄超过 180 天且 30 天无销量的 SKU，必须进入清仓评估。
这个阶段最重要的是建立习惯，而不是买工具。我见过太多卖家在这个阶段就买了系统，结果数据没人维护，三个月后系统成了摆设。
这是最需要工具的区间。矛盾在于：人工已经管不过来，但团队还没有专门的数据岗位。我的建议是，这个阶段必须把库存数据从"人拼"转为"系统归集"，并且一定要把非 FBA 的库存池纳进来。
行动顺序建议是：先统一 SKU 主数据（这一步最痛但必须做），再纳入全链路库存池，然后才上预警规则。顺序颠倒的话，你会得到一堆基于错误数据的正确预警。
这个阶段的核心问题不再是"看不看得见"，而是"决策效率"。你需要的不只是库存中枢，还需要明确的分层决策机制：哪些决策由系统规则自动触发，哪些由运营判断，哪些必须上升到负责人。
我建议按金额和不可逆性划分：金额小且可逆的（比如单 SKU 降价 5% 以内）可以授权到运营；金额大或不可逆的（比如大批量补货、工厂下单）必须走审批。决策分层做不好，规模越大越容易瘫痪。
这种情况有一个特有的风险：重复补货和库存互抢。同一款产品在三个店铺同时售卖，如果各自独立补货，很容易出现总量超配。
我的做法是在 SKU 主数据层面做"虚拟合并"，同一物理产品归到同一个主 SKU 下，各店铺的销量合并计算需求，补货决策统一做，然后再分配到各店铺。这一步在数跨境的归集能力下比较容易实现，因为它的设计前提就是多店铺多平台。
季节性产品不能用常规安全天数。我的经验是：旺季前的备货要在标准安全天数上乘以 1.5 到 2 倍，旺季中维持标准值，旺季结束后立刻切换为清仓模式，安全天数下调到标准值的 50%。
非季节性产品反而更要注意"慢性滞销"，因为没有季节性掩盖，滞销会持续累积直到某一天集中爆发。非季节性产品的滞销预警阈值应该设得更低、更敏感。
这种情况我遇到得最多。通常原因有三个：主数据没统一、预警没有责任人、阈值设置不合理。排查顺序建议按这个来：先抽查十条预警，看数据对不对；再查预警的处理记录，看是否有人响应；最后查阈值，看预警量是否超出团队的合理处理能力。
如果每天预警量超过 30 条而团队只有两三个人，那几乎可以肯定阈值设置过紧，需要先做分级，把预警量压到可处理范围内。预警的价值在于被处理，不在于被发出。
最后一部分我想讲取舍。库存管理里最危险的思维方式是"追求最优"，因为库存本质上是在多个互相冲突的目标之间做动态平衡。以下是我认为最需要在四种情况下想清楚的取舍。
这是最基础的取舍。库存越深，断货风险越低，资金效率越差；库存越浅，资金效率越高，断货风险越高。我的做法不是找中间点，而是按产品分层，让不同产品落在不同的风险偏好位置上。
核心款可以接受资金效率低一些，因为断货的代价是排名和权重的损失，这种损失往往不可逆。长尾款相反，宁可偶尔断货，也不要压货，因为长尾款的排名跌了也没什么可惜的。用同一套安全库存策略覆盖所有产品，是最大的浪费。
精细化意味着更多的规则、更细的阈值、更高的准确度，但代价是响应变慢。我见过一个团队把补货规则细化到 12 个层级，结果每次补货决策要过三轮，平均耗时 14 天，反而错过了补货窗口。
我的判断标准是：如果一个决策窗口短于 7 天，就不要做超过两级的精细化分层。在快窗口的场景里，速度比精度更值钱。
这是很多中大型卖家纠结的问题。我给一个粗略的判断：如果你的年 GMV 低于 5000 万，自研库存系统的投入产出比几乎必然为负。原因不是你养不起技术团队，而是库存管理的核心难点不在技术，在业务规则和持续维护。
自研适合的场景是：你的业务模式足够特殊，市面上通用工具的标准字段和流程无法承载。比如你有自己的定制生产周期、有复杂的组合装拆解逻辑、有多级分销库存。否则自研的结果通常是花了两年做了一个功能残缺的通用系统。
滞销库存清仓的诱惑很大，因为它能立刻释放资金、改善周转指标。但代价是可能破坏价格体系，尤其是当你的清仓价格被竞品抓取并形成长期价格锚点之后。
我的做法是分渠道处理：站内清仓优先用优惠券和秒杀，避免直接改低价；站外清仓走独立渠道，不影响主站价格历史。这个取舍的原则是：宁可清得慢一点，也不要让清仓价进入主站的价格记录。
最后一个取舍是很多完美主义者会踩的坑：为了等一份更完整的数据而推迟决策。库存管理的现实是，你永远拿不到 100% 完备的数据，等待本身就是一种成本。
我的经验法则是：如果缺失的数据不足以改变结论的方向，就应该立即决策；如果缺失的数据可能让结论反转，那就等。判断这个的门槛很具体，缺失的数据是否会影响"补多少"这个量级判断，而不只是"补不补"。
回到最开始那个问题：为什么我坚持用库存管理来验证日常管理效果？因为库存是这门生意里为数不多的、无法被话术修饰的指标。广告数据可以解释成"在养词"，Listing 数据可以解释成"在测试"，客服数据可以解释成"个别情况"，但库存就躺在那里，多少件、多少天、多少钱，一清二楚。
我的核心判断可以浓缩成三句话。第一，库存问题的绝大多数根因在日常动作，不在采购执行。当你发现库存异常时，往回倒推 30 到 60 天，通常能找到那几次没有及时跟上的决策。第二，库存管理的第一道门槛是可见性，不是优化能力。从"看见"到"能行动"之间的衰减率高得惊人，多数团队卡在中间这段。第三，工具不能替代管理，但能决定管理的天花板。它把重复的、可规则的、高频的工作接管过去，让你的人只处理真正需要判断的部分。
如果你现在正准备动手，我建议的下一步顺序是这样的：先花一周时间做一次全链路库存盘点，把 FBA、在途、海外仓、工厂在产四个池子的数字拼到同一张表上，先不管准确度。然后花两天时间，把你所有 SKU 分成核心、常规、长尾三类，给每类定一个安全天数。这两件事不需要任何工具，但能立刻暴露 80% 的问题。做完这两步之后再评估是否需要系统化工具，以及需要什么样的工具，判断会准确得多。
库存管理没有终点，它是一条持续收窄误差的曲线。每一次预警的及时响应、每一次补货判断的修正、每一次滞销的提前识别，都会让这条曲线往更好的方向偏一点。而正是这些日常的、琐碎的、看起来不起眼的动作，最终决定了一家亚马逊店铺能走多远。
读者评论
数据延迟那段很有共鸣。我们也是四个站点，FBA、海外仓、工厂各一套表，周会前两个人拼数据，经常拼完就过时了。但我不太认同所有SKU都做日级预警，上千个SKU每天推一堆异常，运营很快就麻木。实际能落地的是按销量和资金占用分ABC，只对A类核心款做日级，B类周级，C类月级。否则预警系统只会变成新的报表负担。
漏斗图里“能看到FBA可售”100%、“能触发补货”15%，这个衰减很真实。我们上半年也上过库存看板，但批次成本和汇率联动一直没做，因为采购和财务不愿每天维护基础数据。结果毛利算不准，降价清仓时心里没底。我的疑问是，SKU过千后要求三分钟回答任意时点全链路库存，对没有专职数据岗的团队是不是太理想了？
执行层被组织机制卡住这点说得很准。我们之前系统提示某款要降价清仓，运营就是不动，因为降价计入当月GMV，还会拉低毛利考核。后来把滞销处理单独设指标，并给清仓授权，才稍微好转。不过“断货分等级”说起来容易，引流款和利润款的边界经常变，安全库存参数也跟着摇摆。库存管理最终还是得先解决考核和授权问题，不然工具上了也推不动。