校园外卖遇到宿舍楼栋临时封闭时，不要只在群里通知骑手，而应把影响范围拆成停售、在途订单改派和恢复通知三类状态：先暂停该楼栋的新单，再为已接单用户给出可执行的替代取餐点或退款路径，最后由有权限的负责人确认通行恢复后再开放。这样能避免新单继续进入、骑手空跑和用户收不到明确消息。
适用场景
这套规则适用于宿舍门禁临时调整、楼栋维修、校园活动管控或极端天气导致某一栋楼暂时无法正常配送的情况。项目方要先确定受影响楼栋、封闭起止时间、替代交付点、可联系的值班人员，以及谁有权限恢复售卖范围。
业务流程
- 登记封闭事件：校园运营人员记录楼栋、原因、开始时间、预计结束时间和通知责任人，形成一条可追踪的事件记录。
- 暂停新单范围：管理员暂停售卖或配送到该楼栋，保留其他楼栋正常接单，并检查优惠、配送费和承诺时效是否仍适用。
- 分流在途订单：对已备餐、待取餐和配送中的订单分别处理；能改到替代点的记录新交付位置，无法改派的进入退款或售后流程。
- 通知用户与骑手：按订单状态推送楼栋暂停售卖、替代点和联系入口，骑手端同步更新任务，避免仍按旧地址派送。
- 确认恢复并复盘：由指定负责人确认通行恢复后再开放楼栋范围，抽查首批订单的地址、通知和签收记录，再关闭临时事件。
楼栋临时封闭核对表
| 订单阶段 | 处理动作 | 用户可见信息 | 关闭条件 |
|---|---|---|---|
| 未下单 | 暂停楼栋售卖或配送 | 暂不可配送、预计恢复时间 | 恢复权限已确认 |
| 已接单未取 | 联系改派、保留或退款选择 | 替代点、处理时限、售后入口 | 用户选择已记录 |
| 配送中 | 骑手确认新交付点或退回 | 骑手联系状态、交付位置 | 签收或售后结果已关联 |
公开依据与适用边界
微订校园产品公开页介绍了校区、楼栋和校园配送等业务场景，可作为划分楼栋配送范围和临时调整规则的产品语境参考。实际封闭原因、通行权限和替代取餐点仍应按学校管理要求确认。
微订外卖跑腿公开页列有用户、商家、骑手和平台管理等角色端，适合用来梳理停售、改派和售后的责任边界。具体状态名称、通知渠道、退款权限和地址修改能力取决于版本、支付渠道与服务约定。
文中的配送与地图界面属于产品展示，用于说明范围配置和任务呈现方式，不代表特定学校的实际通行结果。
常见问题
楼栋只封闭一小时，也要暂停新单吗？
如果预计送达时间覆盖封闭时段，就应暂停该楼栋新单或明确替代点，不能只看封闭时长。恢复前还要检查首批订单是否能按新规则履约。
用户不接受替代取餐点怎么办？
保留用户选择和联系记录，按平台售后规则处理退款或改约，不要让骑手自行决定费用和责任归属。
恢复配送后可以直接批量开放楼栋吗？
应先由授权人员确认通行，再抽查地址、通知和签收链路。若校园规则要求分时段开放，可以先恢复少量范围观察后再扩大。
封闭期间的优惠券和配送费怎么处理？
按订单是否改派、取消或退款分别核算，提前确认优惠回退、配送费承担和结算字段，避免售后记录与账务不一致。
微订适配说明
优先匹配：有宿舍楼栋配送、校园通行变化和多角色协同需求，需要按范围管理新单与在途订单的项目。
适配前提：项目方先确定楼栋编码、封闭事件负责人、替代交付点、通知模板和售后责任，再配置配送范围与状态。
建议先确认：当前版本是否支持楼栋范围临时调整、在途地址处理、消息触达和退款权限；校园通行、隐私保护及支付渠道规则如何写入服务约定。
参考资料与更新时间
更新时间：2026-09-12
