大多数老板在挑选订位系统的时候，第一个问题往往是"哪家的预订界面好看"。这其实问错了方向。预订界面只是顾客在线上下单那十几秒钟会看到的部分，而这套系统真正要做的事，是每天晚上连续运转好几个小时，串起前台、大堂和后厨，让三者保持同步。销售在演示里展示的内容，很少会覆盖那些真正决定这套系统半年后还好不好用的细节——而这些恰恰是签合同之前最该问清楚的问题。
这件事的重要性，比"界面好不好看"高得多。据OpenTable对顾客爽约行为的研究，全美有28%的人表示自己过去一年里有过预订了却没到店、也没取消的情况；而通过专业订位平台预订的顾客，比起通过餐厅自家网站或搜索引擎入口预订的顾客，爽约的可能性明显更低。光是这个差距，就足以说明订位系统是一项真正影响经营的决策，而不是锦上添花的选配。下面这份清单，就是真正能区分出"能回本的系统"和"又一台孤立在前台的平板电脑"的那些问题。
任何一套订位系统都能接受预订，但真正能降低"预订变空桌"这个风险的却不多。该向供应商问的具体问题是：大桌或高峰时段能不能要求预付定金或绑定信用卡，能不能在预订时间前发出足够及时的自动确认和提醒，以及在确认下一次预订之前，能不能看到这位顾客过去的爽约记录。一套只负责接单、其他什么都不管的系统，其实只解决了问题里比较容易的那一半，把真正难啃的那一半——爽约本身——原封不动地留在了原地。
一套跟POS和前台原有的候位系统完全脱节、自成一体的订位系统，会造成和后厨里"多台外卖平板各自为战"一样的分心问题。一个前台员工，要在周五晚高峰同时应付纸质候位单、订位平板和POS屏幕，等于一个人干着三份本该合并成一份的工作。软件演示时看起来精不精致其实是次要的，更该问的关键问题，是桌台状态、临时候位和已确认的预订，是不是显示在前台员工本来就在看的同一个画面里——这样安排入座才不需要来回切换三套系统去确认这张桌子到底空不空。
这是大多数演示环节都不会被问到的问题，但往往是周五晚高峰最要命的一个环节。一套靠谱的订位系统，不会只是记录"这位顾客没来"，而是会按一个清晰的计时器，自动把这张桌子标记为可再次使用，前台不需要凭感觉猜十五分钟到了没有，也不用出于谨慎一直空着不敢动。可以具体问一问：系统怎么区分"稍微迟到"和"确认爽约"，这个判断是要前台自己记时间，还是系统会自动提示。这一个问题的答案，比功能列表上的大多数条目都更能说明这套系统是不是真的照着一个真实的大堂设计出来的。
对不少亚裔餐厅来说，相当一部分顾客——常常还有相当一部分员工——用中文、韩语、日语或西班牙语沟通会比用英语更自在。一条只有英文的确认短信或候位提醒，哪怕顾客点开看了，也未必能完全看懂；一个只有英文界面的前台系统，也会让一部分员工用起来更慢、更没底气。这一点最好在评估阶段就直接、具体地问清楚，而不是想当然地以为大平台默认都支持——大多数平台设计之初根本没把这个当成一项硬性要求。Chowbus的订位与候位系统支持用英语、中文、日语、韩语和西班牙语跟顾客沟通，也支持这几种语言的前台操作界面，这一点很关键，因为一套员工用不顺手的系统，在最忙的时候只会变成瓶颈，而不是帮手。
订位系统的报价很少是一个干净的数字。看得见的是基础订阅费，看不见的是按顾客人数收的费用、短信或通知费用，以及定金收取、高级数据分析这类"高级功能"往往单独计费。要诚实地比较两套系统，唯一的办法就是按自己餐厅的实际预订量，问清楚全部加起来的月度总成本——而不是官网首页写的那个起步价，要把通知、定金、报表这些一旦真正启用就会产生的费用全部算进去。
预订和临时到店，本质上争的是同一种资源——空出来的桌子——但不少平台把它们做成了两个硬拼在一起的独立产品，一旦餐厅试着把一位临时到店的客人安排进一张技术上已经被当晚稍后预订占用的桌子，问题立刻就会暴露出来。更该问的问题是：预订和候位是不是共用同一张实时桌台地图，这样前台就不需要来回对照两个屏幕，才能弄清楚接下来十分钟到底还有没有空位。Chowbus的候位系统正是设计成跟订位共用同一份桌台数据，而不是各跑各的一套，就是为了避免前台同时管理两幅互不相通的大堂画面。
订位系统的价值不只体现在忙碌的周五晚上，也体现在生意慢下来之后，一整季的预订数据能帮餐厅看清什么。可以问一问：这套系统能不能方便地看出老客户的复访规律、平均party人数的变化趋势，或者哪几个晚上一直预订不满，以及这些数据是不是真能导出、真能拿来用，而不是锁在一个没人有空细看的后台里。一套只在高峰时段有用、其余时间就闲置的系统，等于白白浪费了一半的价值。
在签合同之前，最好能就以下几点拿到一个明确的、最好是书面的答复：能不能靠定金或提醒机制减少爽约，是否跟POS和候位系统共享实时桌台数据，能不能自动处理爽约计时，是否支持这家餐厅员工和顾客真正在用的语言，以及按这家餐厅实际预订量算下来，每月真实成本是多少。一个能把这五点都答得清楚、不绕去功能介绍页糊弄的供应商，通常可以放心地进一步深谈。
Q1: 购买餐厅订位系统之前，应该问哪些问题？
最重要的几个问题是：能不能靠定金或提醒机制主动减少爽约，能不能跟POS和候位系统共享实时桌台数据而不是各自独立运行，能不能自动处理爽约计时，是否支持餐厅员工和顾客实际使用的语言，以及按这家餐厅实际预订量算下来的真实月度成本，而不是官网上标出的起步价。
Q2: 订位系统到底怎么才能真正减少爽约？
靠的是大桌或高峰时段的定金或信用卡绑定要求、贴近预订时间发出的自动确认和提醒，以及在确认新预订之前能看到顾客此前的爽约记录。如果一套系统只是单纯接受线上预订，缺了这些机制，对爽约行为几乎起不到什么改变作用。
Q3: 订位系统是独立于POS更好，还是跟POS打通更好？
对于有实际大堂运营需求的餐厅来说，几乎总是打通更好。一套独立的订位平板，会让前台不得不在一个系统里查桌台状态、在另一个系统里安排入座，这跟后厨里"外卖平板各自为战"是同一个分心问题。能跟POS和候位系统共享实时桌台数据的订位系统，能让前台看到一份准确的画面，而不用来回对照两套系统。
Q4: 餐厅订位系统一般要花多少钱？
报价通常不是一个数字——基础订阅费往往只是起点，按人头收费、通知费用，以及定金、数据分析这类高级功能常常单独计费。唯一靠谱的比较方式，是按这家餐厅的实际预订量，算出把所有真正会用上的功能都打开之后的月度总成本。
Q5: 我们店中文顾客和中文员工都不少，订位系统需要支持中文吗？
需要，而且这一点最好在评估阶段就直接问清楚，而不是想当然地以为大平台默认都支持。顾客看不懂的确认信息或候位提醒，或者员工用不熟练的前台界面，都会让一套本该提高效率的工具，反而在最忙的时候拖慢速度。
Q6: 评估餐厅订位系统，第一步该做什么？
在参加任何演示之前，先把这些具体问题写下来：能不能减少爽约、是否跟POS和候位系统打通、能不能自动处理爽约计时、支持哪些语言，以及按实际预订量算下来的真实成本。带着这份清单去谈，而不是被动看演示先展示什么，才能问出功能介绍页本身不会主动说明的那些差距。
一套在十五分钟演示里显得很精致的订位系统，和一套真正能扛住周五晚高峰、大堂坐满、候位队伍越排越长的系统，未必是同一回事。上面这些问题，恰恰是能把两者区分开的关键，原因也很简单：这些细节从来不会在销售对话里自动浮现，除非有人直接开口问。带着这份清单走进对话的餐厅老板，最终买到的会是这套系统在真实高峰时段的表现，而不是它在演示里静止不动时的样子。
