一、项目背景

我们服务的一家连锁游泳馆，原本泳客买卡之后预约场次全靠微信群接龙。夏天旺季一场接一场，超员和爽约占位同时发生，水池的限流规定形同虚设，安全员天天在边上看人数心惊胆战。场馆方自己都看不清真实的在馆人数，偶尔超员被街道约谈过，安全台账也经不起查。更糟的是爽约的多了，真正想游的人约不上，投诉电话不断，前台接得手软。我们进场的时候，运营每天光对账就花一个多小时，还经常对不平，月底和财务扯皮，谁都不想碰这块，数据乱得没法看。最尴尬的一次是某场满员但现场只来了三个人，剩下的全是占着不来的人，真想游的会员在门口被拦，那天的投诉直接捅到了区域总那里。

二、落地场景

我们基于 XpShop 的预约核销能力重做了场次管理。每个场次在系统里是一个有硬库存的库存单元，会员在小程序预约、可改签一次，改签也占新场次库存不占旧的，避免重复占用。到场后刷脸或刷码核销，爽约的提前两小时自动回收名额放开给候补，候补按预约先后自动顶上。场馆设了限流预警，当某个场次核销人数接近水池承载就弹提醒给值班。教练排班和场次绑定，空闲场次自动挂出小班课，教练排班表不再是静态表。整个预约、核销、回收、排班都进同一套订单和库存视图，运营不用再手工拉表，打开后台就是实时数，哪场满、哪场空、谁爽约，一眼看全。运营后来把会员等级也并入这套预约，金卡会员可以锁特定场次的好泳道，普通会员走通用池，资源倾斜有了依据。寒暑假少儿班和成人夜场错峰排，系统按历史报名自动错开库存，不再出现少儿班占满导致上班族没场次的尴尬。教练侧的小班课排期也接了进来，空闲场次自动挂课，教练空档被填上的同时场馆多了除门票外的收入。我们复盘时发现，错峰排期上线后晚高峰投诉几乎归零，因为成年人和少儿班不再抢场，这条原本靠人协调的规矩被系统固化了下来。

三、关键技术挑战与解决思路

场次库存和超员防护是第一个坎。接龙时代根本没有硬上限，我们给每场设了基于水池面积的承载数，预约数到了就关闸，宁可放候补也不超员，安全这条线不能破。爽约占位回收靠时间窗：开场前两小时还没核销的预约自动释放，同时通知候补，既给客人缓冲又不浪费名额。到场核销要防代刷，我们上了刷脸加动态码双重校验，代刷基本绝迹，会员卡外借的情况也被压住。限流预警则是实时监控在馆数，超过阈值推给值班，安全员从盯人数变成看告警。这里踩过坑，第一版回收窗口我们拍脑袋定成一小时，结果不少客人卡着点堵车迟到，到了名额已经被候补顶走，差评反而比改造前还多，后来按历史爽约率把窗口拉到两小时才平衡，不同场馆还能配不同值，参数不能一套打天下。

案例片段（已脱敏）： 场次库存与核销规则（示意）： slot.capacity_by_area: true slot.hard_close: true no_show.release_before_min: 120 checkin.mode: face_and_dynamic_code capacity.alert_ratio: 0.9 某旗舰馆上线后超员事故从月均 6 起降到 0，爽约率从 19% 降到 7%，对账时间从每天 70 分钟降到 5 分钟。

四、效果数据

我们盯的是场次利用率、爽约率、超员事故和核销异常率。场次利用率从约六成提到八成以上，因为回收的名额被候补接住了，水池不再是空着或半满；爽约率由接近两成降到 7% 左右，两小时回收窗口起了作用；超员事故基本归零，街道那边的约谈也没了；核销异常率维持在很低水平，代刷基本消失。我们还顺带统计了会员的月度到馆频次，核销数据反过来成了运营做续卡提醒的依据，泳池从一次性消费变成了周期习惯，留存肉眼可见地好了。更意外的是，场次利用率上来之后，教练的小班课报名也跟着涨，因为客人来了发现水不挤、体验好，顺手就报了课，这条链路我们当初没预料到。

文中数据为项目复盘口径，实际值会随淡旺季波动，仅作趋势参考。运营最满意的是对账时间，从每天一个多小时变成系统自动出，基本不用人工去对，她能把精力放在排课上，而不是耗在表格里，月底和财务也不再扯皮。

五、可复用经验总结

游泳场次这种带物理容量限制的资源，核心就是"硬库存加回收"。别信接龙，限流要落到系统关闸而不是靠人喊，安全是底线，破一次就前功尽弃。回收窗口别写死，用历史爽约率去调，比拍一个固定时间聪明，不同场馆的爽约习惯不一样，一套参数打天下会翻车。核销防代刷值得上双重校验，游泳馆会员卡被借来借去是常态，单层校验挡不住。做类似场地预约的朋友，先把容量算法和回收窗口这两件事想清楚，比忙着做花哨的营销页有用，系统稳了体验自然好，会员续卡也爽快。