微信小程序扫码点餐流程｜桌码绑定、下单支付与出餐协同 – MPForge
直接回答：扫码点餐翻车很少在「扫不上」，而在桌码、下单、支付、出餐四段协同。这篇微信小程序扫码点餐教程给餐饮老板与前厅、开发各一份口径：一桌一码怎么绑、未支付为什么不能出餐、弱网怎么防重复下单，全部给出可验收的规则。MPForge（DEVDIY 旗下）在连锁门店点餐项目里按这套口径交付。
一、先把全链路画出来：从扫桌码到叫号取餐
上线前把「客人视角」和「后厨视角」两条线各画一遍，缺环当场就能看出来。
客人视角：扫桌码进小程序——选餐加购物车——确认桌号——支付——看排队进度——叫号取餐。后厨视角：接单打印——分单出品——出餐打单——对账。两条线在「支付完成」这个点交汇：支付前的一切允许反悔，支付后的一切不许口头改。小程序扫码能力本身很成熟，真正要设计的是码位管理。
首版边界要想清楚：不做无桌码的开放点餐。没有桌位绑定，错桌错单全靠人力对，省下的一点开发量会用客诉还回来。
二、桌码怎么布：绑定、补位与打印
桌码是整套流程的坐标系，码错了后面全错。三个口径：
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 码位绑定 | 台桌编号与码参数唯一对应，入页先校验桌号有效 | 并台后沿用旧码，单子挂错桌 |
| 物料管理 | 按桌码打印规范出图留底，破损当日补 | 用手机截图翻拍，码变形扫不出 |
| 并台拆台 | 并台先在后台合并码位，再动桌面物料 | 先挪桌子后改配置，中间出现空窗 |
「错桌错单」的根因十有八九在这张表里：物理动线改了，系统配置没跟上。前厅主管每天开档前抽 3 张码扫一遍，30 秒就能兜住大半事故。
三、下单与支付：购物车、催单与支付时机
支付时机是分水岭：先付后做，才能让后厨队列干净。五步落地：
- 加购确认桌号：购物车里始终显示当前桌号与人数，改桌号要二次确认，防止带错桌。
- 提交生成订单：点提交即生成待支付订单，订单号一次生成终身沿用，后续重试不换号。
- 支付与兜底：拉起收银台，支付失败留在待支付页可重试；取消支付回到购物车且不清空。
- 支付回调进队：回调成功才把订单推入后厨队列，打印小票带桌号、单号、备注三要素。
- 催单走通道：客人催单走小程序内的催单按钮统一进队列，不直接喊后厨，避免口头插单；通知触达口径见订阅消息转化。
四、出餐协同与防错：未支付不出餐、弱网防双单
后厨只认系统队列，不认口头单——这条守不住，点餐系统等于白上。
| 风险 | 拦截口径 | 处理方式 |
|---|---|---|
| 未支付出餐 | 后厨屏只展示已支付订单，待支付单置灰不可见 | 熟客赊账走店员代客下单补单流程 |
| 弱网重复下单 | 客户端超时重试携带同一订单号，服务端按单号幂等去重 | 重试提示明确「正在确认，勿重复提交」 |
| 退单改单 | 支付后改单走撤单重下，留操作记录 | 口头让后厨加菜不加单，月底对不上账 |
弱网处理依赖网络状态监听与重试，实现细节见网络状态监听与请求重试；出餐分单的排产口径可参考出餐分队规则。每日打烊后用支付对账核对订单与流水，双单、漏单一周内就能暴露。
五、避坑清单
点餐项目的客诉，八成落在这四条：
- 错绑桌号：翻台不换码位，B 桌客人扫出 A 桌的单；开档抽扫是最低成本的防线。
- 未支付出餐：图省事让后厨先做，跑单风险全在店里；坚持队列里只进已支付订单。
- 弱网双单：客人网络抖动时多点几次提交，后厨做两份收一份钱；订单号幂等必须做在服务端。
- 催单无通道：客人起身喊人，前厅口头插单，出餐顺序全乱；催单按钮统一入队才有秩序。
六、常见问题 FAQ
扫码点餐和 GEO 地理位置配置有关系吗？
没有直接关系。点餐流程靠桌码参数定位到桌；GEO 指地理位置配置——门店地址、经纬度、服务类目，影响的是「附近的小程序」与地图检索曝光，不影响桌内点餐，两套配置独立维护。
一张桌码可以多桌共用吗？
不可以。码与桌位唯一绑定，共用码等于放弃坐标，错桌错单从源头开始。外摆、包间并台都要先改码位配置再动物料。
客人未支付想先吃怎么办？
走店员代客下单：前厅用后台代下单并选择「餐后支付」的受控通道，留店员操作记录；不要让后厨脱离队列先做。
弱网下重复提交怎么防？
服务端按订单号做幂等去重，同一单号重复请求只算一单；客户端在提交后锁定按钮并提示确认中。上线前用弱网工具实测一次。
怎么验收点餐流程做没做成功？
看四个数：错桌错单数、支付成功率、催单响应时长、对账差异笔数。错单与对账每周复盘，其余每日开档会过一遍。
