如果您曾在某个周六下午站在一家座无虚席的点心餐厅门口，您已经亲历了这个问题。一块木制夹板搁在一张小小的接待台上，上面潦草地写着六七个名字，而领位员已经二十分钟没有时间抬头看人了。部分顾客认定队伍毫无希望转身离去，另一些人则在入口处站了九十分钟。餐厅在离开的人身上损失了营收，在等待的人身上损失了口碑。
解决方案不是增加员工，而是一套运行在手机上、能自动更新的虚拟排队系统。
虚拟排队系统究竟做什么
虚拟排队系统用一个公开网页取代纸质夹板。每位顾客在门口扫描 QR 码，点击"取号"，立即看到自己的排队号码和大致位置（"前面还有 4 人"）。他们可以在附近逛逛、坐在车里、打完一个电话，或者做任何比站在人行道上更想做的事。轮到他们时，再走回来。
这套系统解决了同一问题的两面。顾客端它回答了"什么时候轮到我"，无需任何人开口询问。餐厅端它回答了"如何管理客流"，无需任何人记录在案或在嘈杂的大厅里大声喊名字。
技术实现很简单。领位员平板上的一个小型看板显示带有时间戳和参考码的等位列表，当有桌位空出时点击"呼叫下一位"。顾客的手机在十五秒内更新。没有丢失的呼叫器，没有掉落的夹板，没有在嘈杂大厅里被淹没的叫号声。整套系统在浏览器中运行，无需安装应用，零门槛。
GPS 定位限制为何重要
虚拟排队系统的朴素版本允许任何人在任何地方取号，听起来不错，但立刻会崩溃。另一个城市的少年出于好奇随意取了一个号。无聊的顾客抱着昨天的号码期望明天插队。竞争对手的朋友预约了一百个虚假号码，让您的队伍看起来比实际更长。
GPS 定位限制解决了这个问题。在"取号"按钮出现之前，顾客手机先汇报其位置。系统计算到餐厅的大圆弧距离，只有当顾客在配置的半径范围内时（大多数城市餐厅通常设为五公里，市中心密集街区通常设为一到两公里）才激活按钮。
检查会进行两次。首先在浏览器端，顾客不在范围内时按钮保持禁用，提供即时反馈。然后在服务器端，在预约实际提交时进行，因为来自浏览器的位置数据在技术上是可伪造的。两次检查共同保持队列整洁，而不会给真实顾客带来不便。
对于拥有多个门店的餐厅，GPS 定位限制还能自动将顾客路由至正确的分店。恰好在市中心门店附近的顾客不会误入郊区门店的排队。
轮询等位看板的设计剖析
当顾客手机打开排队页面时，应以什么频率检查更新？太频繁会消耗电量和带宽，太慢又让等待感觉遥遥无期。
十五秒被证明是最佳间隔。慢到让服务器几乎感受不到，快到让顾客觉得页面是"实时"的。领位员点击"呼叫下一位"后，顾客的"当前叫号"数字在十五秒内更新，他们就知道自己又近了一步。低于十秒会对屏幕常亮的手机造成明显的电量消耗，拉长到三十秒或六十秒则体验开始像是在翻看一张静态图片。
看板本身应显示三个数字，仅此而已：当前服务的号码（大而醒目）、顾客自己的号码，以及两者之间的人数差。其他任何内容都是干扰。排队页面不是品牌体验，而是状态查询。
防作弊：参考码
每个预约生成一个由服务器端生成的六字符参考码。顾客在手机上看到它，在可保存的 PNG 票据上也能看到，并被要求在叫号时出示。领位员在看板上看到同样的参考码。如果某位顾客声称自己是 42 号但出示的参考码与看板上 42 号对应的不符，领位员便知道有问题。
参考码使用无易混淆字符集：没有零和 O，没有一和 I，没有看起来像数字的小写字母。在餐厅昏暗灯光下眯眼看着手机屏幕，并在嘈杂大厅里大声念出参考码时，这一点至关重要。
参考码也是一次性发放的。同一顾客无法从同一浏览器再次预约，因为系统识别其持久的客户端标识。如果他们尝试，系统会返回他们原有的号码和参考码，而非一个新的。
每次预约的成本
餐厅经营者通常认为虚拟排队系统需要昂贵的硬件或订阅合同。实际上并不需要。在 AWS DynamoDB 和 S3 上为单家餐厅运行排队系统的基础设施成本，即便每天有一千个预约，也在每月几美分的量级，因为主要操作是微小的原子计数器递增。
纸质夹板的货币成本为零，但在顾客体验上付出了真实代价。呼叫器系统硬件成本数百美元，加上每年的更换成本。虚拟排队系统除底层云计算账单外，每位顾客的成本为零。一旦您每个班次的预约量超过寥寥数个，经济账在数字方案上就已经算清楚了。
从零开始
如果您从未运营过虚拟排队，从小规模开始。在一个班次的一种服务类型（到店用餐或外卖）上启用，观察会发生什么。看顾客如何使用它，他们在哪里感到困惑，他们向领位员提出什么问题。根据您的观察调整最大距离设置、措辞和 QR 码摆放位置。
目标不是取代领位员，而是让领位员从充当纸板人肉电子表格的工作中解放出来，转而专注于迎接顾客、管理用餐区，以及处理偶尔的特殊需求。一套好的虚拟排队系统让顾客和员工都更满意，而且在您第一次避免了周六晚上的混乱局面时，它就已经回本了。
