餐饮包间桌台预订系统是一套以「桌台×时段」为库存单位的预订系统：桌型与桌位建模、按时段切分可售性、翻台时间预留、定金与最低消费、取消与超时规则。它和点餐系统的边界很清楚——一个管「谁来坐哪」，一个管「坐下之后吃什么」。
这门生意的核心指标只有一个：翻台率。而翻台率不是靠催客人实现的，是靠时段设计实现的。系统要做的，就是把一张桌子的时间切成能卖出去的小块，同时留出必须留的缓冲。
餐饮包间桌台预订系统是一套什么系统？
是一套以「桌台×时段」为库存单位的预订系统；库存不是桌子数量，是可售时段。
四层建模：
门店层。 一家店、一个营业时段、一张台面图。
桌台层。 桌号、桌型（圆桌、方桌、卡座）、可坐人数、是否包间、是否有最低消费。
时段层。 午市、晚市，可再细分（11:00-13:00、13:00-15:00、17:30-19:30、19:30-21:30）。
规则层。 定金、保留时长、超时收费、取消政策、连台与拼台规则。
关键点是「可售单元」的定义。 一张十人包间在晚市理论上能卖两次，但两次之间要留 30 到 60 分钟的清理与摆台时间。这个缓冲不写进系统，第二次预订一定会踩到第一次的尾巴。
为什么桌台比餐位更难管？
因为桌台不可拆分、不能拼；十人桌来了六人，也得占整张。
四个硬约束：
不可拆分。 八人桌空两个位，也不能把这两个位卖给两个人。
不可叠加。 除非明确支持拼台，否则两桌客人不能共享一张台。
类型不通用。 包间和大厅、圆桌和卡座，满足的需求不同，不能互相替代。
时间不可压缩。 一顿饭的时长有下限，压不下去。
这四条决定了桌台预订是一个「装箱问题」——把不同大小的需求装进固定数量的箱子，每个箱子还有时间窗。比卖电影票难，因为电影票的座位是均质的。
「翻台」怎么在系统里表达？
用时段加清理缓冲表达；不留缓冲，第二桌必然迟到。
具体做法：
时段切分。 晚市切成两段，第一段 17:30 到店、19:30 前离席；第二段 19:45 到店。
缓冲固定。 两段之间留 15 分钟清理，系统把这个缓冲当作不可售时间。
超时提示。 到离席时间前 20 分钟提醒前台，前台去沟通而不是等客人自己走。
预订时告知。 下单页明确写「本时段为 2 小时」，客人有预期，沟通成本低很多。
很多店翻台做不上去，不是客流量问题，是「从来没告诉过客人有时间限制」。
定金与最低消费怎么设置？
写在下单页，不要写在包间门口；事后告知等于没告知。
三条规则要同时成立：
定金金额与退还条件。 提前多久取消可全退、多久内取消退一半、当天取消不退。
最低消费的口径。 是「菜品消费」还是「含酒水」，是「人均」还是「整桌」，必须写清。
超出与不足的处理。 不足最低消费怎么补、超出是否叠加服务费。
为什么这些必须前置： 包间纠纷九成来自「我以为含酒水」「我以为可以退」。系统在下单前把三句话说清，能消掉大部分争议。
包间与大厅为什么要分开定价？
因为它们的成本结构不同，混在一起定价会让包间变成「免费升级」。
包间的成本在于：占用面积大、翻台慢、需要专属服务、有最低消费门槛。
大厅的成本在于：翻台快、服务半径大、单位面积产出高。
如果系统里两者用同一套价格与同一套库存规则，结果一定是包间被低价占满、大厅空着。
正确做法是分开建模：包间单独设最低消费与定金，大厅只设时段与人数上限。两套规则并行，而不是一套规则覆盖全部。
临时取消与超时占用怎么处理？
取消要分级，超时要有人管；全凭前台口头判断，一定执行不下去。
取消分级：
提前 24 小时取消，退全额定金。
提前 4 小时取消，退一半。
4 小时内取消或不到场，不退。
超时占用：
到离席时间仍在用餐，前台按每小时加收台位费，或在下一档预订未满时免费延。
下一档已订满，则必须清台，冲突由门店承担沟通责任。
系统要做的是把规则变成可执行的动作：取消时自动算退款金额、超时时自动标红提醒、连续爽约的客户进灰名单。
这类系统和点餐系统的边界在哪？
一个管谁坐哪，一个管坐下吃什么；合并会让两边都变难用。
预订系统的输入是「几个人、什么时候、要不要包间」，输出是「哪张台、哪个时段」。
点餐系统的输入是「这桌点什么」，输出是「厨房做什么、账单多少钱」。
两者的交集只有一处：桌号。所以正确做法是共享桌台主数据，业务逻辑各自独立。
把它们做成一个大系统，最常见的后果是：预订界面被迫承担点餐的复杂度，前台用不动；点餐界面被迫加载预订规则，服务员看不懂。
对照到店服务预约系统可以看到通用规律：凡是「先占资源、后享服务」的业务，预约与履约都应该拆成两个模块。
落地时最容易做错什么？
最容易做错的是「把桌台图画成一张图片」；图是死的，规则必须活在数据里。
三个常见错误：
桌台图不可操作。 只做成一张静态图，前台还是拿纸笔记。正确做法是每个桌位可点、可选、可改状态。
时段写死。 只支持午市晚市两段，遇到宴会、包场就无解。应该支持自定义时段。
库存与订单不联动。 预订成功后桌台状态没变，导致重复预订。这是最致命的。
对照共享 KTV 空间预约系统可以看到同构问题：空间类预订系统，成败几乎全在「资源状态与订单是否强联动」这一点上。