预约座位释放补位调度：空出来的名额放出来

这个案例来自 餐饮与本地生活 场景。

餐厅高峰期最浪费的，
不是没有客人，
而是桌台明明空出来了，
却没能及时补给真正等位的人。

最常见的现场画面是：

提前订好的包厢临时取消
大桌客人迟迟不确认是否到店
前厅知道有桌快空了，门口候客却不知道

结果就是：

店里空着几张高价值桌台
门口还在排队焦躁

为什么预约座位在餐饮现场特别容易“空出来却补不上”

这家连锁餐饮门店周末和节假日客流很高。
桌台资源分成：

包厢
大桌
普通散台

不同桌型能承接的人数和用餐时长差别很大。
一旦有人取消或超时未到，
这张桌不是简单地“空了”，
而是需要立刻判断：

该不该释放
释放后优先补给谁
候补客人是不是能接这个桌型

人工处理这件事非常赶，
稍慢一点，
桌就空着浪费了。

原来的处理链条为什么总在高峰期失灵

1. 取消和失约信息来得很碎

有人打电话取消，
有人在小程序里退订，
还有人只是到点没来。

2. 候补队列不是“马上能派上去”的队列

排队的人很多，
但不是每一组都适合接这张桌。

3. 前厅先忙接待，补位动作容易往后拖

高峰期越忙，
越容易错过释放后的黄金补位时间。

改造前的旧流程

flowchart TB
    A[预约客人取消或超时未到] --> B[桌台被动空出]
    B --> C[前厅人工找候补客人]
    C --> D[匹配和通知不及时]
    D --> E[高价值桌台空置]

派宝怎么把“空桌”快速变成“有人接上”

派宝做的不是替餐厅排座，
而是把释放出来的桌台资源和候补队列实时接起来。

1. 先判断桌台是否已经真实释放

系统会先核验：

原预约是否取消
确认时限是否已过
当前桌台是否已完成翻台准备

2. 再匹配最适合补上的候补客人

派宝会综合看：

人数是否匹配
可接受桌型是否匹配
客人当前是否仍在候场

3. 把确认窗口缩短

真正关键的是快。
系统会对候补客人进行：

即时通知
限时确认
超时自动顺延

改造后的流程

flowchart TB
    A[预约状态 到店状态和桌台准备状态进入系统] --> B[占用释放判断能力<br/>判断桌台是否已经真实释放]
    B --> C[候补补位调度能力<br/>按人数和桌型匹配候补客人]
    C --> D[对象配套校验能力<br/>校验桌台容量和当前客群是否匹配]
    D --> E[任务提醒能力<br/>推动前厅快速确认补位]
    E --> F[餐厅翻台效率提升]

上线后的变化

连续运行 5 周后，
门店最明显的变化是，
高峰期“门口排队、里面空桌”的情况少了很多。

以前前厅很容易一边安抚排队客人，
一边又来不及处理刚释放出来的桌台。
现在系统会先把释放和补位挂成一条链，
高价值桌型的利用率稳定了不少。

上线前后对比

对比项	改造前	改造后
释放桌台空置浪费	较多	明显下降
前厅人工联系候补耗时	很长	缩短约 51%
高峰期顾客等待体验	波动大	明显改善
桌台周转效率	一般	明显提升