正餐堂食中餐厅 · 桌台正餐
桌台多、加菜频繁、包间带最低消费，最容易出错的是并单和规格。
一桌多轮加菜合成一张单
01 · Pain Points
这四件事卡住了餐饮门店的效率
01
高峰时段堵在点餐这一步
服务员来回跑不过来，顾客扫码不会用，收银机前排长队。本来翻台率能再提 30%，卡在这不动。
02
后厨不知道哪桌等得最急
一张小票就是一张小票，凉菜出了热菜还没动，或者反过来。哪个档口忙不过来、哪个档口闲，没数据。
03
回头客凭感觉认，没有会员锚点
今天过来的客人是不是上周那个、点了什么、来过几次——靠店长记性。想发个券拉复购，不知道发给谁。
04
结账环节是整段体验的尾巴
要等服务员拿单据过来、算对、再去收银台排队。房账挂账错一笔要翻一整天单，协议单位对账更痛苦。
02 · Business Types
先对号入座：六种业态，卡点不是一个
同样是“做个点餐小程序”，正餐店要的是并单不出错，茶饮店要的是高峰取餐节奏。下面按业态写清楚各自的难点。
正餐堂食
火锅烧烤火锅 · 烧烤
锅底、加汤、加菜、按时长计费都落在同一张单上，计时和加菜最常起争议。
锅底单独立计费，加菜不拆单
酒店餐饮酒店餐厅 · 客房送餐
住店客人的餐费要挂进房账，退房时和客房消费分开列清，错一笔要翻一整天单。
房账挂账，明细可追溯
茶饮烘焙茶饮 · 咖啡 · 烘焙
单量高、单价低，复购靠会员和券；高峰取餐节奏比界面好不好看更要紧。
会员储值 + 下单取餐叫号
食堂快餐食堂 · 快餐档口
高峰只有那一个小时，预点单、分档口取餐、扫码与刷卡并行，把排队压下去。
提前点单，分档口取餐
多档口大店大店 · 多档口并出
凉菜、热菜、主食、酒水各一个档口，一张单要拆到各自对应的打印机上。
按档口自动拆票出餐
03 · User Flow
从顾客进店到结账，6 步走通
下面是一张典型餐店的业务流程，每一步对应到系统里的一个功能入口。
01
顾客进店
扫码桌号自动带上
02
选菜加规格
口味/份量/加料
03
多次加菜
合并到同一张单
04
自动拆档口出票
凉菜 / 热菜 / 主食 / 酒水
05
后厨出餐
按档口节奏，不打乱序
06
结账
微信支付 · 房账挂账 · 协议单位
这 6 步同时留下了什么
桌号与人数菜品与规格加菜时间档口出票时间结账方式挂账房号
这些不是顺手记的流水，是后面营业报表能算准的前提：翻台率、档口负荷、菜品销量都从这几步里出。手工点单、口头传菜的门店，这一段数据基本是丢的。
第 1–3 步都在这一扫里完成：桌号自动带入，加菜回到同一张单。
这一段最容易错的三个地方
- 加菜被开成新单，结账时两单对不上；
- 规格没选清，退菜重下单多跑一圈；
- 并桌后人数和最低消费算不清。
第 4–5 步落在后厨：一张单按档口拆票，出餐节奏不打乱序。
04 · Four Screens
四个端，各自只看自己那一块
顾客看菜、服务员看台、后厨看票、老板看数。下面把四个端的字段和动作列清楚，接口只有一套。
顾客端 · 微信小程序
点菜、加规格、下单、买单
桌号 A08 · 4 人已开台
- ¥38
口水鸡 ×1
少辣 / 常温
- ¥32
干锅花菜 ×1
不辣 / 加腊肉
- ¥88
鳜鱼 ×2
葱油 / 例份
加菜自动并入本单合计 ¥190
下单 · 已送 3 个档口
服务员端 · 手机 / H5
开台、改桌、催菜，不用回收银台
A08
用餐中
A09
待清台
B02
已并桌
B03
空台
开台换桌并桌加菜退菜催菜
后台改完，顾客端实时同步；不会出现在顾客手机上还是旧桌号的情况。
后厨端 · 浏览器 + 云打印
按档口出票，不拿乱序
凉菜档已等 02:10
#2318 · A08
口水鸡 ×1 少辣
热菜档已等 08:20
#2318 · A08
鳜鱼 ×2 葱油
主食档已等 01:05
#2321 · B02
米饭 ×6 / 干锅花菜 ×1
超时颜色在屏幕上直接提示，哪个档口堆单一眼能看到。
PC 管理后台
营业、菜品、档口与房账
今日营业额
¥12,480
单量
186
翻台
2.7
新会员
23
鳜鱼
干锅花菜
口水鸡
房账挂账单独列表：房号 · 餐费 · 退房日期，财务对账不用逐单翻。
以上为功能结构示意，不是交付界面：配色与排版按门店 VI 重做，字段与流程以需求确认稿为准。
05 · Modules
8 个功能模块，覆盖一家餐店的日常
01
桌台与开台
每桌一码，扫码自动带桌号；换桌/并桌/拆单后台改完，顾客端实时同步
02
扫码点餐与规格
菜品按分类陈列，口味/份量/加料拆规格；同一桌多次加菜合并一张单，不拆单
03
后厨分档口出餐
一张单按档口自动拆票，凉菜/热菜/主食/酒水各走各的打印机
04
结账与房账挂账
微信支付/现金/挂账并行；房账挂账单独留明细，退房时客房餐饮分开列
05
会员与储值
等级、储值、积分规则后台配；会员识别在点餐入口就完成，下单自动算优惠
06
满减与优惠券
包间最低消费、时段券、菜品券、满减规则都靠配置，不靠收银临场心算
07
营业报表
菜品销量、桌台翻台、时段订单、渠道来源按天/周/月出
08
服务员手机端
开台、改桌、并桌、加菜、改单全部手机操作，不用回收银台
06 · Architecture
技术架构：四端 · 一套后端 · 按需对接
小程序、服务员端、后厨端、PC 后台共用同一套后端接口；对接能力按门店实际情况配置，不强制全都上。
L1 · 入口层
顾客小程序
服务员端
后厨出餐端
PC 管理后台
L2 · 业务层
桌台与开台
扫码点餐
分档口出餐
结账与挂账
会员与储值
满减与券
营业报表
服务员操作
L3 · 数据层
MySQL
业务数据 · 会员 · 订单
Redis
缓存 · 队列 · 实时状态
对象存储
菜品图片 · 小票 · 附件
L4 · 第三方对接（按需配置）
微信支付
云打印机 API
短信服务
房账 / ERP / POS
核心约束：四端共用一套后端，域名和服务器只需一份。对接层按门店实际需要开，不强制全部上线。
技术选型
- 顾客端：
- 微信原生小程序，独立发版
- 服务员端：
- 小程序 / H5，扫码即用
- 后厨端：
- 浏览器打开，云打印机自动出票
- 管理后台：
- Web 端，与移动端共用同一套接口
- 服务端：
- Java，前后端分离，RESTful 接口
- 数据与存储：
- MySQL · Redis · 对象存储
07 · Real Case
真实案例：南京小曼谷酒店
一家有堂食和客房送餐的酒店，餐饮账要能挂进房账，退房一起结清。
交付形态
南京小曼谷酒店 · 顾客小程序 + 服务员端 + 后厨出餐端 + PC 后台，四端同步交付
核心做法
同一桌多次加菜合并一张单；菜品按档口自动拆票；住店客人餐饮账挂房账，退房统一结清
交付归属
源码、数据库脚本、部署文档按合同移交，著作权归客户
08 · Template vs Custom
模板版 vs 定制版：怎么选
模板快、便宜，但改不了流程。定制灵活、能对接，但投入要多。先判断你的店处在哪一边。
| 对比项 | 模板版 | 定制版 |
|---|---|---|
| 适用场景 | 单店或 10 家内、流程标准、没有内部系统对接需求 | 有特殊流程（房账、协议单位、ERP 对接）、想做自己的会员体系、长期用 |
| 投入范围 | 3000-8000 元 · 1-2 周上线 | 3-10 万+ · 4-8 周，按功能范围评估 |
| 源码与部署 | 不交付源码，SaaS 托管，不能自己改 | 完整源码 + 数据库脚本 + 部署文档，可私有化部署 |
| 二次开发 | 功能固定，改不了；能改的只有展示文案 | 流程、字段、对接、报表都能改，后续自己团队接手也可以 |
| 对接能力 | 一般只有微信支付 | 房账系统、ERP、POS、自助取餐柜、打印机 API 按需对接 |
09 · FAQ
关于餐饮点餐系统的常见疑问
我是一家小店，有必要做定制吗？+
看两件事：有没有房账/协议单位挂账、有没有自己的会员体系需求。如果都没有，先用模板版验证；如果有其中一件，定制版的钱不会白花——房账挂账错一笔损失的钱就够来回项目了。
小程序和服务员端、后厨端，是不是要分别买域名和服务器？+
不需要。四个端共用同一套后端接口，域名和服务器只买一份。小程序走微信托管，手机端和 PC 后台都挂在同一个域名下。
后厨的打印机用什么？能接现有的吗？+
后厨出餐用的是云打印机，常见品牌是芯烨和飞鹅。现有打印机如果支持开放 API 可以直接对接；如果不支持，建议换云打印机——本地打印机会出现"小票没打出来但单已经落了"的情况，排查成本高。
做了这个之后，收银和服务员是不是可以少招几个？+
不能直接说减几个人，但能做两件事：一是服务员不用来回跑收银台，翻台率自然提升；二是收银员的工作从点餐+结账变成只负责异常情况。人还是需要，但每个人的时间花在更值钱的地方。
会员体系怎么做？要对接外卖平台吗？+
会员体系建议先把到店的客人锁住，再考虑外卖。外卖平台的用户数据在平台手里，不能用来做自己的会员。小程序会员跑通之后，再考虑要不要把外卖订单也导进来做积分。