2024年8月，我服务的一家服饰品牌做了一场女装直播，主推款库存显示还有3000件，运营在直播间喊“最后200件”时，后台订单已经拍下了4200单。直播结束后仓库一盘点，实际可发库存只有2600件，超卖1600单。当晚的售后群直接被退款和投诉刷屏，店铺评分从4.8掉到4.6，主播第二天开播时流量掉了将近四成。
这个案例不是个案。我过去一年接触过二十多个直播团队，发现一个反直觉的事实：直播库存失控，从来没出现在“库存不够卖”的时候，而是出现在“库存数据对不上”的时候。 大多数团队把问题归结为运营手速慢、平台规则复杂、或者ERP系统不好用，但真正的问题往往出在一条看不见的链路里，数据库存、直播间可售库存、实际可发库存三者之间，存在着一条极易错位的数据管道。
这篇文章不打算讲“怎么在后台设置库存”这种浅层操作。我想从数据链路的角度，拆解直播带货实时库存管控的底层逻辑，告诉你为什么你的直播间会在最不该出问题的时候出问题，以及怎么用一套可落地的框架把库存风险管住。
先讲核心结论：直播间库存管的是什么
我在给企业做数据方案时反复讲过一句话：直播间里显示的库存数字，不是一个“仓库事实”，而是一个“计算结论”。 这个结论由数据库存、渠道同步策略、平台展示规则、用户下单行为四者共同决定。任何一环发生变化，都会导致屏幕上那个数字失真。
库存问题的本质是“数据一致性”问题
我在九数云做企业数据分析项目时发现，大部分商家对库存的认知停留在“总仓还有多少货”这个层面，但直播电商的库存逻辑完全不是这样。直播间同时存在三笔库存：
这三笔数字永远不可能完全相等。同步存在延迟，锁定有时效窗口，不同渠道之间还会互相抢占。管好直播库存的目标不是让它们完全一致，而是把三者之间的差异控制在业务可接受的范围内。
实时库存管控有三个层级
根据我接触过的项目经验，可以把直播库存管控分成三个成熟度层级，大多数团队处在第一层，少数成熟团队到了第二层，能到第三层的很少：
（1）人工盯盘层：运营盯着直播间实时销量，每隔一段时间手动调整可售库存。适合SKU少、场次少、客单价高的直播。
（2）规则自动化层：通过ERP或库存管理工具设置自动同步、库存预警、超卖熔断规则，减少人工介入。适合SKU较多、多平台同时开播的商家。
（3）数据中台层：把库存、订单、售后数据打通到统一的数据平台，做数据回填、异常监控和智能决策。这是少数头部商家和大量铺货型企业的做法，也是我在九数云白皮书中看到的企业数字化转型方向之一。
库存管控的真正目的
分清这三层之后，你就会理解：直播库存管控不是一个“改数字”的动作，而是一套从数据源头到用户界面的完整风控链路。管得好，库存是直播间的发动机；管不好，它就是一颗定时炸弹。
数据库存与直播间库存对不上的真实场景
我真正开始深入研究这个问题，是在帮一个连锁零售客户做库存数据清洗的时候。他们的财务每天都要手工核对各渠道的销售订单和库存变动，月底经常差出几千件货，怎么都对不上账。后来我去仓库和IT部门聊了一圈，才发现问题根本不在仓库，而在数据链路。
一条典型的库存数据链路
数据库存到直播间库存，中间通常经历这样几步：ERP系统记录一次库存扣减，然后通过接口推送数据到中台，中台再同步到抖音、快手等直播平台的商家后台，最后由商家后台把可售库存展示给用户。每一步之间都有时间差。ERP扣减可能只需要50毫秒，但同步到直播平台可能需要五秒、五分钟，甚至更久。如果运营在直播中途手动改过一次价格或库存，整个链路又要重新对齐。
我在多个项目里实测过不同平台的库存同步延迟，结果差异很大。有些平台接口支持实时同步，延迟在秒级；有些平台为了性能考虑，限制了调用频次，高峰期延迟能到五分钟以上。这个差异就是“数据库存还有5000但直播间可拍只有2000”或者反过来“数据库存只剩800但直播间还在卖1200”的根本原因。
一个我从客户项目里整理出来的典型超卖路径
这家零售客户曾经在双十一当天出现过一次严重的直播超卖。复盘之后，我们把整个事件的时序还原了出来：
这个问题最坑的地方在于：每一步操作看起来都没有错，但每一步之间都没有形成实时的数据闭环。运营在直播间里改库存，改的是“前台展示值”；ERP扣减的却是“全局数据库存”；两者之间的差额，就是超卖风险累积的空间。
为什么Excel和人工背不下来这个锅
很多人会问：既然数据链路这么复杂，我每天用Excel记录库存变动，直播前人工核对一次行不行？我的答案是：低频次、SKU少的直播可以，高频次、多渠道的直播绝对不行。原因很简单，人工核对的频率永远跟不上直播间消耗库存的速度。
我们测过一组数据：一个运营在直播间同时盯3个SKU时，手动改库存的响应速度还能维持在2分钟以内；但SKU数量增加到10个以上，响应速度就会直线下降到5分钟以上，且出错率明显上升。而一场正常的直播，一个爆款SKU的库存消耗速度是每秒零点几件到几件。5分钟的响应延迟，就意味着拦截不住超卖。
拆解三个常见的库存管控误区
每次和企业聊库存问题，我听到最多的解释就那么几句：我们的运营改慢了；平台接口有bug；ERP系统不好用。但把问题拆开看，这些话都只解释了表象。我总结了三个最典型的认知误区：
误区一：“超卖是因为运营手速不够快”
这可能是最常见也最危险的理解。超卖出现后，团队的第一反应往往是加强人工盯盘，要求运营“盯紧一点”，甚至安排两个人同时盯一个SKU。这不是在解决问题，而是在给一个本身就不可靠的机制加保险。
我的判断逻辑是：如果一次直播的SKU总数超过20个，任何单纯依赖人工盯盘的库存管控方案都是不可靠的。 运营的注意力是有限的，卖爆的时候盯着销量看，卖不动的时候就去看评论区了。真正的问题不是运营不够努力，而是直播间的库存状态本身是一个高并发实时数据流，人类不适合逐秒处理这种数据。
误区二：“超卖是系统同步延迟造成的，没办法解决”
确实，任何系统的同步都有延迟，这是由分布式系统的CAP理论决定的。但同步延迟不等于无解。我们完全可以通过“预占库存”“安全库存缓冲”“超卖熔断”这些机制来对冲延迟的影响。
我在给企业做数据中台方案时，经常打一个比方：你不可能让每一辆车都不迟到，但你可以通过在地铁站外增加排队栏杆、提前广播限流信息，来保证站台不拥堵。库存同步同理。延迟不可消除，但可以通过机制设计把它带来的风险隔离掉。
误区三：“只要上了ERP，库存就不会出问题”
ERP解决的是企业内部库存记录的准确性，但直播间的库存展示和订单扣减发生在平台侧。ERP的数据要经过接口同步才能到达直播间。而且很多ERP的库存模型是围绕传统零售设计的，缺少直播场景下的“渠道预占”“直播间独立库存池”“订单支付前锁定”这些概念。
所以我经常建议客户：先别急着换ERP，先搞清楚你的库存模型是否需要支持多渠道同时售卖、是否支持订单支付前的库存预占、是否支持超卖拦截。 如果这三个能力都不具备，换系统只是把同样的问题换了个地方重新出现。
专业判断框架：用“库存数据链路”视角看直播库存
当我面对一个直播团队的时候，我不会先问“你用的是什么库存系统”，而是会先问三个问题：你的数据库存在哪里？你的直播间库存怎么同步？同步失败的时候谁来兜底？这三个问题的回答，决定了这个团队直播库存管理的底层能力。
第一问：数据库存在哪里，是否唯一
很多中小商家其实说不清楚自己的“数据库存”到底在哪。问起来就是“就在ERP里”，但实际销售在抖音，订单数据在抖音后台，仓库发货在另一个系统，财务对账又用一套Excel表格。这些数据之间经常不一致，连“目前还有多少库存”都没有唯一答案。
我建议的做法是：明确一个“库存数据主源”，所有渠道的库存展示和订单扣减都必须回到这个主源上取数和回写。 在我参与过的项目中，有的团队把ERP作为主源，有的团队自建了中台作为主源。不管选哪种，关键是全公司只认一套数据，其他系统展示的库存都只能算“视图”，不构成决策依据。
第二问：直播间库存的同步机制是什么样的
直播平台的库存同步通常有两种方式：主动调接口查询，和平台回调通知。主动查询简单但效率低，还要注意平台接口限流；回调通知效率高，但如果回调消息丢失或延迟，直播间库存就不会更新。成熟团队会在两种机制之外再加上一层对账任务，定期把直播间的订单数据拉回来和数据库存对一遍，发现差异立即告警。
我在一个零售客户的项目中给他们搭建过一套自动对账逻辑：每5分钟拉取一次直播间的订单明细，和ERP的库存扣减记录做比对，一旦发现差异超过设定的阈值（比如20件），立即在企业微信群推送告警。上线之后，他们的库存差异发现时间从原来的“月终盘点才发现”缩短到了“5分钟内”，差异金额下降了90%以上。
第三问：同步失败和超卖发生之后，有没有兜底机制
很多团队从来没有想过“库存同步失败之后怎么办”，直到超卖发生才手忙脚乱地启动售后。成熟的直播库存管控方案，至少要有三层兜底：
（1）熔断类兜底：当可售库存低于安全阈值时，系统自动下架商品或关闭购买入口，而不是依赖运营手动改库存；
（2）补偿类兜底：当超卖已经发生时，系统自动锁定受影响订单，生成补偿方案（优惠券、赠品、无理由退款），并通知客服优先处理；
（3）复盘类兜底：直播结束后，自动生成库存消耗、超卖、退款、缺货的复盘报表，为下一场直播的库存设置提供依据。
这三层兜底，我建议所有直播团队都至少先把第一层落地。因为熔断机制不需要特别复杂的系统改造，大部分电商平台的后台都支持设置最大可售数量或库存预警线，关键在于你是否愿意设一个“宁愿少卖也不超卖”的库存水位。
具体案例与数据观察：三类典型的直播库存失控现场
这几年我参与了不少企业的数据咨询和库存管控方案设计，亲眼见过大量库存失控的案例。我把它们归类成三种典型模式，每种模式的成因、表现和应对方式都不一样。
多平台同播型失控：库存被“抢”没的
一家美妆品牌在抖音、快手和视频号同时开播，三个平台共用一个ERP库存池。运营分别在每个平台的后台设置了不同的可售库存，但没有做渠道隔离。结果一场直播下来，三个平台一共卖出了1.3万件，而ERP里的总库存只有8000件。事后复盘发现，根本原因是每个平台的运营都在“自己的后台”看到有库存就继续卖，但库存池是共用的，三个直播间同时在消耗。
这个案例说明一个很简单的道理：多平台同播的时候，必须给每个直播间建立独立的库存池，或者设定“渠道库存上限”。 否则不是库存不够，而是渠道之间互相“踩踏”。
高客单价长决策型失控：订单支付前库存被锁定，导致“看得见拍不了”
另一个案例是一家珠宝品牌，客单价超过5000元，用户从拍下到支付往往要经过几分钟甚至几小时的犹豫。平台默认的锁定时间是30分钟到45分钟，导致大量库存被“已下单未支付”的订单占用。直播间明明显示“仅剩3件”，但实际上这三件已经被别人拍了还没付钱，新用户根本拍不了。
这不是库存不足，而是库存锁定策略和用户决策周期不匹配。对于高客单价品类，我建议把库存锁定时长调短，同时让运营监控“未支付订单”的数据，及时释放未支付库存，避免直播间出现“看着有货买不了”的尴尬。
促销改价触发型失控：一次改价让库存“回到了解放前”
还有一次，一家食品品牌的运营在直播中为了报活动，临时改了商品价格。改完之后发现直播间可售库存从500件变成了2000件，原来是平台在改价时重置了库存同步状态，把之前的扣减记录全部恢复了。运营一开始没发现，等发现的时候已经多卖出去300多单。
这类问题属于典型的平台状态管理缺陷。我的建议是：大促或改价之前，必须先截图记录当前的库存状态；改完价格后，第一时间核对可售库存是否发生跳变。如果团队有开发资源，可以通过平台接口定时拉取库存快照来做自动比对。
直播实时库存管控的行动建议：从开播前到复盘后
讲了这么多案例和框架，下面给出一套可以直接拿来用的行动清单。这套清单是我根据自己参与过的项目实践整理出来的，覆盖一场直播从准备到结束的完整周期。
开播前：做库存预检，而不是只查库存数字
我见过很多团队所谓“检查库存”，就是打开ERP看一眼总库存够不够就开播了。这远远不够。我建议开播前至少完成四件事：
（1）校验主源数据：确认ERP/OMS里的数据库存是准确的，且和仓库实际盘点数据一致；
（2）为直播间分配独立库存池：如果平台支持渠道库存设置，必须给每个直播间划出独立库存，防止和其他渠道互相占用；
（3）设置安全阈值和熔断水位：比如可售库存低于50件时自动触发预警，低于20件时自动下架；
（4）记录库存快照：用Excel或截图把每款商品的初始可售库存、锁定库存、数据库存记录下来，作为直播结束后的对账依据。
直播中：盯“差异”，而不是盯“销量”
大多数运营习惯盯着直播间的在线人数和销量看，但库存管控视角下，更应该盯的是“库存差异值”，也就是直播间可售库存和数据库存之间的差额。当这个差额超过预设阈值时，说明同步出现了问题，需要立即介入。
具体动作包括：
（1）每15-30分钟记录一次各SKU的可售库存；
（2）对比数据库存的变化量和直播间销量，算出两者之间的缺口；
（3）缺口超过安全水位时，立即通知运营暂停售卖、调整库存或启用熔断；
（4）出现价格调整或库存重置操作时，第一时间重新核对库存快照。
直播后：做缺货盘点，而不是直接开始发货
直播结束后，很多团队直接把订单导入仓库发货，等到发不出去了才发现缺货。我建议所有直播订单在进入仓库之前，先做一轮“库存占用校验”：
（1）把直播期间的订单按SKU汇总，和可发库存做对比；
（2）列出缺货SKU清单和缺货数量，标记优先级；
（3）在ERP中锁定缺货订单，不要让仓库先去处理这些订单；
（4）生成一份“直播库存复盘表”，记录实际消耗、超卖、退换货预判数据，为下一场直播的库存设置提供参考。
以下是直播前中后三阶段的完整检查清单，可以直接复制打印：
| 阶段 | 检查事项 | 频率 | 负责人 |
|---|---|---|---|
| 直播前 | 校验ERP库存与仓库实盘数据一致性 | 每场开播前 | 供应链/库管 |
| 直播前 | 为每个直播渠道划分独立库存池 | 每场开播前 | 运营 |
| 直播前 | 设置安全库存阈值和自动熔断规则 | 每场开播前 | 运营/IT |
| 直播前 | 截图记录各SKU初始可售库存 | 每场开播前 | 运营 |
| 直播中 | 记录各SKU可售库存变化 | 每15-30分钟 | 运营 |
| 直播中 | 对比直播间销量与数据库存扣减量 | 每30分钟 | 数据/运营 |
| 直播中 | 监听库存预警消息和熔断触发通知 | 实时 | 运营 |
| 直播后 | 汇总订单SKU与可发库存比对 | 直播结束后1小时内 | 数据/供应链 |
| 直播后 | 锁定缺货订单，标记售后优先级 | 直播结束后1小时内 | 客服/供应链 |
| 直播后 | 输出库存复盘报表 | 直播结束后当天 | 数据/运营 |
不同业务阶段的取舍：别让方法论绑架你的生意
在和很多老板聊完这套方案之后，我最常听到的追问是：那我到底要不要上系统？要不要找外包开发？我的回答是：先算账，再选方案。
取舍一：SKU少于20个的直播间，别上系统，先把规则跑通
如果你的直播以单爆款或少数几个SKU为主，每场直播SKU不超过20个，用平台自带的库存设置功能加上Excel记录就足够了。这个阶段上ERP、上中台、上第三方库存管理工具，都是在为用不到的能力付费。
我的建议是先做好三件事：库存快照记录、安全库存阈值设定、直播后的订单比对。这三件事都用Excel就能完成，但一定要有人负责、有标准动作、有超卖后的处理预案。等这套规则跑顺了，再考虑上工具。
取舍二：SKU上百且多平台同播，必须上库存管理工具
如果你的团队已经发展到每场直播几十上百个SKU，同时在抖音、快手、视频号等多个平台开播，再做Excel和人工盯盘就是在玩火。这个阶段需要引入的至少是支持多渠道库存同步、渠道库存池隔离、超卖拦截能力的库存管理工具或ERP系统。
选型的时候我建议重点考察三个能力：
（1）是否支持按渠道设置独立的可售库存池；
（2）是否支持订单支付前库存占用和超时释放；
（3）是否支持库存同步失败时的自动告警和超卖熔断。
这三个能力缺一个，库存管控就会留下一个口子。
取舍三：自建数据中台还是购买成熟方案，取决于你的数据复杂度
当企业开始自己做数据中台，用九数云这样的数据分析平台搭建库存看板、自动回填数据、做库存分渠道分析的时候，本质上是把库存管控从“救火”变成了“日常经营能力”。但自建中台是有门槛的，需要数据团队，需要不断迭代。
我建议判断标准很简单：如果你的团队已经有专门的运营数据分析人员，或者正在为多个平台、多个仓库的数据对不齐而痛苦不堪，就可以认真考虑引入数据中台或BI分析平台。如果只是单渠道单仓库，先用简洁的工具方案更务实。
写在最后：库存管控的终点，是让用户永远看不到错误
回到开头那个女装品牌的案例。我们后来给这家客户做了一套很轻量但有效的库存管控流程：开播前由供应链在Excel里填写每款商品的初始可售库存和锁定库存，运营在直播中每20分钟记录一次实际销量，系统后台自动比对差异；直播结束后，我们用九数云把订单数据和ERP库存数据做了自动对账，生成缺货清单。这套方案没有投入昂贵的系统改造，却把超卖数量从1600单降到了个位数。
这件事给我的启发是：库存管控做得好，不是体现在你最风光的时候卖了多少，而是体现在你最忙乱的时候有没有出错。 用户永远不会因为你“差点超卖”而感谢你，但一定会因为你“拍下之后发不出货”而离开你。
所以我的建议很直接：下一次直播之前，先花30分钟，把你主要商品的数据库存、直播间可售库存、锁定库存三栏列出来，看看它们之间的差额是多少。如果这个差额超过你的心理底线，就说明你的库存链路需要补课了。先从那四个动作做起，开播前预占、过程同步、自动熔断、超卖补偿，然后再一步步升级你的工具和系统。
库存是直播间的生命线，但对大多数团队来说，它更是一条数据链路。把这条链路管顺了，你才能真正做到“分析有趣，决策有据”。
我在直播间做过运营，经常遇到用户刚拍下就被退款说没货。后台库存明明改了，前台还显示有货，我真的搞不懂数据库存和直播间库存之间到底发生了什么。能不能讲清楚它们中间到底隔了什么？
先说结论：超卖不是“库存不够”，而是数据同步延迟造成了“库存残影”。用户看到的可售库存和数据库里的真实库存，隔了好几步：数据库存→中间同步任务→平台接口→前台缓存→用户手机。中间任何一步没有更新，用户看到的就是旧数据。具体我经历过一次：300件库存，5分钟同步一次，下播超卖76单。
5分钟内卖出250件时，数据库存已经不对了，前台还显示有300件可拍。最后一个用户拍下的瞬间，系统并不知道自己已经没有货了。常见原因有四个：同步频率太长、数据库高并发锁冲突、平台接口频控、多套系统之间数据不同步。其中同步频率是最容易被忽略的，很多人甚至没改过平台默认设置的5分钟同步。
所以管控的目标不是让数字绝对一致，而是让延迟造成的差异尽可能小。当差异仍存在时，用熔断和补偿兜底。
我负责一个小品牌店铺的直播运营，每次开播都手忙脚乱。开播前怕库存不够，直播中怕超卖，下播后又怕对不上账。有没有一套按直播前、中、后三个阶段都能直接落地的库存管理步骤？
有，按三个阶段做动作。直播前做两件事：一是库存快照，把每个要播SKU的品牌库、锁定数、可售数拉出来，用表格记录留底；二是预占，把直播间的可售库存从总库存里切出来，其他渠道不能动，最低配置是在ERP里建一个“直播渠道仓”。直播中做三件事：一是设置安全水位，库存到警戒线（比如5件）就准备下架；
二是打开自动熔断，能交给平台规则就交给规则，不要等人来操作；三是安排一个人专门盯订单异常，出现超卖订单第一时间标记出来，避免漏单。直播后做三件事：一是拉订单和库存流水对账，核对每笔扣除是否一致；二是把超卖订单单独筛出来，走补偿流程；
三是修正数据库存，把直播期间的临时改动回填到ERP，避免第二天数据错乱。用一个表格概括： 阶段核心动作 直播前快照+预占 直播中水位+熔断+盯单 直播后对账+补偿+修正 不管团队多小，至少把直播前快照和直播后对账做了。这两个动作成本最低，能挡住80%的常规问题。
我们团队比较小，买不起库存系统，一直靠运营手工改后台库存。直播时一个人盯着销量，看得差不多了就去后台改库存，但总是有延迟，已经超卖过好几次。用Excel和人工管理库存真的不行吗？还是有什么办法能减少出错？
能撑住，但有前提：单场SKU少于20个、单平台直播、单场订单比较平稳。超过这个范围，Excel和人工就成了整条链路最慢的一环。人工改库存有三个致命问题：一是延迟不可控，运营发现库存不多了，到打开手机找到商品改成下架，最快也要几十秒，这几十秒足够冲进几百单；
二是没有并发处理能力，两个人同时操作一个表格，数据就会互相覆盖；三是没有熔断，人工只会“改小库存”，很少能立刻“下架商品”，而真正能拦住超卖的是下架。如果你暂时没有预算上工具，折中方案是把Excel当“快照工具”而不是“实时台账”。
直播前用Excel记录每个SKU的可售数，直播中每次调整都在表格里登记时间；同时把平台自动上下架的规则打开，设置“库存≤5件自动下架”。再配合平台自带的“库存预警”提醒，能把超卖概率降一半。
判断标准很简单：如果一场直播超卖超过2次，说明这套人工打法已经到极限了，该考虑用平台库存同步API，或者第三方库存工具。
我们刚起步的店铺没什么预算，怕上系统太贵也怕太复杂。我想先用最低成本把库存管起来，如果只做一个动作或者只上一个最便宜的工具，应该先做哪一步？有没有一个从零开始就能用的最低配置清单？
我的建议是分三步，从0元开始。第一步，直播前库存快照。用免费表格拉出每个SKU的总库存、锁定库存、可售库存，直播前打印出来或者放到共享文档。快照不需要实时更新，它的作用是给后面所有决策一个基准线。成本0元。第二步，直播中人工熔断点。
给每个SKU提前标出“安全水位”，比如5件，到了水位立刻在平台后台点击“下架商品”，不是改库存数字，而是直接停售。这一步的人工成本极低，但能挡住最危险的超卖。第三步，直播后对账。下播后把订单数据导出来，对比库存快照，把差异一列列标出来。
只要你坚持做三次直播复盘，就能发现自己业务里最容易出问题的SKU。这三步做完之后，再考虑平台自带的库存同步设置，把同步频率从5分钟改成1分钟。如果SKU超过20个、多平台同播，再投入API同步工具，几千到几万一年。别再让运营手动改库存了，他们应该盯流量，而不是做打字员。
读者评论
文章里那个女装直播超卖的案例太真实了，我也遇到过类似情况。直播间喊着限量，后台订单却比显示库存多出一大截，最后只能一个个打电话道歉。关键问题确实是数据不同步，运营改的只是前台数字，ERP扣的是总库存，中间差出来的就是风险。
作为运营，我深有体会。之前一直以为是手速慢或者平台延迟，看了文章才意识到是数据库存、可售库存和锁定库存三者之间的链路没打通。尤其是SKU一多，人工根本盯不过来。现在准备尝试设置安全库存和超卖熔断，而不是光靠人肉盯着。
文章提到的三个管控层级很实用，我们团队目前就在人工盯盘层，确实准确率低，一场直播下来累得不行。数据中台层的成本虽然高，但对比超卖带来的损失和售后成本，其实更划算。打算拿这个框架去和老板申请预算，先做规则自动化。
最认同的是“先别急着换ERP”这个观点。我们公司之前就是库存对不上就怪系统，换了一次还是有问题。后来才发现是渠道间没有库存隔离，抖音卖着卖着把天猫的库存也占了。现在先把主数据源定清楚，再做自动对账，差异发现快多了。
文中那个阶梯面积图很直观，三条线之间的间距就是超卖风险。我复盘了我们上次大促，情况和那个案例几乎一样，运营改库存和ERP扣减之间差了好几分钟，等到预警触发已经超卖几十单。现在每天直播前都强制做一次库存数据核对，至少把差异控制住。