后厨刚说一道菜卖完了，顾客却又从扫码菜单点了一份。服务员来回解释，前台还要改单。对使用扫码点餐的餐厅来说，“卖完”不能只停留在口头通知，还需要让点餐入口及时停止接收这道菜的新订单。

一、先分清临时售罄和长期下架

午市备料用完、某个规格暂时没有，通常是当班的供应状态变化；确定不再经营一道菜，才涉及长期菜单整理。两者需要的恢复方式、交接说明和检查范围并不一样。

不少系统把临时售罄相关操作称为“沽清”或“估清”。银豹官方PC收银文档以厨房配菜不足为应用场景，并提醒恢复操作不等于恢复原来的库存数量。这只是该文档对应的产品说明，不能据此推断所有系统的处理方式。

因此，先请服务方说明沽清、停售和库存数量之间的关系。本文给出的是门店核对思路，不提供可直接照搬到所有软件的按键路径，也不建议为停止点餐而随意改整店库存。

二、后厨报告时，把菜名和范围说完整

“鱼没了”“这个不要点”很容易产生歧义。建议后厨明确菜名、规格、剩余可做份数和影响范围，由指定岗位接收并操作。若同一原料用于多个菜品，也要一起核对，而不是只处理刚刚被问到的那一道。

例如，只缺某种配菜，究竟整道菜无法制作，还是仅一个套餐不能提供，应由后厨确认。不要让收银员凭经验替换食材或把所有相似菜名一起停售；需要更换做法时，应先与顾客沟通。

留下一条简短交接即可：什么时候、哪道菜、谁确认、谁处理、何时复核。记录业务状态，不需要附上顾客手机号或其他个人资料。下一班接手时才知道该恢复什么、找谁确认。

三、操作后，从顾客入口再看一遍

收银机上出现售罄标识，不等于顾客手机看到的状态已经一致。用门店实际的扫码点餐入口重新查看菜品，检查是否提示售罄、是否还能加入购物车，以及提交时怎样处理；测试应由服务方在合适的演示环境安排，不制造虚假付款。

门店同时使用桌边点餐、自提小程序或外卖平台时，要列出实际使用的入口分别确认。联动范围、同步速度、离线状态和套餐内菜品的处理，以当前版本与对接方案为准，不能只检查堂食页面就认为全部完成。

尤其留意已提交订单。设置售罄主要是为了控制后续接单，不能把它当成取消原订单或自动退款。前台应与后厨核对尚未制作的相关菜品，再根据实际订单状态，与顾客沟通继续等待、换菜或按正常流程退单。

四、补货后恢复，要再核对数量与菜单

原料送到不等于菜品已经可以出餐，先由后厨确认可制作情况。恢复时核对正确门店、菜品与规格，并检查顾客端是否重新可选；如果系统还要求维护可售数量，应按实际情况处理，不能仅取消标识就结束。

不要默认第二天一定自动恢复。门店若启用了按日计划量或其他自动恢复规则，应让负责人了解生效时点，并在开门前核对备料。具体是否支持这些能力，需要让服务方按实际版本演示，不能仅凭功能名称判断。

这套流程适合现做餐厅、茶饮和每日限量供应的门店。选系统时可拿一条“售罄—顾客端检查—补货恢复”的完整过程试用，比单独询问有没有沽清按钮更容易发现交接遗漏。

常见问题

已经在顾客购物车里的菜会怎样？

不同系统可能在展示、加购或提交环节检查，不能一概而论。选型时把已有购物车也纳入测试；营业中发现异常订单，及时沟通，不自行假定顾客已收到提示。

只办收款码就能实现菜品售罄联动吗？

不能默认具备。收款工具与点餐菜单管理属于不同需求，应另外核对软件模块、渠道对接、权限和费用。