2024年初，我帮一家做家居品类的亚马逊卖家做系统复盘。他们全年GMV大概4200万人民币，团队17个人，在深圳龙华。财务给的Q3损益表看起来非常“健康”：广告ACOS从24%降到21%，Listing转化率从11.3%提升到13.1%，退货率还降了1.2个百分点。但净利润比Q2少了38万。
我带着两个运营追了三周数据，最后定位到的不是广告，也不是汇率，而是库存。9月初他们有6个核心ASIN断货，平均断货11天。这6个ASIN贡献了店铺37%的自然流量权重。断货恢复之后，关键词自然排名没有回到原位，等于用后面两个月的广告费，去买回本来免费的那部分流量。
这件事之后，我把“库存管理”提到了亚马逊软件改造的第一顺位，排在广告工具、客服工具、财务工具之前。这篇文章想讲清楚一个判断：对绝大多数年GMV在500万到1亿之间的亚马逊卖家来说，库存管理不是ERP里的一个模块，而是整个数字化改造的起点和主轴。改造顺序搞反了，后面每一分钱都是在填坑。
先把结论摆出来，后面再讲我是怎么得出来的。我复盘过大概30多家中型亚马逊卖家的系统改造项目，改造顺序和最终ROI之间的关系，比大多数人想象的要强得多。
广告要不要加预算，取决于这个ASIN还有多少库存能撑住放量；采购要不要下单，取决于在途、在库、在FBA的可用量和未来30天的预估销量；财务要不要放款，取决于库存周转天数和资金占用；客服要不要关掉某个促销，取决于这个SKU还有没有货可发。
这四个部门每天做的决策，全都依赖同一份库存数据。如果这份数据本身是滞后三天、口径不统一的，那么无论你上多贵的广告工具、多智能的BI，都是在给一个错误的输入做精美的加工。
这是我判断改造顺序的第一原则：先修数据源，再修数据应用。库存就是那个数据源。
很多卖家算库存工具的ROI时，算的是“减少多少滞销库存”“降低多少仓储费”。这些都对，但都不是最大的那块。
最大的那块是：防止爆款断货导致的排名归零。一个日销200单的ASIN，断货14天，恢复后自然排名回到原位的概率我统计下来不到15%。这意味着你前面花的所有广告费、所有Review积累、所有关键词权重的沉没成本，可能一次性损失掉30%到60%。
这笔钱不出现在任何一张财务报表的“成本”科目里，但它真实存在。库存工具最值钱的地方，就是把这笔隐形损失挡住。
我很少见到一开始就“库存管理很烂”的团队。绝大多数团队是从“还能用Excel顶一顶”开始，然后随着SKU数量、店铺数量、平台数量增长，慢慢滑向失控。失控的过程有非常清晰的四个标志性时刻。
我在2023年8月见过一个做厨房小家电的卖家，Prime Day前两周，运营总监和采购主管在会议室吵了三个小时，吵的核心是某个主力款到底备多少货。运营说“去年这个时候日销300单，今年至少翻倍”，采购说“工厂排期只能给8000台”。
最后拍了个中间数，12000台。结果是Prime Day当天日销冲到1400单，第4天断货；同时另一款备了9000台的滞销，到年底还在付长期仓储费。
这不是人的问题，是决策依据的问题。当补货决策依赖两个岗位的经验和立场博弈时，你无法在旺季这种高频决策场景里保持稳定。
这是最容易被低估的一个节点。当卖家只有FBA时，一切简单。但一旦你同时用FBA、第三方海外仓、国内直发，甚至还有平台仓，库存就开始出现“三本账”。
常见的情况是：ERP里显示某SKU可用库存1800件，FBA后台显示1200件，海外仓那边说还有400件在途。这三个数字本身都不算错，只是口径不同，统计时间不同、是否含预留（reserved）、是否含待入库、是否含不可售（unfulfillable）都不一样。
而这个“口径差”带来的后果，是采购依据ERP下了单，广告依据FBA数据放了量，结果两周后发现自己实际能卖的只有1200件。
做多店铺的卖家一定遇到过：A店铺某SKU快断货了，B店铺同款还压着2000件，但两个店铺的库存数据在系统里是分开统计的，没有人会主动去跨店调拨。因为跨店调拨涉及FBA移除费、重新入仓时效、两头的人工，算下来不一定划算。
不划算的判断往往是错的。我帮一个卖家算过一次：把一个滞销店铺的1600件货通过移除再入仓的方式转到爆款店铺，全部成本加起来约2.9万元，但这批货在爆款店铺两个月内出清，贡献毛利约11万元。问题不在于划不划算，而在于你根本没有这个视角，你的系统不告诉你“这两笔库存其实是同一批货”。
这是我认为库存管理彻底失控的标志。同一周，运营在开会讨论怎么清掉三个滞销ASIN，采购在紧急催一款爆款的空运补货。两件事发生在同一个公司、同一个仓库、同一批资金上，但没有任何一个系统把这两件事关联起来告诉你：你清库存收回的现金，正好可以覆盖空运的溢价。
我见过一个卖家，2024年2月光是空运溢价就花了41万，同期滞销库存占用资金超过600万。如果这两件事能被放在同一张现金流视图里，至少有一半的空运是可以避免的。
这一节是我这些年看项目踩坑最密集的地方。我把它整理成七条，每条都对应一个我真实见过的失败案例。
这是最普遍的误区。很多卖家觉得“我都上了ERP了，库存模块不是现成的吗”。问题在于，传统ERP的库存模块设计逻辑是“记账”，不是“决策”。
它擅长告诉你“现在有多少”，不擅长告诉你“你该补多少、什么时候补、补到哪个仓”。前者的技术难度很低，后者需要销量预测、季节性建模、物流时效建模、安全库存计算。这是两个完全不同的产品能力。
我的判断标准很简单：如果一个库存模块只能导出报表，不能生成带时间点的补货建议，它就只是账本，不是工具。
对接能力是及格线，更新频率才是分水岭。我见过两个系统都能对接亚马逊SP-API，但一个每6小时同步一次，一个每30分钟同步一次。
在平时，这个差别无所谓。在Prime Day、黑五这种场景下，6小时的延迟意味着你看到的库存数据可能已经过期了一个爆单周期。你在早上9点看到的“还有1500件”，到下午3点可能只剩300件了，而你的系统还在按1500件给你算补货建议。
准确率当然重要，但它只回答“数字对不对”，不回答“决策对不对”。我见过库存准确率99.2%的系统，但补货建议的准确率不到60%，因为它用的还是最简单的“过去30天日均销量×安全天数”模型，完全没有考虑季节性、促销排期、竞品动作。
选型时我更关注三个指标：库存数据新鲜度（分钟级/小时级/天级）、补货建议采纳率（运营实际采纳了多少条建议）、缺货预警提前天数（平均提前几天预警）。
“支持20个平台”听起来很美，但每个平台的库存逻辑都不一样。亚马逊有FBA、有预留、有长期仓储费阶梯、有IPI考核；其他平台可能是自发货为主。一个系统如果要兼顾20个平台，往往每个平台都做得很浅。
我的建议是：先用主力平台（通常是亚马逊）的深度能力把库存管明白，再考虑扩展其他平台。顺序反过来，你会得到一个什么都能接、什么都不精的系统。
很多系统的补货建议是停在一个报表里的。运营看到建议，复制到微信，发给采购，采购再手工录入到另一个系统。这个链条上每多一次人工搬运，就多一次信息损耗和延迟。
我统计过，一个中等规模卖家的补货链路，从“系统生成建议”到“采购实际下单”，平均耗时是2.7个工作日。在旺季，2.7天足以让一个爆款从“需要补货”变成“已经断货”。
这是组织层面的坑。如果库存改造由IT部门主导，通常会变成一个“系统上线”项目；如果由运营或供应链主导，才会变成一个“决策改善”项目。
我见过太多“系统上线成功、业务指标没变”的案例。原因几乎都一样：系统上线了，但没有人改工作流程，运营还是用Excel，因为“用惯了”。
库存系统切换最忌讳“一刀切”。老系统停掉、新系统上线、中间没有任何并行期，一旦新系统在某个SKU上算错了补货量，你损失的是真实的货和真实的钱。
我的经验是至少保留一个完整补货周期的并行期，通常是45到60天。这段时间两套数据同时跑，每周对比差异，找到差异原因再逐步切量。
前面讲了误区和场景，这一节讲我实际用的判断框架。这套框架我在多个项目里反复调整过，目前是五个维度，每个维度都有明确的观察点和阈值。
我会直接问供应商两个问题：一是SP-API的库存同步最小间隔是多少；二是增量同步还是全量同步。
全量同步在SKU数量少时没问题，但当你SKU超过3000个，全量同步的耗时会显著上升，很多系统为了保证不超时，就不得不拉长同步间隔。这是一个隐藏的技术债。
我的阈值：库存核心字段（可售、预留、在途）同步间隔不超过60分钟，且支持增量同步。低于这个标准，在旺季会出问题。
很多系统会宣传“AI智能预测”，但我更关心的是：系统能不能告诉我，为什么建议补这个数量。
如果一个系统给出“建议补货1280件”，但点进去看不到计算过程，运营是不会信任它的，不信任就不会用，不用就等于没有。我见过太多AI预测模块被弃用的案例，都是因为不可解释。
好的补货建议应该能拆解成：基础日均销量、季节性系数、促销排期加成、物流时效、安全库存天数、当前可用库存、在途库存。这七个变量都应该是可见、可调的。
这一条决定了你能不能发现跨店调拨的机会。如果系统只能按店铺维度看库存，你就永远发现不了“A店滞销、B店缺货”这种结构性机会。
我通常会测试一个场景：同一个SKU在三个店铺、两个仓库都有库存，系统能不能在一个界面里把总量、各仓分布、各店可售都列出来，并且给出调拨建议。
这是我最看重的一条。一个库存系统如果只做预警不做动作，价值至少打对折。
理想的状态是：系统识别到某个ASIN在未来7天内会断货，自动降低该ASIN的广告预算（或者通知广告系统降预算），同时在补货建议里把这个SKU排到最前面，并且把建议推给采购负责人。
这条链路打通了，库存工具才真正从“账本”变成“控制系统”。
最后一条经常被忽略，但非常关键。库存系统是主干系统，一旦切换失败，影响的是发货和销售。所以我会特别关注：数据能不能导出、历史数据能不能迁移、切换过程中能不能并行、如果失败能不能退回。
一个不支持数据导出的SaaS，本质上是在用你的迁移成本锁定你。这不一定是恶意，但对你的改造风险是实打实的。
前面讲的是框架，这一节我讲一个我深度参与过的实际改造，把过程、数据、失败的地方都摊开讲。这个案例我选的是数跨境这条路线，因为它比较典型地代表了“从库存切入、以数据口径统一为前置条件”的改造思路。
这家卖家做户外用品，亚马逊美国站为主，同时有日本站和欧洲站。SKU数量约2400个，其中活跃SKU约900个。团队规模31人，运营12人，采购4人，仓配5人。
改造前的基线：库存周转天数68天，年化库存资金占用约1850万元，FBA长期仓储费年支出约47万元，缺货率（按月统计的缺货ASIN占比）11.3%，滞销库存（超过180天未动销）占库存金额的19%。
更关键的是人工耗时：每周补货会议平均耗时6.5小时，涉及运营、采购、供应链三个岗位；每月库存对账（ERP与FBA与海外仓三方核对）平均耗时约26人时。
第一阶段我们没有做任何“上线展示”，只做了一件事：把FBA、海外仓、ERP三方的库存字段逐一对齐，定义清楚“可售库存”“预留库存”“在途库存”“不可售库存”在系统里的确切含义。
这个阶段最枯燥，也最重要。我们最终整理出一份37个字段的口径对照表，其中11个字段在三方系统里的定义是不一致的。比如“在途”，ERP指的是已下单未发货，FBA口径包含已发货未入库，第三方海外仓口径只算已清关的。
这11个字段如果不统一，后面所有的补货计算都是错的。这也是我为什么在前面反复强调“先统一口径、再自动化”。
第二阶段上线了补货建议模型，但设了一个硬规则：所有建议必须由采购确认后才能转为订单，系统不自动下单。
这个阶段的目的是建立信任。我们每周会拉一次对照表：系统建议量 vs 采购实际下单量，逐条看差异原因。前三周差异率高达42%，到第六周降到11%。
差异的主要来源有三类：一是系统不知道的促销计划（比如临时报了一个秒杀）；二是工厂最小起订量限制；三是新品没有历史销量，模型只能给保守值。这三类差异我们后来分别做了配置项。
第三阶段开始做闭环。系统识别到断货风险的ASIN，会自动在站内推送预警给对应的运营和采购，同时触发一个“广告降速”的待办事项。
这一阶段我们没有做全自动降预算，原因是广告降速本身有副作用，降速后排名会掉，恢复需要时间。所以我们把它做成了“建议+一键执行”，而不是自动执行。这是我个人在库存自动化上的一个保守判断：涉及销售端的动作，宁可多一次人工确认。
改造后第6个月的数据对比（与改造前3个月均值对比）：库存周转天数从68天降到41天，年化库存资金占用从约1850万元降到约1220万元，降幅约34%。
FBA长期仓储费从年化约47万元降到约18万元。缺货率从11.3%降到4.1%。滞销库存占比从19%降到8.6%。
人工侧的变化也很明显：每周补货会议从6.5小时压缩到2.8小时，每月三方对账从26人时压缩到约7人时。
| 指标 | 改造前 | 改造后（第6个月） | 变化幅度 |
|---|---|---|---|
| 库存周转天数 | 68天 | 41天 | -39.7% |
| 库存资金占用（年化） | 约1850万元 | 约1220万元 | -34.1% |
| FBA长期仓储费（年化） | 约47万元 | 约18万元 | -61.7% |
| 缺货率（月度ASIN占比） | 11.3% | 4.1% | -7.2个百分点 |
| 滞销库存占比 | 19.0% | 8.6% | -10.4个百分点 |
| 每周补货会议耗时 | 6.5小时 | 2.8小时 | -56.9% |
| 每月三方对账耗时 | 26人时 | 7人时 | -73.1% |
我不想把案例讲得太漂亮，因为真实的改造从来不是一路顺利。这家客户在改造过程中至少有三个明显的坎。
第一个坎是采购团队的心理抗拒。第31到60天那段时间，采购主管私下跟我说“系统建议我为什么要听”。这个问题的根源不在人，在于我们没有提前让他参与模型参数的设计。后来我们让他主导了“工厂最小起订量”和“账期约束”这两个配置项，他的态度才转变。
第二个坎是新品没有历史数据。户外用品有明显季节性，新款上市时模型给的建议非常保守，导致前两个月有两个新品上架即断货。后来我们引入了一个“同类目相似款”的迁移参数，用老款的季节曲线去推算新款，才缓解了这个问题。
第三个坎是跨店调拨的执行阻力。系统能识别出调拨机会，但仓库端不愿意做，因为涉及移除、重新贴标、重新入仓，工作量真实存在。最后是靠把调拨收益的一部分计入仓库团队的考核才推动下去。
框架和案例讲完，这一节给可以直接执行的分层建议。我按GMV规模、平台结构、经营模式三个维度来分，你可以对号入座。
这个阶段的卖家SKU通常在200个以内，活跃SKU可能只有几十个。上任何复杂系统都是浪费，你需要的是三张表：一张销量跟踪表、一张在途表、一张补货计划表，加上固定每周一次的补货会议。
关键动作是：把补货决策从“临时拍脑袋”变成“每周固定节奏”。这一条做到，比上任何工具都有用。这个阶段的目标不是自动化，是建立可重复的决策节奏。
这是改造收益最明显的区间。SKU数量通常在500到3000之间，人工已经明显跟不上了，但还没到需要自研的复杂度。
建议的动作顺序：先做口径统一（2到4周），再上补货建议（保留人工确认，至少6周），最后做预警联动（第3个月开始）。参考像数跨境这类把库存口径统一作为前置步骤的平台，重点考察它的补货建议是否可解释、是否支持多店多仓统一视图。
这个阶段的卖家通常有自己的IT能力或至少有一个技术负责人。我的建议不是全自研，也不是全采购，而是混合：核心的库存账本和数据口径自己做，补货算法和预警引擎用成熟工具。
原因是：库存口径是你公司的业务机密，也是你和所有系统对接的接口，这部分自己掌握更安全；而补货算法涉及大量的模型迭代，采购成熟方案更经济。
只做亚马逊的卖家，重点应该放在FBA特有逻辑上：预留库存、长期仓储费阶梯、IPI考核、库容限制。这些是亚马逊独有的，通用型工具往往覆盖不深。
多平台卖家（亚马逊+其他平台）的重点则应该放在“统一可售口径”和“跨平台调拨”上。你真正需要的是把所有平台的库存汇总成一份“我实际能卖多少”的视图，而不是每个平台各自的报表。
精品卖家SKU少、单SKU销量大，库存改造的核心是缺货预警和补货节奏。你的关键指标是缺货率，因为一个爆款断货的损失远大于一批货滞销。
铺货卖家SKU多、单SKU销量小，核心是滞销识别和批量清退。你的关键指标是滞销占比和资金周转，因为你的库存是分散在几百上千个SKU上的，任何一个SKU断货都无所谓，但整体资金占用是致命的。
这两种模式选工具的侧重点完全不同，铺货型卖家如果去买一个主打精品补货模型的工具，会觉得处处不顺手。
建议讲完了，这一节讲取舍。取舍的意思是：你不可能全都要，必须放弃一些东西。我把库存改造中最常遇到的四个岔路口列出来，每个都给出我的倾向和理由。
这个问题的答案取决于两件事：你的库存逻辑是不是你的核心竞争力，以及你有没有持续迭代的技术团队。
如果你的库存逻辑只是标准的“销量预测+安全库存”，那没有任何自研的必要，采购成熟方案的成本可能只有自研的十分之一。
但如果你的供应链有特殊约束，比如账期结构复杂、有自有工厂排期、有多级分销，那通用的补货模型一定跑不准，这部分就需要自研或者至少深度定制。
我的倾向是：中小卖家一律采购，除非你的年GMV超过5000万且有专职技术负责人。自研最大的风险不是初始成本，是持续维护成本，很多卖家在自研上线一年后发现没人维护了。
这一条我态度很明确：并行双跑，哪怕多花两个月。
库存系统是主干，一旦切换失败，影响的是发货、是销售、是客户体验。我在前面提过，至少保留45到60天的并行期。这段时间你会觉得效率降低了，因为要维护两套数据，但这是买保险。
唯一的例外是：你现在的系统已经完全不能用了（比如数据错误率高到无法信任），那这时候全量替换反而是更优选择，因为并行的前提是“至少有一套是可信的”。
这个取舍我见过太多团队纠结。我的答案取决于你的业务处于什么阶段。
如果你是旺季前要改造（比如8月开始改，准备黑五），那优先上线速度：先上核心的库存视图和断货预警，补货模型可以先用简化版。
如果你处于业务平稳期，那优先功能完整度：把口径统一做扎实，把补货模型的可解释性做透，不要为了快而留技术债。
判断标准是：如果未来6个月内有一个你输不起的销售节点，选速度；如果没有，选完整度。
库存管理有一个反直觉的地方：精细化程度越高，需要的人力不一定越少。系统能识别出每一个SKU的调拨机会，但如果没有人去执行调拨，这个识别就是无效的。
我的建议是分层：把SKU按销售贡献分成ABC三类，A类（贡献80%销售额的20% SKU）做精细管理，允许人工介入；C类（长尾SKU）用规则化管理，比如统一的补货阈值和安全天数，不追求最优。
这样做的结果是，你的团队精力集中在最值钱的那批SKU上，而不是被2400个SKU的平均管理成本拖垮。
写到这里，我想把整篇文章的核心观点收一下。前面讲了结论、场景、误区、框架、案例、建议、取舍，如果只能记一句话，我希望是这一句：
库存管理软件改造的本质，不是把Excel换成系统，而是把补货决策权从“人的经验”重新分配给“数据+规则+人的判断”。
这个重新分配的过程有三个层次。第一层是数据层，把口径统一、把数据实时化；第二层是规则层，把补货逻辑显性化、参数化；第三层是组织层，把决策权限、审批流程、考核方式都相应调整。三层缺一层，改造都会停在半路。
我见过太多项目卡在第二层和第三层之间，系统上了，模型跑了，但采购还是不信、运营还是用Excel、仓库还是不愿意调拨。这不是技术问题，是组织问题，而组织问题的解决周期通常比技术问题长三到五倍。
第一个判断：库存改造的收益释放是滞后的，通常在第3到第6个月才明显。前两个月你只会看到成本，看不到收益，这个时候最容易动摇。我在案例里展示了这条曲线，第12周之前指标几乎没有改善，但从第12周开始加速。坚持过这个拐点是关键。
第二个判断：补货建议的采纳率比库存周转率更适合当先行指标。库存周转反映的是结果，采纳率反映的是流程是否真的变了。如果采纳率不涨，周转率的改善往往是短期的，不可持续。
第三个判断：多店多仓的统一视图，价值被严重低估。大多数卖家关注的是预测准确性，但真正带来结构性收益的，是“看见跨店调拨机会”这件事。它不需要任何算法，只需要一个统一视图。
如果你读到这里觉得该动手了，我建议不要一上来就选工具。先做这14天的动作，做完之后你对自己该买什么会非常清楚。
做完这14天，你会拿到一份属于自己的需求清单，而不是拿着别人的功能列表在猜。
最后再说一句关于工具选择的判断。像数跨境这类把库存口径统一、多店多仓视图、补货建议可解释性作为核心能力的平台，适合的正是年GMV在500万到1亿之间、SKU在500到5000之间、已经开始被库存问题拖累但还没到自研规模的卖家。如果你的情况在这个区间之外，宁可先做14天清单，也不要急着买。
库存改造没有最优解，只有和你的规模、模式、组织能力匹配的解法。改造顺序上先库存、后其他，这个顺序我做了三十多个项目，没有变过。
我在深圳做亚马逊运营三年多，去年被拉进公司内部系统改造的项目组。老板一开始的想法是先做广告投放自动化，理由是 ROI 好量化、做出来能立刻看到效果。但真推进了两个月才发现，广告花多少预算其实是被库存和补货节奏卡着的，库存数据不准，广告端再智能也是白搭。
因为库存数据是整条链路的源头，它同时被订单履约、采购补货、财务核算、广告预算分配四个下游消费，口径一旦不准，下游全是脏数据。
可执行的第一步是做一次库存口径盘点：把在库、在途、FBA 可售、FBA 预留（含客户订单、调仓、入库处理中）、海外仓、本地仓、次品待处理全部列成一张对照表，逐个数字确认它来自哪个系统哪张表、字段级负责人是谁。盘点完通常会暴露三到五处口径冲突，比如运营看的可售数扣没扣预留、采购在途是否含已发货未入仓。
这些冲突不解决，先做订单或广告只会把错误放大。判断顺序的简单标准是：哪个模块的数据被其他模块引用次数最多，就先改它。
我在选型阶段前后约了七八家供应商做演示，PPT 都做得很漂亮，每家都说自己支持多平台多店铺。可我心里没底，因为 demo 环境里的数据都是他们准备好的，干净得像样板间。我想知道有没有一套能在现场就把水分挤出来的判断方法。
区分度高的指标有四个，建议全部现场验证。第一是多店铺多站点 SKU 映射能力，要能支持一个商品对应多个 FBA 货件号、多个海外仓 SKU 编码的一对多映射，而不是强制你改编码去适配系统。
第二是库存变更事件的拉取方式和幂等处理，要问清楚接口的调用频率、增量还是全量、失败重试和去重怎么做，这直接决定大促期间会不会超卖。第三是批次、效期、货权维度，同一 SKU 能否按批次分开核算成本。第四是对账数据能否按口径导出并追溯到原始单据。
区分度低的是界面美观度、AI 预测准确率 90% 以上这类没有说明口径的宣称。最有说服力的做法是让对方拿你的一批真实数据现场跑一遍：给 200 个 SKU、3 个站点、2 个海外仓的历史数据，看导入后的库存准确率能否对上你自己账上的数，误差超过 1% 就必须让对方解释差异出在哪张表。
我们内部为这件事吵过好几轮。技术团队觉得买现成的受制于人，业务团队嫌自研排期太慢。我最想知道的是，有没有一个相对客观的算法，能算出我们这种体量到底该选哪条路，而不是谁嗓门大听谁的。
先按库存变更事件量估算规模：日均订单行乘以每单触发的库存变更次数，再加上每天的入库、调拨、盘点操作数。如果这个量级在日均五千次以下，自研通常不划算，因为多平台接口对接、请求节流、失败重试、幂等去重、跨系统对账这套基础设施，光搭建就要两到三个人月起步，之后还有每月持续的接口维护成本。
可以给一个粗略的年度成本口径：自研首年约等于后端 1.5 人年加前端和测试各 0.5 人年的人力，加上云资源和接口维护；采购类工具一般按店铺数、SKU 数或订单量阶梯计费，要提前问清超量后的单价。
二次开发的关键判断点是对方有没有开放库存事务表和 webhook，如果只能进后台点按钮、没有对外接口，这种二开最后一定会退化成人工导数，反而比纯采购更贵。
上线那天大家都很开心，群里刷了一屏。但一个月后老板问我，这套东西到底省了多少人、少了多少超卖，我一下答不上来，因为上线前根本没留基线数据。这个坑我踩过一次，想搞清楚下次该怎么设计验收口径。
关键是在上线前先冻结一组基线指标，连续取三十天数据。至少要包含这五项：库存准确率，用盘点差异 SKU 数除以总 SKU 数；断货率，用缺货 SKU 天数除以可售 SKU 天数；冗余库存占比，用库龄超过 270 天的库存金额除以总库存金额；超卖订单数；
库存相关人工工时，把每周盘点、补货、对账的小时数记下来。上线后用完全相同的口径再取三十天做对比，中途不要换统计方法，否则数字没有可比性。参考经验值是一套改得比较扎实的库存模块，库存准确率能稳定在 98% 以上，人工对账工时能砍掉一半左右。
如果上线六周后超卖订单没有下降、对账还得靠手工 Excel 拼表，那大概率是数据链路没打通，不要用推广期还没适应这种理由把它糊过去。
读者评论
我们也是年GMV六千万左右的家居卖家，文章里说的四个部门口径不统一太真实了。但我们实际情况是采购和运营用同一套ERP数据，可财务那边算资金占用还是自己另起一套表，每次对账都要扯半天。想问一下，统一口径这件事在组织上到底该由谁来牵头？运营推不动财务，IT又不懂业务，这个协调成本文章里好像没展开讲。
断货导致排名滑落的说法我有不同看法。我们做过一次测试，一个日销80单的Listing断货9天，恢复后自然排名大概两周就回来了，当然广告费确实多花了一些。我觉得排名能不能回来跟类目竞争度和断货时长关系很大，文章里说恢复到原位概率不到15%，这个数字是不是偏悲观了？样本是不是集中在竞争特别激烈的类目？
并行期45到60天的建议我认同，但实际操作中最难的不是跑数据，是人。我们老系统用了三年，运营闭着眼睛都能操作，新系统上线后光培训就花了三周，中间还有人不愿意切换。后来是靠老板强制要求所有补货必须走新系统才推下去的。所以我觉得库存改造最大的坑可能不是工具选型，是内部习惯的惯性。