爆款补货候补顺位释放：空出来的名额放出来

这个案例来自电商场景。

爆款断货以后，很多店铺都会说：

“登记一下，补货通知您。”
“到货优先提醒。”

可真正到货时，如果库存只回来一小部分，团队最常见的做法却是直接重新开放售卖，结果前面那批已经登记、已经等了很久的高意向顾客，还是要重新回到拼手速。

这会让顾客非常挫败。
因为从顾客视角看，自己不是没表达过意向，而是已经排过队，却没有得到顺位上的承接。

这个场景为什么在断货爆品里特别伤

这家企业主营家居小电和高频消耗型爆款，部分 SKU 经常出现：

上一波卖空
顾客大量登记补货通知
下一波只补回来有限库存

这时候团队面对的不是单纯“到货了没”，而是：

这次补货够多少人
先通知谁
被通知的人如果没下单，名额多久释放
剩下的人什么时候补位

如果没有候补顺位机制，所谓“到货优先提醒”就很容易沦为空话。

旧流程为什么总在补货时又回到一场新的抢购

1. 前面登记意向的人虽然多，但没有真正形成顺位

客服记录了，商品页预约了，私域也有人登记了。
可这些数据如果没有合并成一个候补池，到货时还是谁先看见谁先买。

2. 补货量有限时，通知动作往往太粗

很多团队会一股脑发一轮：

“到货了，先到先得。”

这会让前面认真等待的人和后面随手登记的人被放回同一起跑线。

3. 被通知后未及时下单的名额没有明确回收边界

如果没有释放机制，第一波被通知的人即使没买，名额也可能继续空耗，后面候补的人还是进不来。

改造前的旧流程

flowchart TB
    A[顾客登记爆款补货意向] --> B[补货数量有限回仓]
    B --> C[运营或系统统一发一轮到货通知]
    C --> D[被通知者和其他新流量一起再次抢购]
    D --> E[前面登记等待的人未真正获得顺位优势]

派宝怎么把“登记等待”真正接成候补顺位

派宝在这里不负责定义爆款策略，而是把“谁先等、谁该先补位、多久不下单再释放名额”这条链挂稳。

1. 先合并候补池并形成顺位

系统会把：

客服登记
商品页预约
私域登记
多次咨询但未成交的高意向顾客

统一形成候补对象池，并结合时间和意向强度生成顺位。

2. 到货后按候补顺位进行补位调度

派宝会明确：

这次库存够通知多少人
谁是第一批候补
哪些人暂时继续保留在后续顺位里

3. 对已分配名额继续做释放判断

如果第一批候补在规定时间内没有下单，系统会判断：

名额是否应释放
是否应转给下一批候补

这样不会让前排名额长期空挂。

4. 对已承诺的优先权继续留痕

只要前线明确说过“优先通知”或“优先购买”，系统就会把这条承诺挂在顺位链上，而不是只发一条普通通知。

改造后的流程图

flowchart TB
    A[缺货登记 补货意向和库存恢复信息进入系统] --> B[客户分群<br/>识别高意向候补对象]
    B --> C[候补补位调度<br/>按顺位分配本次可释放库存]
    C --> D[占用释放判断<br/>判断未成交候补名额是否应释放]
    D --> E[承诺兑现跟踪<br/>持续跟踪已承诺的优先通知和优先购买]
    E --> F[流程自动触发<br/>按批次通知候补对象]
    F --> G[补货等待更像排队而不是重来一遍]

上线后的变化

项目上线后，团队最明显的变化不是爆款补货变多了，而是补货回来的那一刻，前面已经等过的人终于更像真的排过队。

几个变化特别明显：

候补池不再只是一个通知名单
第一批被通知却未下单的名额更快回流给下一批
高意向顾客的回流成交更稳定
顾客对“说好优先通知却还是抢不到”的不满明显下降

项目复盘结果

以 13 周内 41 次爆款缺货后补货事件为样本，项目复盘结果如下：

对比项	改造前	改造后
已登记补货意向顾客未获得实际优先权的比例	较高	下降约 58%
第一批候补名额空耗未及时回收的情况	反复出现	明显下降
高意向候补顾客补货回流成交率	不稳定	明显提升
运营人工整理候补名单和顺位耗时	很长	缩短约 57%
顾客对“优先通知”承诺落空的投诉	较多	明显下降

为什么这个案例值得写

因为补货候补不是一个普通通知场景，而是一个“候补顺位、名额保留、名额释放和承诺履约”一起参与的场景。
这类问题一旦做稳，缺货损失会比单纯发通知更容易被收回来。