外卖是一门与到店用餐截然不同的生意。顾客不会坐下来，没有桌位可以安置他们。他们想知道两件事：食物什么时候好，以及怎么付款。一切阻碍这两个问题得到答案的因素都是摩擦，而摩擦会将订单输给流程更顺畅的竞争对手。
过去几年里，外卖的运营模式已经从电话接单和步行台转向了一套 QR 码加排队的工作流，并且这套流程是可扩展的。顾客取一个排队号，在自己手机上组建订单，通过上传银行转账凭证完成付款，叫号时来取餐。整套流程在浏览器中运行，无需应用、无需前台、无需耳机。
本文将梳理让这套流程在真实餐厅中切实可行的关键决策。
独立的外卖定价
第一个决策是外卖价格是否应与到店价格相同。在许多国家，答案是否定的。到店用餐包含餐具、玻璃器皿、桌面服务和整体体验。外卖包含包装，以及顾客将在其他地方用餐的预期。成本结构不同，支付意愿也不同。
常见的做法是外卖小幅加价，也许 10% 到 15%，以覆盖包装和打包取餐的边际人工成本。也有餐厅反其道而行，提供外卖小幅折扣，因为省去了洗碗和翻台成本。无论哪种方式，菜单系统都需要支持每道菜品独立的外卖价格字段，与到店价格区分，且仅在顾客下取餐订单时显示。
菜品还需要一个独立的外卖可用性开关。有些菜品不适合外带。舒芙蕾、精致的肉排、多组件摆盘甜点——这些都不适合出现在外卖菜单上。它们应保留在到店菜单上，但通过一个开关从外卖列表中隐藏，而非维护两套并行菜单。
两阶段订单确认
经典的错误是将外卖订单视同网站结账，让顾客在最后一次性确认所有内容。实际上这会失效，因为付款步骤是最慢、最容易出错的部分。银行转账需要时间。顾客可能误输金额。凭证可能不清晰。如果订单在付款确认之前就已锁定，厨房开始备餐却可能得不到报酬。
更好的工作流是两阶段交接。第一阶段：顾客下单。系统记录菜品，计算总价，以顾客支付的货币显示清晰的总金额。第二阶段：顾客上传付款凭证。在餐厅手动确认凭证有效之前，订单处于"待确认"状态。厨房不开始备餐。顾客的状态标签显示"等待餐厅确认付款"，让他们知道皮球在您这边，而不是他们那边。
这听起来很慢，实际上员工确认只需十秒钟——打开看板，瞥一眼凭证图片，点击按钮。厨房在付款确认的那一刻而非之前看到订单，这正是最合适的时机。
不宕机的付款凭证上传
凭证上传最常见的故障模式是权限问题。顾客手机使用各种随机 IP 地址。图片大小从 200 KB 到 10 MB 不等。有人截图银行 App，有人用相机拍打印收据，有人粘贴从聊天转发来的图片。上传系统必须在不报错的情况下吸收所有这些情况。
几条实用规则。第一，接受多种图片格式：JPEG、PNG 和 WebP 基本覆盖所有手机摄像头和截图工具。第二，使用有效期仅数分钟的预签名上传 URL，使上传直接从顾客手机到存储空间，不经过您的服务器中转。第三，在发放 URL 前于服务器端验证文件类型。第四，将凭证存储在清晰命名的路径下，以便日后发生付款争议时可以审计。
面向顾客的界面应该是一个标注"上传付款凭证"的大按钮，而非多步骤表单。上传后，向顾客展示凭证的缩略图，并提供"替换"选项，以防他们上传了错误的截图。顾客的状态标签应立即翻转为"等待餐厅确认"，让他们知道上传成功。
取餐参考码
当顾客前来取餐时，您需要一种快速将其手机与屏幕上订单匹配的方式。在安静的餐厅里大声叫号还行，但在有五个 12 号在排队的嘈杂网红奶茶店里就会失效。
一个来自无易混淆字符集的六字符短参考码可以解决这个问题。在下单时由服务器端生成，显示在顾客手机上，与排队号码并列展示。员工看板上显示同样的参考码。顾客到达时出示手机，您比对参考码，递出袋子。整个交接不超过三秒，从不依赖叫喊名字。
参考码也起到防欺诈作用。顾客无法在不出示对应参考码的情况下声称"我是 42 号"。在任何合理的场景中，两个随机人在同一天不可能撞上同一个参考码。
日终对账
外卖收入需要每日与银行转账对账。最简单的方法是在排队看板中设置一个历史视图，列出某天所有标记为"已完成"的订单，包含排队号、参考码、时间、金额，以及凭证图片链接。选择一个日期，查看列表，看到当日总额，与银行流水交叉核对。每天五分钟，最好作为闭店例程的一部分。
历史记录需要正确处理时区。曼谷当地时间午夜关店的餐厅，应看到该日历日期的所有订单汇总在一起，而不是在晚餐服务中途被 UTC 午夜截断。系统应知道餐厅所在国家，并使用当地时区进行分组。
出现问题时如何处理
在任何真实的工作流中，边缘案例都会发生。顾客付款金额有误。凭证不清晰。顾客始终没来取餐。厨房在下单和确认之间的时段用完了某道菜的食材。
针对每种情况，设计一条清晰的处理路径。金额有误：员工打开订单，查看问题，要么接受附注的部分付款，要么请顾客重新付款。凭证不清晰：员工联系顾客（如有手机号）或直接不确认；顾客发现状态卡住后会重新上传。顾客未到：队列条目保持"备餐中"状态，直至手动标记为"已完成"或"已取消"，之后从活跃列表中移出。
下单和确认之间出现食材缺货是最令人头疼的情况。最干净的解决方案是退款至顾客同一银行账户，附上道歉和说明。系统应让这件事变得简单：看到凭证后可以使用的取消按钮，顾客手机立即反映取消状态。
不要过度优化理想路径
设计外卖流程时的诱惑是假设每笔订单都顺利完成，并据此设计界面。这是一个陷阱。大多数订单确实顺利，但那些出问题的订单会占用不成比例的时间，并产生最多的客服工作。先围绕最差情况构建工作流，理想情况自然会妥善处理。
顾客能在三秒内读懂的清晰状态标签。显示员工所需一切信息的看板。快速交接的参考码。日终对账的历史视图。加上一个默认预期：部分订单需要人工干预，而系统让这种干预变得容易而非不可能。把这些做对，您就拥有了一套可扩展的外卖运营体系。
