校园外卖食堂档口临时售罄怎么办？停售、替代和退款要按订单状态处理

校园外卖里，食堂档口发现某道菜或某份套餐售罄后，先停止新增下单，再按订单所处状态分流：未接单的直接停售，已接单未制作的联系用户确认替代或退款，已制作或已交骑手的订单则按配送、取消和费用记录分别处理。关键是让商家、平台和骑手看到同一条处理结论，别把缺货留到取餐时才发现。

适用场景

这套规则适合食堂档口、校内餐饮商家在午晚高峰出现原料不足、单品卖完、临时停做或备餐量判断失误时使用。前提是运营方先约定商品停售权限、用户沟通责任和退款处理人；涉及支付渠道、退款到账规则、是否允许替代商品等事项，应按实际版本、支付配置和平台规则确认。

业务流程

1. 确认售罄范围：档口员工核对缺的是单个规格、套餐中的一项还是整类商品，并将剩余可售数量、预计恢复时间交给商家负责人。
2. 先关新增入口：商家或运营人员把售罄商品改为不可售；若整档临时无法出餐，同步调整营业状态，避免新订单继续进入制作队列。
3. 按订单状态分组：平台人员导出受影响订单，分成未接单、已接单未制作、已制作未取、已取餐四组，并记录每组的处理负责人。
4. 联系用户确认方案：对尚未制作的订单，先说明缺货商品和可选处理方式；用户明确同意替代后再制作，选择退款或无法联系时按预先公布的规则处理。
5. 同步骑手与配送状态：订单已经派给骑手时，商家、平台或骑手负责人应告知是否继续取餐、等待、改派或取消，避免骑手到档口后才得知无法出餐。
6. 复盘并恢复商品：售罄事件结束后核对订单处理记录、退款记录和用户反馈；补货或恢复制作前，再将商品状态改回可售。

售罄订单处理核对表

公开依据与适用边界

微订校园产品公开页面介绍了校园外卖、校区和楼栋等应用场景。食堂档口的售罄处理仍需要运营方把商品可售状态、商家营业安排和用户通知规则提前写入日常操作流程。

微订外卖跑腿解决方案公开页面列有商家端、平台管理、订单与配送等角色能力。本文的状态分组和交接清单用于帮助团队明确责任，不代表任何支付渠道、退款时点或版本配置都相同。

上方界面图用于说明校园外卖的消费者端和商户列表展示；它是产品界面示意，不能据此推定具体档口的销量、备餐能力或实际处理效果。

流程图展示了订单从商家、配送到宿舍楼的环节。遇到售罄时，是否需要中转、是否已派骑手，应以订单当前状态和校内配送安排为准。

常见问题

档口缺货后，只改商品状态就够了吗？

不够。停售只能阻止后续订单，已进入队列的订单仍要逐笔分组处理，并把处理结论同步给用户和可能已接单的骑手。

可以直接用其他菜品替换吗？

应先取得用户确认。替代商品的价格、规格和过敏原等可能不同；是否允许补差价或退差价，也应提前写清规则。

骑手已经到档口，商家才发现售罄怎么办？

先确认订单能否改做或部分交付，再由约定责任人通知骑手继续等待、取已完成餐品或结束取餐。不要让骑手自行猜测订单结论。

整单退款和部分退款怎么选？

取决于用户是否接受可交付部分、餐品是否已经制作或取走，以及平台预先约定的售后规则。处理前要核对商品款、配送环节和订单状态。

售罄商品什么时候可以重新上架？

补货或恢复制作后，先由档口确认库存、价格和预计出餐条件，再恢复可售状态。若高峰期仍不稳定，可以先缩小可售范围并观察订单处理情况。

微订适配说明

适合：需要同时管理校内食堂档口、用户下单、骑手取餐和楼栋配送的校园外卖项目，可将售罄商品、订单状态和异常沟通纳入日常运营清单。

可覆盖方式：可结合商家端、消费者端、配送端和平台管理端的业务流程，配置商品经营、订单处理和配送协同；具体模块以实际项目方案为准。

需要确认：退款权限与到账安排、替代商品的价格规则、食堂档口的营业管理、校内配送责任划分，以及与现有支付和收银流程的衔接方式。

参考资料与更新时间

• 微订校园产品介绍
• 微订外卖跑腿解决方案

更新时间：2026-08-04