背景
他们买过一套系统，用不起来
在找我们之前，老灶记买过一套通用的点餐系统，年费一万多。用了三个月就停了， 原因是"改个菜价要等客服，最快第二天"。周五晚上临时售罄，菜单上还在卖， 客人点了才知道没有，投诉一大堆。
所以他们这次的核心诉求其实很朴素：菜价和估清，我们自己能马上改。 听起来简单，但很多通用系统就是把这块锁在服务商手里。
7 家门店，一套系统。扫码点餐、会员储值、后台分店管理，还有高峰期那 90 分钟的极限测试。
| 客户 | 本地湘菜连锁品牌，7 家直营门店，单店 30 - 50 桌 |
|---|---|
| 我们的角色 | 小程序开发、门店后台、收银对接、上线培训 |
| 周期 | 2025 年 4 月 - 6 月，共 46 天 |
| 交付物 | 点餐小程序、会员储值、门店后台、厨房出单对接 |
| 预算区间 | 1.8 万 - 3.5 万元（本例含收银机对接） |
在找我们之前，老灶记买过一套通用的点餐系统，年费一万多。用了三个月就停了， 原因是"改个菜价要等客服，最快第二天"。周五晚上临时售罄，菜单上还在卖， 客人点了才知道没有，投诉一大堆。
所以他们这次的核心诉求其实很朴素：菜价和估清，我们自己能马上改。 听起来简单，但很多通用系统就是把这块锁在服务商手里。
店长手机上点一下"今日售罄"，厨房和顾客端同步变灰。不用打电话给任何人。
7 家店的菜品、价格、库存互不影响，但总店能看到全部。新品先在两家试，卖得好再全推。
充值、消费、余额、积分打通，跨店通用。老客在哪家店充的钱都能花，这在他们圈子里是加分项。
他们不想换硬件。我们按厂商的开放接口做了对接，前台不用改操作习惯。
上线前我们挑了周五晚 18:00 - 19:30 在两家店做真实压测。发现并发下单时后厨出单有延迟，改了队列策略才全量推。
万一小程序挂了，店里还有纸质菜单和手工单。我们写了一页应急预案贴在收银台后面。
点餐不用等服务员，高峰期的等待时间明显缩短。这是店长给的估算。
主要来自估清同步和价格透明，客人在手机上就看得到。
三个月累积，其中储值会员 1100 多人。复购率比非会员高一倍。
每家店高峰期可以少安排一名点单服务员，人力成本降了。
我们最初把"优惠券"做得太灵活：满减、折扣、赠菜、限时，四种能叠加。结果上线两周， 有两桌客人叠加出了 3 折的单子，店长发现时已经核销。财务对不上账。
后来改成：一桌只能用一张券，且必须由店长在后台手动核销。 灵活性下来了，但可控。餐饮这种高频小额的场景，宁可笨一点，也要堵住漏洞。
他们在开第 8 家店的时候，后台加一家店只需要我们十分钟配置。目前按年签的运维，逢年过节前做一次活动页。