直接答案：排队解决"等多久"，预订解决"留不留位"。排队的核心是等位时间预估准确率，预订的核心是超时释放规则。两者共用一个东西：桌台状态。桌台状态管不清楚，排队叫错号、预订占死位，两个功能都会失效。
核心结论速览
**排队的关键指标是预估准确率。** 告诉客户等 20 分钟，实际等了 40 分钟，客户就走了。预估误差控制在 ±5 分钟内，客户体验才可接受。
**预估要靠数据，不能靠感觉。** 基于历史翻台时长、当前桌台状态、排队人数、菜品结构算出来，不是领班拍脑袋。
**预订必须有超时释放规则。** 客户订了 6 点没来，位子一直占着，等于损失一桌生意。常见规则是保留 15 分钟，超时自动释放并通知。
**大桌小桌要分开排。** 两人桌和十人桌不能混在一个队列里，否则会出现"两人桌空着但排了十桌客人"的荒谬情况。
**排队和预订要打通。** 预订的桌台是锁定的，不能被排队占用；预订超时释放后，要自动回到可用池让排队的人补上。
一、排队和预订为什么难做
难点一：等位时间估不准。领班凭经验说"大概二十分钟"，这个数字往往是乐观的。客户信了，等半小时后开始不满，走了还留个差评。估算不准的根本原因是缺少数据：每桌平均吃多久、什么时段翻台快、什么菜品出餐慢，这些都没记录。
难点二：预订了不来，位子空着。周末晚上黄金时段，三个预订客户没来，三个位子空到七点半，外面排队的客户走了。这是最直接的钱的损失。但没有规则，门店不敢随便释放——万一是大客户迟到，释放了得罪人。
难点三：桌台被"软占用"。一桌客人吃完了，但坐着聊天不走；服务员不敢催，桌台就一直"占用中"。系统显示满座，实际有一半桌子在聊天。翻台率上不去，排队越来越长。
难点四：叫号过号。客户取了号去逛街，叫到号没在，服务员跳过去叫下一个。客户回来发现过号了，要重新排，非常不满。过号规则不清晰，是投诉高发点。
难点五：大桌小桌不匹配。四个人来吃饭，只有两人桌空着，拼桌客户不愿意，等大桌又要二十分钟。反过来十人桌空着但只有两个人来，浪费。桌型结构和客群结构不匹配，是很多店的硬伤。
难点六：线上取号和现场取号打架。客户在小程序上取了号，到店发现现场排队的人已经进去了。线上线下的号池不统一，线上客户会觉得被欺骗。
这六个难点的共同根源是：桌台没有准确的状态，排队没有准确的数据。所有优化都建立在"知道现在有几张桌子、每张桌子什么状态、还要多久空出来"这个基础上。
二、排队管理：从取号到叫号的完整链路
第一步：取号。两种方式——现场取号（扫码或服务员代取）和线上取号（小程序、公众号）。线上取号要能选人数、选桌型（大厅/包间/靠窗），并显示预估等位时间。
线上取号必须和现场用同一个号池，按取号时间统一排序。不能让线上客户到了现场还要重新排，那是欺骗。
第二步：等位预估。算法要素包括：当前空桌数、预计空出的桌数（按已用餐时长推算）、排队人数及桌型分布、历史同时段翻台速度。
简化算法示例：预估等待时间 = 前面排队人数 ÷ 每小时可接待桌数 × 60 分钟。比如前面排 8 桌、每小时能接待 6 桌，预估 80 分钟。这个算法粗糙但可用，进一步优化可以按桌型分开算、按已用餐时长动态修正。
关键是动态更新。客户取号后每隔几分钟刷新一次预估时间，如果变长了要如实告知（而不是一直显示最初的乐观数字）。诚实比好看重要，客户能接受等 40 分钟，不能接受说好 20 分钟结果等 40 分钟。
第三步：叫号。三种方式：语音播报（店内广播）、屏幕显示（等位屏）、手机推送（小程序通知）。三种同时用效果最好——客户可能在门外抽烟、可能在隔壁店逛，只有手机推送能找到人。
叫号要有缓冲时间。叫号后给 3-5 分钟到店时间，超时视为过号。过号规则要提前公示：可以顺延 3 桌（常见做法）或者作废重排。建议顺延，因为客户体验更好，且实际损失不大。
第四步：带位入座。叫到号后服务员带位，系统标记桌台"占用中"并记录入座时间。这个动作是后续所有计算的基础——没有准确的入座时间，就算不出用餐时长，也就估不准等位时间。
第五步：数据沉淀。记录每桌的：取号时间、叫号时间、入座时间、离座时间、人数、桌型、消费金额。这些数据跑三个月，等位预估准确率能提升到 ±5 分钟以内。
三、预订管理：规则比功能重要
预订规则要提前定：哪些时段接受预订（比如只接受 11:30-13:00、17:30-19:30）、哪些桌型接受预订（包间全接受、大厅部分接受）、最少几人起订、最多提前几天订、每人限订几桌。这些规则不清晰，服务员每天要请示店长，效率极低。
定金机制：包间和大桌建议收定金（比如 200 元/桌），到店消费可抵餐费，爽约不退。定金的目的是降低爽约率，不是为了赚钱。数据显示收定金的预订爽约率能从 20% 降到 5% 以内。
收定金要注意合规：金额不能过高（一般不超过预估消费的 20%）、规则要提前告知、退款要及时。定金纠纷是投诉高发点，规则写清楚能避免大部分问题。
超时释放规则：这是预订管理的核心。常见规则是"保留 15 分钟"，客户订 18:00，18:15 未到自动释放桌台，同时短信通知客户"您的预订已释放"。如果客户提前打电话说会晚到，可以手动延长（延长次数和时长要有限制）。
释放后的桌台要立即回到可用池，让排队的客户能补上。这一步如果靠人工通知，往往会延迟半小时，损失就产生了。系统自动化是关键。
桌台锁定：预订成功后，该桌台在预订时段内标记"已锁定"，不能被其他预订或排队占用。锁定的粒度要细到"时段"而不是"整天"——18:00-20:00 锁定，20:00 之后可以再订下一轮。
预订和排队的冲突处理：如果门店满座、有预订桌台即将到时间，排队客户问"能不能坐那桌"，服务员要能明确回答"这桌 18:00 有预订"。系统要能看到桌台的锁定信息，服务员不用记。
预订提醒：到店前一天推送"明天 18:00 的预订，需要调整请回复"，到店前两小时再推一次。这两个提醒能把爽约率再降一半。
四、桌台管理：所有功能的地基
桌台状态机：空闲 → 预订锁定 → 已到店 → 占用中（用餐）→ 待清台 → 空闲。每个状态要有明确的操作人和时间戳。状态流转靠人工点（服务员在平板上操作），不能自动推断。
为什么要人工点？因为"客人走了"这个判断只有现场知道——菜吃完了但还在聊天，不能算走；客人去洗手间，不能算走。让系统自动判断必然出错。
桌台属性：桌号、桌型（2 人/4 人/6 人/10 人/包间）、位置（大厅/靠窗/包间/二楼）、是否可拼桌、是否可预订。这些属性决定了排队和预订的匹配逻辑。
拼桌和拆桌：小店常见做法是把两个两人桌拼成四人桌。系统要支持"临时拼桌"，拼桌后桌号变成" A01+A02"，结账时可以分开结也可以合结。拆桌同理。
翻台率计算：翻台率 = 当日接待桌数 ÷ 桌台总数。这个指标反映桌台利用效率。影响因素包括：用餐时长、清台速度、等位转化率。翻台率低不一定是坏事（可能客单价高），但要知道原因。
清台时长要记录：从客人离座到桌台可用的时间。这个时间如果超过 10 分钟，说明清台流程有问题（人手不足、标准不清）。很多店排队严重不是因为桌台不够，是因为清台太慢。
桌台使用分析：哪些桌台翻台率最高、哪些桌台经常空置、哪些时段最紧张。这些数据能指导桌型改造——比如把两个低效的两人桌改成四人桌，整体接待能力会提升。
五、常见问题解答
等位预估的准确率怎么提升？
三个方向：一是积累数据，记录每桌的入座和离座时间，算出真实用餐时长分布（不是平均值，是分布）；二是分桌型、分时段、分星期算，周末和周三的翻台速度差很多；三是动态修正，客户取号后每 5 分钟重新计算，把"前面的人吃得比预期久"这个因素算进去。做到这三点，误差能控制在 ±5 分钟。
预订要不要收定金？
包间和大桌建议收，散台不建议。定金的目的是降低爽约，不是赚钱。金额建议是预估消费的 10%-20%，且到店可抵餐费。数据显示收定金的预订爽约率从 20% 降到 5% 以内，对黄金时段的桌台利用率提升明显。
客户预订迟到，桌台要不要释放？
按规则执行：保留 15 分钟，超时释放。但可以设一个"手动延长"权限给店长，用于特殊情况（客户打电话说堵车、重要客户）。延长要留记录，避免变成"永远不释放"。规则的意义在于有例外时也知道为什么例外。
线上取号和现场取号怎么统一？
用同一个号池、同一套排序规则。客户在小程序取号后，到店扫码"签到"，系统确认到场，排序不变。如果线上取号后 30 分钟未签到，自动作废（防止有人远程占号）。现场取号用同一个队列，按时间戳排序。
过号了怎么处理客户才不生气？
两个做法：一是顺延 3 桌（客户回来后在当前队列前面插入，等 3 桌就能进），二是保留 15 分钟（超时才作废）。推荐顺延，客户体验好，实际损失也小。关键是规则要提前告知——取号时就说明"过号顺延 3 桌"，客户有预期就不会不满。
大桌空着但客人少，能不能让他们坐？
可以，但要算清成本。大桌坐两个人，占用了本该接待十人的资源，翻台损失是实打实的。做法有两种：一是收"大桌最低消费"（常见于包间），二是允许坐但明确告知"如果有大桌客人需要，可能需要换桌"。第二种体验差，建议用第一种。
排队系统要不要和会员打通？
要，而且价值很大。会员取号可以优先（会员优先叫号）、可以自动识别历史偏好（常坐包间、常点某菜）、可以在等位时推送优惠券（把等待时间转化成消费）。这些动作能明显提升会员体验和客单价。
翻台率多少算正常？
正餐 1.5-2.5 次，快餐 4-8 次，火锅 2-3 次。低于区间说明桌台利用不足（可能客单价高、可能清台慢、可能客流不够），高于区间说明可能压榨体验（用餐时间被压缩）。不要盲目追高，要看客单价和客户满意度一起判断。
六、九尾狐在这类问题上的做法
九尾狐做排队预订模块时，先把"桌台状态机"定死，再做排队和预订。因为这两个功能本质都是"抢桌台"，状态机不清楚，两边会打架。我们的做法是桌台状态变更必须有人操作、必须有时间戳，任何自动推断都不允许。
等位预估我们用的是"分布"而不是"平均值"。平均用餐时长 60 分钟，但实际可能是 30 分钟和 90 分钟各一半，用平均值算出来的预估会偏差很大。按分布算，准确率能提升一个档次。
预订超时释放我们做成自动的，到时间没到店就释放并推送通知，桌台立即回到可用池。这个自动化带来的效果很直接——客户的黄金时段桌台利用率提升了，排队时间短了。
排队数据我们做成日报：今日取号数、叫号数、过号数、平均等待时长、预估准确率、各时段压力。这份日报能看出门店的接待能力瓶颈在哪，是该加桌、该提效、还是该调菜单。
七、综上所述
排队和预订不是两个功能，是一套桌台调度系统。排队解决"来了怎么安排"，预订解决"提前怎么留位"，两者共用桌台状态。做得好的店，客户觉得"这家店很顺"；做得不好的店，客户觉得"等半天还没位置"。差别就在三个数字上：等位预估准不准、超时释放快不快、桌台状态清不清。