去年接的一家连锁酸菜鱼店，三家门店，老板的诉求只有一句：顾客扫码就能点。真做起来才发现，这一句话背后改了六版，前后四个多月，餐饮类的小程序定制几乎没有例外都要过这几关。把这段复盘写出来，做餐饮的朋友可以对号入座，少走弯路。
第一版输给了高峰期
第一版上线两周，晚市高峰系统就卡住了。三家店同时扫码，峰值一分钟能进来两百多单，最初的服务器配置扛不住，点单页面转圈。加配置是小事，真正的问题是下单接口设计时没考虑并发排队，改起来伤筋动骨。餐饮定制的第一个教训：白天堂食高峰就是你的压力测试，容量要按最高峰算，不能按平均值算。
第三版开始懂服务员了
前面几版都是顾客视角，改到第三版才发现真正天天用系统的是服务员。桌台被扫错码、顾客中途加菜、退单要店长审批，这些真实场景店里天天发生，功能里却没顾上。第四版加了服务员端：桌台状态一屏看清，加菜合并到原单，退单一键提交。上线后点错桌的投诉从每周十几次降到基本没有。餐饮小程序定制里，后台好不好用，直接决定门店愿不愿意用。
顺带说个细节：菜单图片的尺寸，第一版没人管，顾客一进店先加载三秒图。后来定了规范，图片上传自动压缩到两百K以内，首屏速度降了一半。餐饮场景里，顾客是站在店门口扫码的，等不了三秒，这种细节模板不会提醒你，只能靠踩坑，踩过的坑都替你写在本文里了。
最后两版在抠会员细节
储值和会员是老板最上心的部分，也是改版最多的地方。储值赠送规则换了三套方案，满减和折扣的叠加顺序反复调整，积分抵扣的比例改了又改。这些不是技术问题，是经营策略在系统里的试错。好在架构上把营销规则做成了可配置，老板自己在后台改，不用找开发，这一步是后面迭代快的关键。规则可配置的另一个好处是试错便宜，活动效果不好，后台改回来就行，不用等人排期。
现在这套系统服务着三家门店，月订单两万四千多单，老板的总结很实在：系统是改出来的，不是一次买对的。两条建议送给准备做餐饮小程序定制的朋友：容量按高峰期算，别省这份服务器钱；营销规则一定要求做成后台可配置，不然每一场活动都是一次开发费。比格网络做餐饮类项目的经验也验证这一点，前期架构多想一步，后期省钱省心。
