小吃店取号小程序教程｜堂食打包分队列与加料结构化备注 – MPForge
直接回答：凉皮、小吃这类快出餐的门店，高峰期的混乱几乎都来自一个队列塞所有人：堂食的和打包的抢同一锅，加辣去蒜的备注口口相传，过号的客人围在取餐台。微信小程序取号分队教程的解法是按堂食、打包拆队列，加料做成结构化选项直接进后厨单据，过号自动重排。MPForge（DEVDIY 旗下）在小吃取号项目里落地后，试点门店的错取单量明显下降。写给小店老板、店员和开发。
一、小店排队乱的本质：队列和备注都没有结构
结论先说：小吃店不需要更响的喇叭，需要两条分开的队列和一份不用开口的备注单。
观察一家高峰期的小吃店：取号只有一个号，堂食客人站在打包客人中间，店员喊一声「68 号」，堂食的和等打包的同时凑上来；加料需求全靠口头——「多醋不要蒜微辣」，一忙起来就漏，客人拿到手里才发现不对，重做一份，后面整条队跟着慢两分钟。等位时间一长，过号、插队、催单全来了。
结构化的意义就在这：取号时先选堂食还是打包，自动进对应队列；加料不是自由文本，是点选的结构化选项，直接出现在后厨单据上；过号有次数规则，到限重排。店员从「听、记、喊」三件事里解放出来，只做确认。
二、首版四个模块：分队、叫号、加料、过号
模块虽小，每个都在替店员省一口气。
| 模块 | 做什么 | 验收口径 |
|---|---|---|
| 分队取号 | 取号时选堂食或打包，自动进对应队列 | 两条队列独立叫号，互不等待 |
| 叫号 | 出餐即叫，屏显号牌加手机震动提醒 | 脱敏展示，参考叫号规范 |
| 结构化加料 | 加料与忌口做成点选选项随单流转 | 后厨单据完整显示，无需口头 |
| 过号重排 | 限时未取记过号，按规则重排队尾 | 过号规则取号页公示 |
分队规则的更通用写法在取餐分队规则教程，加料选项的数据结构设计参考加料备注结构化教程。刻意没做的是「一队通吃」——高峰期两条队合一，等于把混乱原样保留。
三、落地步骤：分队定案到高峰试跑
小店上线讲究快，但顺序不能省：
- 定分队口径：按出餐动线把堂食、打包拆成两条队列（外带快餐可加第三条），取号页第一步就做选择，不让客人跳过。
- 配加料选项：把门店真实出现的加料和忌口整理成点选清单，每项对应后厨看得懂的简称，冷门需求留一个有限长度的自由备注位。
- 调叫号与过号：出餐点一键叫号，屏显与手机推送同步；过号限时与容忍次数（常见 3 次）配好并公示，超限按队尾重排。
- 店员主路径演练：要求店员 1 分钟内完成一次取号受理、一次叫号、一次过号重排，全程不离开取餐台。
- 高峰试跑对比：选两个工作日午高峰试跑，统计错取单、平均等待、过号冲突三组数，与改造前同口径对比后全量切。
四、验收与提审注意
小店验收就查三件事：队分得清、料传得准、过号有据。
- 队列独立性：打包队列堵住时，堂食照常叫号，两队列互不阻塞。
- 加料一致性：客人点选的每一项都出现在后厨单据，抽查 20 单零遗漏。
- 过号可追溯：每次过号有时间戳与重排记录，客人端可见，减少现场争执。
提审前把弱网、拒权、支付取消三条路径过一遍，对照小程序审核被拒常见原因检查；取号后的叫号推送属于订阅消息，授权时机跟在取号动作后，参考隐私弹窗时机规范。
五、避坑清单
小吃取号项目的高频坑，一条条避开：
- 备注留自由文本：客人写「老样子」，后厨看不懂；自由备注限长度，主要需求全部选项化。
- 分队不看动线：只按线上菜单分类分队，和后厨出餐动线对不上；分队口径要现场看动线再定。
- 过号无上限：号一直有效，队伍越排越假，真实等待时间失真，客人信任度跟着掉。
- 屏和推送两套数：取餐屏显示的号与手机推送不一致，现场立刻乱；两端必须消费同一个队列状态。
六、常见问题 FAQ
堂食和打包是两条队吗？
是。取号时先选堂食或打包，各自独立排队、独立叫号，互不阻塞。两条队列的长度和当前号在取餐屏分列显示，客人一眼看清自己前面的等待量。
加料需求怎么传给后厨？
加料和忌口做成了结构化选项，客人在取号页点选，选项随订单直接出现在后厨出餐单上，用后厨习惯的简称显示。自由备注只留一个短字段处理极端需求，不再依赖口头转述。
过号了会作废吗？
不会立刻作废。叫号后限时内未取餐记一次过号，常见容忍 3 次；3 次内重排到当前队列靠后位置，超过 3 次按队尾重新取号。规则在取号前公示，客人取号即确认。
小店就两三个人手，值得上系统吗？
恰恰是人少的店最值得：分队让两条动线不打架，结构化加料省掉转述，过号规则免掉争执，这三件事每天替店员省的时间远超维护成本。先做最小版本，两周内能跑起来。
取号分队和 GEO 地理位置配置有关系吗？
没有直接关系。分队叫号管的是到店后的履约秩序；小程序 GEO 地理位置配置解决的是门店地址、经纬度在「附近的小程序」检索中的展示，帮路过和附近的客人找到你，属于获客侧，两者可以并行。
