电商库存落地清单：缺货预警相关的核心功能事项
电商库存预警最容易被误解成“库存低于 100 件就发一条消息”。我在参与多渠道库存梳理时见过更棘手的情况：仓库实物还有 312 件，系统可售库存只剩 86 件；采购单显示已下单 500 件，但供应商延期 8 天；运营每天收到几十条低库存提醒，却没有一条明确写出谁负责、何时处理、是否已经补货。真正有效的缺货预警，不是提醒数量，而是把库存变化转化为可执行的补货、调拨、限售和履约决策。
如果系统只判断“当前库存是否低于阈值”，它最多完成了风险识别的第一步。它不知道这些库存是否已经被订单锁定，也不知道在途商品能否在缺货前到仓，更不知道促销开始后销量会不会突然放大。
因此，我判断一套电商缺货预警功能是否成熟，首先不会看它能发送多少种通知，而会看它能否完整回答五个问题：当前真正可售多少、按照当前速度还能卖多久、补货需要多久、谁来处理、处理之后结果是否回写系统。
这五个问题分别对应数据口径、风险计算、供应链周期、责任分配和执行闭环。缺少其中任何一环，系统都可能出现“提醒很及时，但商品仍然卖断”的结果。
这六个节点不是“系统功能清单上的六个勾选项”，而是一条必须能跑通的业务链路。采购人员在测试系统时，不能只测试低库存提醒是否弹出，还要模拟订单锁定、采购延期、跨仓调拨和活动销量上升等真实变化。
我不建议企业一开始就把所有商品、所有仓库和所有渠道同时接入。更稳妥的做法是先选择高销量、高毛利、缺货后损失明显的 50 至 200 个 SKU 进行试运行。
试运行阶段的目标不是证明系统能发提醒，而是验证三件事：可售库存口径是否与订单履约一致，预警时间是否早于实际断货，提醒是否能被正确的人在规定时间内处理。
当这三个问题都稳定后，再逐步扩展到低频商品、季节性商品、组合商品和多仓协同场景。否则，数据口径尚未统一就扩大范围，只会把错误规则复制到更多商品上。
仓库里有货，只能说明商品存在于某个物理位置，不代表消费者现在可以购买。已付款未发货订单、已分配但未拣货订单、售后冻结库存、质量待检库存和直播活动预留库存，都可能无法再次被正常销售。
一个适合用于项目讨论的简化公式是：
可售库存 ≈ 实物库存－已锁定库存－冻结库存－渠道预留库存＋可确认在途库存
这里的“可确认在途库存”不能简单等于所有已采购数量。只有供应商已确认、物流状态可追踪，并且预计到货时间早于需求风险点的货，才有资格参与缺货判断。不同系统的字段定义可能不同，正式上线前必须以订单、仓库和采购模块的实际口径为准。
| 库存状态 | 是否可直接销售 | 预警计算中的处理建议 | 必须核对的问题 |
|---|---|---|---|
| 可用实物库存 | 通常可以 | 作为可售库存的基础输入 | 是否已完成入库和可销售质检 |
| 订单锁定库存 | 通常不可以 | 从可售数量中扣除 | 订单取消后是否自动释放 |
| 冻结或质检库存 | 通常不可以 | 不计入可售数量 | 冻结原因和预计释放时间是什么 |
| 渠道预留库存 | 取决于分配规则 | 按渠道库存策略扣除 | 预留是否会过期或回收 |
| 在途库存 | 尚未可以 | 结合到货可信度和补货周期判断 | 到货时间是否早于预计缺货时间 |
这张表的价值在于把“库存”拆成业务状态。很多系统上线失败，并不是没有库存字段，而是采购、仓库、运营对同一个字段有不同理解。采购认为在途就是库存，运营认为只有到仓才能销售，系统却把两者直接相加，最后得到一个看似安全、实际已经断货的数字。
套装和组合商品是缺货预警中最容易被忽略的场景。例如一个礼盒由杯子、包装盒和赠品组成，即使杯子库存充足，只要包装盒不足，礼盒就无法正常销售。
组合商品的可售数量通常应由组成件中的最小可组合数量决定。系统至少要支持维护主商品与子 SKU 的用量关系，并在任一组成件低于风险线时向运营和采购发出说明，而不是只提醒主商品库存。
验收时可以准备三组数据：单品库存充足且配件不足、配件充足但主件不足、其中一个 SKU 被冻结。系统应能准确显示究竟是哪一个组成件限制了组合商品的销售。
“库存低于 100 件就预警”只适合销售速度和采购周期都相对稳定的商品。对日销 3 件的商品来说，100 件可能足够销售一个月；对日销 80 件的爆款来说，100 件可能只够一天。
固定阈值的优势是容易理解、容易配置、容易向业务人员解释。它的短板也很明显：无法反映销量变化，无法处理促销波动，也无法区分供应商交付能力。
我通常会把固定阈值作为第一阶段规则，而不是最终规则。新系统没有足够历史数据时，可以先用固定值保证基本防线，运行四至八周后，再根据实际销量和缺货记录升级为动态规则。
预计可售天数是比“还有多少件”更接近运营决策的指标。基础计算方式是：
预计可售天数＝当前可售库存÷近期平均日销量
例如某 SKU 当前可售库存为 240 件，过去 14 天平均每天销售 30 件，那么预计可售天数约为 8 天。如果该商品的采购、生产和入仓周期是 12 天，它即使还有 240 件，也已经进入补货风险区。
这个公式不能机械使用。促销期应单独计算活动销量，季节性商品应参考同期数据，新品可以使用相似商品的销量曲线，销量极不稳定的商品则需要设置上下限或采用分位数方法，避免单日异常订单把平均值拉得过高。
安全库存不是越高越好。设置过低，预警来得太晚；设置过高，则会把正常经营库存误判为风险，增加资金占用和积压压力。
在实际配置中，我会至少检查以下变量：
如果供应商通常 7 天交货，但过去三个月有多次延迟到 12 天，那么安全库存就不能只按 7 天计算。此时，系统需要呈现“承诺交期”和“实际交期”的差异，而不是只读取供应商主数据中的一个静态数字。
| 商品层级 | 典型特征 | 建议规则 | 主要取舍 |
|---|---|---|---|
| A 类重点 SKU | 销量高、毛利高、缺货损失大 | 按预计可售天数和采购周期提前预警 | 提醒更早，但需要承担更高库存成本 |
| B 类稳定 SKU | 销量规律、供应商较稳定 | 安全库存加固定阈值 | 易于管理，精度依赖历史数据质量 |
| C 类低频 SKU | 销量低、订单少、补货不频繁 | 按最低库存和采购批量管理 | 减少频繁提醒，但可能牺牲部分响应速度 |
| 季节或活动 SKU | 需求波动大、销售窗口短 | 按活动计划和同期销量单独配置 | 预测难度高，需要人工复核 |
通知发给所有人，往往等于没有发给任何人。仓库主管可以确认实物，采购负责供应商和订单，运营负责活动、限售和商品展示，财务或负责人则需要关注大额采购和资金占用。
因此，系统应支持按照仓库、商品分类、供应商、渠道或预警等级分配责任人。紧急缺货不应只发给仓库；仓库只能说明“有没有货”，不能决定是否采购、是否调拨或是否调整销售策略。
通知内容也不能只写“某商品库存不足”。至少应该包含 SKU、仓库、渠道、可售数量、预计可售天数、采购周期、在途数量、建议动作和处理截止时间。
我建议把预警至少拆成“关注、预警、紧急”三个层级。关注表示接近风险线，预警表示按照现有销量可能影响后续销售，紧急则表示已经进入断货窗口或即将影响待履约订单。
不同等级应对应不同通知频率和处理时限。关注可以进入日报，预警需要产生待办，紧急则应通过移动端或即时通讯工具通知责任人，并在超过时限未处理时升级给主管。
同时要控制重复提醒。同一个 SKU 在库存没有变化、责任人没有动作时，每小时重复推送只会制造噪音。更合理的做法是合并同类事件，在库存继续下降、风险等级升级或处理超时三个节点再次提醒。
预警状态至少应包含待确认、处理中、已转采购、已安排调拨、暂不处理、误报和已解决。没有状态，管理者只能看到消息发送量，无法知道风险是否被消化。
“暂不处理”也应要求填写原因，例如供应商已确认今日到货、商品即将下架、销售计划已经结束或该 SKU 有替代品。这样做不是增加形式审批，而是为后续复盘保留判断依据。
如果系统支持处理结果回写，运营可以看到预警是否影响商品销售，采购可以看到补货是否按期到仓，仓库可以核对实际入库数量。三方使用同一条记录，才能减少口头沟通和重复确认。
以九数云这类数据分析与可视化工具为例，我更建议将其放在“库存数据汇总、风险分析、看板展示和复盘”这一层使用，而不是在没有确认接口能力的情况下，直接把它当作完整的 ERP、仓储系统或采购执行系统。
官网地址为 https://www.jiushuyun.com/。实际项目中，工具能否接入店铺、订单、仓库和采购数据，取决于数据源、接口权限、同步方式以及企业自身的数据治理条件。
我的判断标准是：让业务系统负责订单扣减、入库、出库和采购状态，让分析工具负责把分散在多个系统里的数据拼接起来，计算预计可售天数、预警等级、供应商延期情况和缺货损失，再通过看板推动责任人处理。
首页不应只展示库存总额。管理者更关心当前有多少 SKU 已进入风险、哪些渠道受到影响、预计几天内可能缺货，以及高毛利商品占了多少风险库存。
明细表要能下钻到商品、规格、仓库和渠道。每一行最好同时显示可售库存、近 7 天销量、近 30 天销量、预计可售天数、采购周期、在途数量、最近一次预警时间和处理状态。
采购人员需要看到预警 SKU 是否已有采购单，采购单处于待审核、已下单、部分到货还是延期状态。如果每次都要从看板切换到采购系统手工查询，预警闭环仍然没有真正形成。
复盘视图应比较预警与实际结果：预警后是否缺货、提前了多少天、采购是否按期到货、是否出现误报、是否因为库存同步延迟造成判断错误。
为了让分析结果可追溯，我会把数据拆成五类，而不是把所有字段堆到一张表里。
其中，销售数据和库存数据的时间粒度必须事先统一。若销量按天统计，库存却只在每周盘点时更新，那么预计可售天数的精度自然有限。看板可以把问题展示出来，但不能凭空修复底层数据缺口。
假设某电商企业有三个仓库，某爆款 SKU 的合计实物库存为 680 件，其中 A 仓 420 件，B 仓 160 件，C 仓 100 件。表面看库存不少，但 A 仓有 260 件已锁定订单，C 仓有 80 件正在质检，真正可直接销售的数量只有 340 件。
该商品近 14 天平均日销量为 52 件，活动期间预计放大到 75 件。采购周期为 6 天，跨仓调拨需要 2 天。按平销速度计算，可售库存覆盖约 6.5 天；按活动速度计算，只能覆盖约 4.5 天。这个 SKU 不应该继续显示“库存充足”，而应至少进入预警状态。
如果看板进一步发现 B 仓仍有 160 件可售库存，而平台订单主要来自 A 仓，那么最优动作未必是立即采购，也可能是优先调拨。由此可见，缺货预警不是简单地回答“要不要买”，而是帮助团队比较采购、调拨、限售和等待到货的成本。
库存看板最常见的错误是堆满环形图、柱状图和颜色卡片，却没有告诉使用者下一步做什么。我建议每个核心图表都对应一个动作入口，例如点击风险 SKU 后查看采购单，点击延期供应商后查看受影响商品，点击紧急预警后进入责任人待办。
如果一个图表无法帮助用户判断采购、调拨、限售或复核中的至少一个动作，就应考虑删除。数据越多不代表决策越清晰，真正有价值的是让使用者在三十秒内找到最需要处理的异常。
统一阈值看起来管理简单，实际会制造两种错误。低销量商品被频繁提醒，采购人员逐渐忽略消息；高销量商品则可能在真正断货前才触发提醒，留给供应链的时间已经不够。
改进方法是先按销量、毛利、缺货损失、交期和商品生命周期分层，再为不同层级配置规则。规则数量不宜一开始就过多，先用三至五类覆盖主要商品，运行后再根据误报和漏报调整。
采购单已创建，不代表商品一定按期到仓。供应商可能延期，物流可能滞留，部分到货可能存在质量问题。若系统把全部在途数量直接加入可售预测，预警就会被人为推迟。
更合理的做法是把在途库存分为已确认、运输中、预计延期和异常待核实等状态。只有到货可信度较高、且预计到货时间早于库存耗尽时间的部分，才可以作为风险缓冲参考。
库存数量是静态结果，销售速度是风险变化的过程。一天卖 10 件和一天卖 100 件的商品，即使库存同为 200 件，缺货时间也完全不同。
建议至少同时展示近 7 天、近 30 天销量和预计可售天数。若两个周期差异很大，应主动标记销量加速或减速，而不是简单取一个平均值隐藏变化。
仓库可以核对数量，却通常不能决定采购金额、供应商选择、渠道分配和营销策略。将所有提醒发给仓库，会造成仓库承担无法独立解决的责任。
责任分配应按照问题类型拆开：库存差异给仓库，供应商延期给采购，活动销量异常给运营，超预算采购给负责人，多渠道分配冲突则进入库存计划或运营管理岗位。
多平台库存同步受接口频率、订单并发、网络延迟、扣减顺序和平台规则影响。即使同步间隔很短，也不能保证所有渠道在同一瞬间看到完全一致的数量。
企业应同时设计安全库存、渠道配额、超卖保护和异常对账机制。对于直播或大促场景，还要提前锁定活动库存，并在活动结束后回收未使用的预留数量。
自动采购可以减少录入工作，但不应替代采购判断。系统并不知道商品是否即将下架、现金流是否紧张、供应商是否正在涨价，也不一定知道活动已经取消。
成熟做法是先生成补货建议，并给出计算依据，再由采购人员确认数量、供应商和到货时间。对于高频标准品可以提高自动化程度，对于高金额、季节性和生命周期末端商品，则应保留人工审批。
当系统提示某 SKU 还有 500 件时，我会先追问这 500 件包含什么。若系统不能展开到实物、锁定、冻结、在途和渠道预留明细，那么这个数字不适合直接用于采购决策。
可解释性是预警可信度的基础。业务人员应该能看到触发规则、输入数据、计算时间和数据来源。只给出一个红色图标而没有计算依据，会让使用者在几次误报后放弃信任。
缺货预警的关键不是“现在缺不缺”，而是“在新货可用之前会不会缺”。因此，判断逻辑至少要比较预计缺货日期与预计可供销售日期。
如果预计缺货日期为 6 月 12 日，而采购到仓并完成质检预计为 6 月 15 日，即使当前仍有库存，也应视为存在三天风险窗口。系统可以建议调拨、拆分发货、限售或加急采购，而不是等到库存归零后再通知。
不是所有预警都应该通过采购解决。补货数量过小可能达不到供应商起订量，补货数量过大又会增加积压。调拨速度较快，但会产生运输和仓内操作成本；限售能保护履约，却可能损失流量和转化。
我会把处理动作放在三个维度下比较：缺货损失、补货或调拨成本、库存积压风险。高毛利爆款通常更适合提前补货，低毛利和短保商品则需要更谨慎地平衡服务水平与库存成本。
预警太多不一定代表系统敏感，可能只是规则过于粗糙。预警太少也不一定代表库存安全，可能是库存同步延迟或阈值设置过低。
建议每月建立一张复盘表，至少记录预警数量、实际缺货数量、误报数量、预警提前天数、处理及时率和因缺货损失的订单金额。不要只看“预警关闭率”，因为快速关闭误报并不等于系统创造了业务价值。
中小商家通常 SKU 数量有限，但数据来源分散，可能同时使用平台后台、表格和第三方仓库。此时不必追求复杂预测模型，先统一每日库存快照、销量、采购周期和责任人即可。
这类企业最容易踩的坑是过度追求自动化。连库存口径都没有统一时，复杂的预测模型只会让错误看起来更专业。
如果同一 SKU 同时销售于多个平台，重点不只是计算总库存，而是判断哪个渠道可以使用哪些库存。平台独立配额、活动预留和仓库发货范围都可能导致“全局有货、某渠道无货”。
建议先建立渠道库存台账，区分共享库存、独占库存、活动锁定库存和不可跨仓库存。预警时同时展示全局可售和渠道可售，避免运营只看总库存而继续投放已经无法履约的渠道。
大促期间不能沿用平销期阈值。活动开始前，系统应根据预计曝光、转化率、活动时长和发货能力建立活动库存计划；活动进行中，则需要按小时或更短周期观察销量速度和剩余可售量。
直播场景尤其要关注订单峰值。一个商品在平时每天卖 50 件，直播间可能在十分钟内产生 300 件订单。如果系统仍按日均销量计算，预警几乎一定会滞后。
活动结束后还要处理预留库存回收、取消订单释放和未支付订单释放。否则，活动预留会长期占用可售数量，制造虚假的缺货风险。
新品没有足够历史销量，不能直接套用成熟商品的预测模型。上线初期可以参考相似商品、预售订单、广告预算和活动计划，设置一个较保守的初始阈值。
新品前两周应提高人工观察频率，重点记录首日销量、加购率、转化率和订单取消率。等积累了足够数据，再逐步从人工规则过渡到按可售天数和销量趋势预警。
短保商品的库存预警不能只看“是否快卖完”，还要看“剩余保质期内能否卖完”。季节商品也不能因为库存低就自动采购，销售窗口即将结束时，补货可能反而扩大损失。
这类商品应在预警中增加剩余保质期、预计销售结束日、临期数量和折扣处理状态。系统可以同时展示缺货风险与报损风险，让采购人员看到完整的取舍，而不是只被单一红色提醒驱动。
| 方案 | 优点 | 不足 | 适合情况 |
|---|---|---|---|
| 固定库存阈值 | 容易理解，部署速度快 | 无法反映销量变化 | 稳定标品、新系统初期 |
| 按可售天数 | 更贴近销售速度和采购周期 | 依赖销量口径和统计周期 | 有稳定订单数据的商品 |
| 趋势或预测模型 | 可处理季节性和需求变化 | 建设和解释成本较高 | 数据量大、库存价值高的企业 |
我的建议是分阶段使用：第一阶段用固定阈值保证基础防线，第二阶段加入可售天数和采购周期，第三阶段才考虑趋势预测。每一次升级都必须能解释比上一阶段减少了什么误报，提前发现了什么风险。
自动采购适合供应商稳定、采购价格透明、需求规律且缺货代价高的标准品。人工审批适合高金额商品、季节商品、短保商品和即将下架商品。
可以采用分层授权：低金额标准品自动生成采购申请，中等金额由采购确认，高金额或高风险商品由负责人审批。这样既减少重复录入，也避免系统依据异常销量直接放大采购量。
统一库存有利于提高整体库存利用率，但会增加跨渠道分配和超卖控制的复杂度。渠道独立库存更容易管理，但某个渠道缺货时，其他渠道可能仍有闲置库存，整体周转效率较低。
如果企业刚开始多渠道经营，可以先按仓库和渠道建立清晰配额，再逐步引入动态共享。动态共享必须建立在订单扣减、同步异常和优先级规则都稳定的基础上。
高频提醒能更早发现问题，但也更容易产生通知疲劳。低频提醒可以减少噪音，却可能错过活动、突发订单或供应商延期带来的风险。
比较好的办法不是简单选择高频或低频，而是按风险等级设置频率。关注级进入日报，预警级进入待办，紧急级即时推送；同一预警在未发生新变化时合并提醒，发生风险升级时再触发新通知。
验收时不要只让产品人员点击菜单。应该设计至少四个测试场景：订单锁定导致可售下降、供应商延期导致在途失效、跨仓调拨解决渠道缺货、活动销量突然上升触发紧急预警。只有场景跑通，功能才算真正可用。
选择高销量或高缺货损失 SKU，列出相关仓库、渠道、供应商和订单状态。由运营、采购、仓库共同确认哪些库存可销售、哪些库存必须扣除。
检查 SKU 编码是否统一，组合商品关系是否完整，库存和销量的日期是否一致，采购单是否包含承诺到货日期。不要在数据明显缺失时急于配置复杂规则。
对重点 SKU 设置固定阈值、预计可售天数和采购周期。关注级、预警级和紧急级不必一开始设计得过细，先保证业务人员能理解触发原因。
让每条预警都进入一个明确的待办队列。测试不同等级是否通知到正确岗位，并检查同一 SKU 在短时间内是否产生重复消息。
人为制造库存下降、订单取消、采购延期和跨仓有货等情况，观察系统是否给出合理建议。特别要检查“总库存有货但目标渠道无货”的场景。
不立即改变全部采购策略，只观察系统预警与人工判断的差异。记录每条预警的实际原因、处理动作和最终结果，为规则调整准备证据。
统计触发数量、有效预警数量、误报数量、处理耗时和实际缺货数量。若预警过多，优先检查销量周期和库存口径；若预警过晚，优先检查采购周期、活动数据和在途库存可信度。
电商库存管理真正难的地方，不在于计算一个库存数，而在于判断这个数对订单履约、采购决策和现金流意味着什么。实物库存、可售库存、渠道库存和在途库存之间存在差异，固定阈值、预计可售天数和安全库存也各有适用边界。
我的核心建议是：先把库存口径讲清楚，再把风险规则配准确，最后把预警连接到责任人和业务动作。不要先采购一个看起来功能很多的系统，再试图让业务迁就系统字段；应先画出真实流程，再用系统承载流程。
如果企业目前还没有完善的库存预警体系，下一步可以从一张重点 SKU 清单开始。选出最容易缺货、缺货损失最高的商品，记录当前可售库存、日均销量、采购周期、在途数量和责任人，连续运行七天。
七天之后，企业通常就能看到最值得解决的真实问题：是库存口径不一致、采购周期不可信、渠道库存分配失衡，还是预警通知没人处理。找到这个问题，再决定是否需要更复杂的预测、更深的数据分析或更高程度的自动化，投入才会真正产生价值。
我以前把库存预警简单设成“低于 100 件就提醒”，结果发现同一个规则用在不同 SKU 上，误报和漏报都很严重。有的商品每天卖 3 件，100 件库存足够销售一个月；有的活动款每天卖 80 件，库存还有 100 件却可能当天就断货。我想知道，缺货预警到底应该依据哪些库存和销售数据判断？
固定库存阈值适合销量稳定、采购周期短的标品，但不适合大多数电商 SKU。真正需要判断的不是“仓库还剩多少件”，而是“当前可售库存还能支撑销售多久，以及补货能否在售罄前到达”。我在测试库存规则时，先把库存拆成实物库存、已锁定库存、冻结库存和在途库存，再单独计算可售数量。
一个更接近业务实际的基础公式是： 可售库存 ≈ 实物库存－已锁定库存－冻结库存＋可确认在途库存 这里的“在途库存”不能直接全部加回。只有已经确认供应商发货、预计到货时间明确，并且不会被其他渠道占用的数量，才适合参与缺货判断。不同系统对锁定、冻结和可售字段的定义可能不同，上线前必须先做口径确认。
第二步是计算预计可售天数： 预计可售天数 = 当前可售库存 ÷ 近期平均日销量 商品场景库存数量近期日销量预计可售天数判断 稳定标品100 件3 件约 33 天不一定需要紧急预警 活动商品100 件80 件约 1.25 天应立即预警 销售周期也不能机械取一个固定值。
平销商品可以参考近 14 天或 30 天销量；促销商品应单独使用活动期销量；季节性商品需要参考去年同期；新品则可使用相似 SKU、预售订单和人工判断。我的建议是至少同时保留两条规则：一条是安全库存规则，另一条是预计可售天数规则。
例如，商品可售库存低于 200 件，或者预计可售天数低于采购周期加安全缓冲天数，任一条件满足就进入预警。这样比单纯设置“低于 100 件提醒”更不容易漏掉高速销售商品。
我对比过几类库存系统，几乎都能显示库存、设置阈值和发送提醒，但真正使用时还是要靠人工导出表格，再去查采购单和在途货物。为什么很多系统看起来功能齐全，预警却没有转化成补货动作？选型或验收时，我应该重点检查哪些功能？
缺货预警不是一个通知按钮，而是一条“库存数据，风险判断，责任人，处理动作，结果复盘”的业务链路。系统只有提醒功能，没有后续任务和处理状态，通常只能解决“有人看到”，解决不了“有人负责”。我建议把验收事项分成五层，而不是只看产品页面上的功能数量。第一层是库存数据层。
系统要能按 SKU、规格、仓库和渠道查看库存，并区分可售、锁定、冻结、待入库和在途数量。库存变动还应保留订单扣减、入库、盘点、退货和人工调整记录，否则出现超卖时很难追责。第二层是规则层。至少要支持固定阈值、安全库存、预计可售天数和按商品分级配置。
高销量商品、低频商品、易过期商品和活动商品不应共用一套规则。规则最好支持批量导入、定时生效和变更记录，方便运营团队在大促前调整。第三层是通知层。通知内容不能只有“某商品库存不足”，还应包含 SKU、仓库、渠道、当前可售库存、预计缺货时间、在途数量、责任人和建议动作。
系统还要支持重复提醒控制、超时升级和已处理状态，否则高频提醒很快会变成噪声。第四层是执行层。预警触发后，系统应能生成补货建议、关联已有采购单、查看供应商交期、发起仓间调拨，或将商品标记为限售、停售和暂不补货。
自动生成采购建议是合理的，但不建议无条件自动下采购单，因为采购还要结合活动计划、现金流和供应商可靠性确认。第五层是复盘层。系统应能统计预警数量、实际缺货数量、误报数量、处理时长和预警后缺货比例。没有这些数据，就无法判断是阈值设置错误、库存口径错误，还是采购执行太慢。
验收模块必须能回答的问题 库存口径这个数量到底能不能卖？预警规则为什么此时触发预警？通知机制谁负责处理，多久处理？采购协同如何补货或调拨？复盘报表这次预警是否准确？如果一个系统只能展示低库存列表，却不能解释触发原因、关联采购单和记录处理结果，我会把它归类为“库存查询工具”，而不是完整的缺货预警系统。
我同时经营多个平台，商品在中心仓、第三方仓和平台仓都有库存。最麻烦的是总库存看起来还不少，但某个店铺已经卖断货；有时系统显示库存同步成功，平台仍然出现超卖。我想知道，多渠道库存预警应该按总库存判断，还是按仓库和渠道分别判断？
多平台场景下，按总库存做缺货预警通常会掩盖局部缺货。总库存还有 500 件，并不代表每个渠道都能销售这 500 件，因为库存可能被渠道预留、仓库区域、配送范围和订单状态切分。我处理这类问题时，会同时建立三个视图：全局库存视图、仓库库存视图和渠道可售视图。
全局视图用于采购决策，仓库视图用于调拨和履约，渠道视图用于防止某个店铺提前售罄。
视图主要用途不能替代的判断 全局库存判断整体是否需要补货不能代表每个渠道都可售 仓库库存判断是否能从其他仓调拨不能忽略配送时效 渠道可售库存控制店铺销售和超卖风险不能直接作为全局采购量 例如，中心仓有 300 件，直播渠道预留 150 件，平台店铺预留 100 件，另有 50 件处于质检冻结状态。
此时“看起来有 300 件”并不等于有 300 件可以继续销售。若系统只读取实物库存，预警一定会偏晚。多仓库还要加入调拨时间。假设 A 仓可售库存只能维持 1 天，B 仓还有 200 件，但跨仓调拨需要 3 天，那么 B 仓库存不能直接消除 A 仓的缺货风险。
系统应把“可调拨数量”和“预计到仓时间”一起展示，才能判断调拨是否来得及。验收时，我会要求系统模拟四个动作：同一 SKU 在两个平台同时下单、订单取消后释放库存、退货入库延迟、库存同步接口失败。测试重点不是页面上是否显示“同步成功”，而是订单扣减、库存释放、失败重试和异常告警是否完整。
还要谨慎看待“实时同步”这个说法。实际同步速度取决于平台接口、系统轮询频率、订单并发量和库存扣减逻辑。更稳妥的做法是设置可售库存缓冲，并对同步失败、库存差异和长时间未对账建立单独预警。
我的判断标准是：系统不仅要告诉你“总库存还有多少”，还要告诉你“哪个渠道、哪个仓库、在什么时间点会先卖断，以及是否有可执行的调拨方案”。
我遇到过一种很典型的情况：系统上午发出低库存提醒，采购看到了但没有确认，运营以为采购已经下单，仓库则等着系统自动补货。几天后商品真正缺货，大家却找不到是哪一步出了问题。我想知道，一条预警从触发到关闭，应该怎样设计责任人、状态和升级机制？
预警闭环的核心不是把消息发给更多人，而是让每条异常都有明确的责任人、截止时间和处理结果。通知范围越大，责任越容易模糊；很多团队的问题不是没有提醒，而是提醒没有进入工作流。我建议将预警状态至少拆成以下几种：待确认、处理中、已转采购、已安排调拨、暂不补货、误报、已解决和已关闭。
每种状态都应有操作人、操作时间和备注，避免员工只点击“已读”却没有留下业务判断。
处理阶段责任角色需要确认的内容 风险确认运营或库存专员是否为真实缺货风险，销量数据是否异常 方案判断采购或供应链补货、调拨、替代商品还是限售 执行跟进采购与仓库采购单、到货时间和入库进度 销售调整运营是否限购、限售、下架或调整渠道库存 结果复盘负责人是否按时解决，规则是否需要调整 预警内容也要支持决策，而不是只提供一个库存数字。
至少应显示当前可售库存、近期日销量、预计可售天数、采购周期、在途数量、已有采购单和建议截止时间。采购人员看到这些信息后，才能判断是立即下单，还是等待已有货物到仓。对于紧急预警，我会设置升级机制。例如，一级预警进入系统待办；二级预警通知采购和运营负责人；三级预警在超过设定时间未确认时升级到部门负责人。
升级条件应基于“未确认”和“未处理”，而不是单纯重复发送同一条消息。还有一个容易被忽略的动作是记录“不补货原因”。有些 SKU 低库存是因为即将下架、供应商停止供货、活动已经结束或商品正在替换。如果系统只能让员工选择“已处理”，后续复盘会把合理决策误判成漏处理。上线初期不要一次覆盖全部商品。
我更建议先选择 20 至 50 个高销量、易缺货或高毛利 SKU 试运行两周，记录预警命中率、平均确认时长、实际缺货比例和误报原因。等团队真正形成“看到预警，作出判断，执行动作，关闭任务”的习惯后，再扩大到全量 SKU。
读者评论
文章把缺货预警从“发通知”拆成数据、判断、分派、执行和复盘几个环节，比较符合实际业务。尤其是区分实物库存与可售库存，对多仓、多渠道电商很有参考价值。
组合商品和在途库存的处理容易被忽略，文中提出按最短板计算组合商品可售量，确实能减少误判。不过动态销量预测仍需要较完整的历史数据，小商家落地时可能要先从简单规则开始。
通知分级、责任人和超时升级的设计比较实用，能避免预警长期停留在消息层面。建议实施时同步关注误报率、处理时效和补货后的实际效果，否则规则可能越来越复杂但管理收益有限。