到店自提超时名额释放：空出来的名额放出来

这个案例来自电商场景。

到店自提、前置仓自提、门店自提这类模式在电商里越来越常见。
但很多团队很快都会撞到一个现实问题：
有些订单顾客下完单后一直不来拿，货和提货名额就被长期占住。

最常见的现场通常是：

顾客下单选择自提
门店或前置仓为这单留货
系统也为它保留了提货时段或取货资格
顾客迟迟不来，客服又说再等等

如果团队没有稳定判断“现在是不是已经到了可以释放的边界”，就容易两头受损：

不放，后面真正想买想提的人拿不到货
乱放，顾客回来取货时又发现东西没了

真正难的不是有没有超时，而是超时之后能不能安全释放。

这个问题为什么在门店自提里特别棘手

这家企业主营家清、零食和日用百货，部分城市开放门店自提。
自提订单一旦成立，往往同时占住几样东西：

门店可售现货
自提柜或提货位
店员预留空间
某个时段内的服务容量

而顾客不来拿的原因也很多：

临时没空
改主意了但没取消
想顺路再去
信息没看见或提醒漏掉

如果只盯着“订单有没有取消”，很难判断这批资源现在该不该回池。

旧流程为什么总是“先继续等等”

1. 门店和平台都不愿意先放

门店怕顾客回来取不到货；
平台怕被投诉；
所以最常见的默认动作就是继续等。

2. 但继续等本身也是成本

热门 SKU 被长期占着，后面的顾客买不到；
提货位被占着，门店会觉得自提越来越难做。

3. 自提提醒和释放动作常常脱节

有的团队会提醒顾客来取，
但提醒了之后没人继续判断：

还要不要继续留
已经超几天了
是否进入释放前最后确认

改造前的旧流程

flowchart TB
    A[顾客下单选择到店自提] --> B[门店预留商品和提货位]
    B --> C[顾客迟迟未提]
    C --> D[客服或门店零散提醒]
    D --> E[资源继续被占住]
    E --> F[后续可售库存和提货能力被长期压住]

派宝怎么把“留多久、什么时候放”判断清楚

派宝在这里不负责决定自提策略，而是把保留窗口、提醒动作和回池条件挂成一条线。

1. 先识别当前占用对象

系统会把这笔自提单占住的对象明确下来：

哪件现货
哪个门店或提货点
哪个提货位
哪个保留时段

这样后面判断的就不只是订单状态，而是资源状态。

2. 再做变更窗口和释放判断

派宝会结合规则判断：

顾客当前是否仍在正常提货窗口内
是否已进入超时提醒阶段
是否已满足释放条件
是否存在顾客确认延期等例外

3. 释放前继续跟一次承诺

如果客服或门店已经向顾客承诺：

可以延迟一天来拿
晚上前会再帮忙保留

系统会把这条承诺一起带入判断，不会机械回池。

4. 满足条件后把资源安全放回去

一旦进入可释放状态，系统会明确：

商品回到哪个库存池
提货位何时释放
是否需要同步取消提醒或重新上架

改造后的流程图

flowchart TB
    A[自提订单 门店库存 提货位和顾客承诺进入系统] --> B[变更窗口判断<br/>判断当前是否仍在正常提货窗口]
    B --> C[承诺兑现跟踪<br/>识别是否存在已答应的延时保留]
    C --> D[占用释放判断<br/>判断商品和提货位是否应回池]
    D --> E[系统自动录入<br/>同步库存和自提状态]
    E --> F[任务提醒<br/>在释放前对门店和顾客做最后提醒]
    F --> G[减少无效占用]

上线后的变化

项目上线后，门店最明显的变化不是自提顾客突然都按时来了，而是“哪些还该继续留、哪些其实已经可以放”终于不再全靠店员经验判断。

几个变化特别明显：

热门 SKU 被自提超时单长期占住的情况明显减少
门店对延时保留的承诺不再只停在聊天里
释放动作更有依据，顾客回头投诉也更容易解释
自提位周转率开始更稳定

项目复盘结果

以 14 周内 1.2 万笔门店自提订单为样本，项目复盘结果如下：

对比项	改造前	改造后
超时未提订单长期占库存的比例	较高	下降约 58%
门店人工判断是否释放的耗时	偏长	缩短约 46%
因已承诺延期却被提前释放引发的争议	偶发	明显下降
提货位被无效占用导致的门店拥堵	较多	明显减少
自提资源回池时间的稳定性	较差	明显提升

为什么这个案例值得写

因为门店自提超时不是单纯的库存问题，而是一个典型的“资源被临时占住后，什么时点安全释放”的问题。
这个抽象放到预约、席位、房间、设备上都成立。