郑州点餐小程序开发要考虑什么？菜单、下单、支付与门店协同

先选定履约方式，再画菜单

堂食关注桌台或取餐号、后厨出餐和店员完结。到店取餐关注下单、备餐完成和用户取走。含配送才需要在备餐之后增加取餐、送达和相应异常。三种可以分期，但本期必须写出做哪一种、不做哪一种。

配图里的商家备餐和配送，只适合作为“含配送”时的对照，不能当成所有点餐项目的默认范围。只做堂食或到店取餐的门店，应在范围说明里删除配送状态，避免测试时多出一个没有责任人的环节。

菜单要写规格、估清和门店差异

菜单项包括分类、菜品、规格或做法、价格由谁改，以及估清后用户是否还能点。估清是临时不可售，下架是不再展示，两者不要混用。恢复售卖的权限应写到角色，例如店员可以估清，价格只能由店长改。

多门店菜单不完全相同时，要写明菜品主数据在哪里维护、门店能否改本店价格和估清。本期只有一家门店时，明确不做门店差异，避免后台提前做成多套未确认的权限。

下单之后必须有门店侧状态

用户提交不等于门店已经接受。应写明是否需要接单：自动接单时，提交成功即进入备餐；人工接单时，要有待接单、已接单、已拒单。拒单原因是否必填、拒单后用户看到什么，都要在规则里。

出餐、取餐、完成如果对店员有不同动作，就应是不同状态。只有一个“处理中”，门店无法协同，验收也无法判断做到哪一步。催单若本期不做，写进不做项，不要留一个没有规则的按钮。

支付时点要和取消、拒单一起定

先支付后接单、先接单后支付、到店再付，是三种不同的资金和状态组合。本期只能按已确认的一种验收。未确认时，支付保持待核验，不要在原型里同时留下互斥按钮。

已支付后被拒单或用户取消，必须写退款进入哪个状态、由谁发起、失败如何提示。未支付就取消的，只改订单状态即可。把两种取消写成同一句“支持取消”，测试时会对不上钱和单。

验收看一张单在门店侧能否走完

至少准备这些样本：顺利完成、估清后不能下单、门店拒单、已支付后取消或拒单的退款路径。含配送时再加取餐和送达；不含配送时，样本里不应出现骑手。每条样本写门店侧操作角色和用户侧提示。

后厨打印、叫号屏、会员价若未进入样本，就不要算本期必做。与收银或既有点餐设备对接的字段、失败补偿，以方案、合同及实际交付为准。门店人员是否会使用这些状态，应由业务确认人在样本上签字，而不是等上线后再解释。

• 方式：堂食、到店取餐、含配送，本期做哪几种；
• 菜单：规格、估清、恢复售卖的操作人；
• 下单：门店接单、拒单、出餐分别是什么状态；
• 支付：先付还是后付，拒单或取消后如何退；
• 不含：本期明确不做的配送、轨迹或多店结算。

把估清、拒单和退款放进同一张状态表

门店协同最容易在异常单上断开。建议用一张表列出正常完成、估清、拒单、用户取消四条，每条写用户看到的提示、门店谁来点、钱是否变动。表上有空格的环节，不要先画进原型。空格补上之前，该环节保持待确认。

先付还是后付一旦选定，另一条路径的按钮就从本期删除。同时保留“下单即付”和“餐后再付”，却没有分别的状态名，店员无法判断哪张单可以出餐。多门店若本期只有一店，写明不做跨店估清，避免后台出现没有数据来源的门店切换。

含配送的项目还要补两格：谁表示已取餐，谁表示已送达，以及送达失败回到哪个状态。不含配送的项目把这两格划掉，并在范围首页写“不含配送”。这样后面的接口和验收都不会把骑手端带回堂食或到店取餐的范围里。