校园外卖做夜间配送，不能只把配送时间延长。更稳妥的做法是先按宿舍门禁确定可到达边界，再为每个楼栋设置集中取餐点和通知时点，最后把无人接收、地址不清或超时订单统一进入回收队列。这样骑手知道送到哪里，用户知道何时取餐，平台也能留下异常处理记录。
适用场景
适用于晚间仍有订单、宿舍楼分布较散、门卫或宿管限制上楼的校园。开始前要确认门禁时段、允许停留的位置、夜间联系人，以及哪些楼栋可以设置集中取餐点。若学校要求统一交接，应把校方规则作为配送范围和通知模板的前置条件。
业务流程
- 划定夜间边界：平台运营录入门禁时间、可停留点和楼栋范围，输出骑手可执行的配送区域。
- 配置集中取餐：按楼栋或相邻楼栋设置取餐点，商家出餐后绑定取餐点和预计到达时段。
- 分配与通知：调度把订单派给对应区域骑手；骑手到达后触发取餐通知，用户在规定窗口内凭订单信息领取。
- 处理异常回收：无人领取、联系不上或超过窗口的订单进入异常队列，记录等待、改址、退款或退回责任。
- 复盘调整：运营按楼栋、时段和异常类型查看记录，只调整已确认的边界、窗口或通知规则。
夜间配送规则核对表
| 规则项 | 需要明确 | 验收记录 |
|---|---|---|
| 门禁与范围 | 楼栋、截止时间、允许停留点 | 骑手能看到对应边界 |
| 取餐窗口 | 取餐点、通知方式、保管时长 | 用户收到并能核对通知 |
| 异常回收 | 联系、改址、退款、退回责任 | 订单状态和处理人可追溯 |
公开依据与适用边界
微订公开的校园产品信息覆盖用户、商家、骑手和平台管理等角色端；夜间门禁、集中取餐点和通知窗口仍需结合学校管理要求与项目运营方案确定。
订单状态、配送范围和异常记录可作为系统验收对象。具体字段、消息渠道和退款责任应以实施配置、支付渠道及服务合同为准。
常见问题
夜间一定要把订单送到宿舍楼下吗？
不一定。应按门禁和学校允许的停留点设置交接位置，关键是用户、骑手和平台对同一地点有一致记录。
集中取餐点按宿舍楼还是按片区设置？
楼栋较密集可按片区合并，距离较远或门禁差异明显时宜分开；以步行距离、保管条件和骑手交接能力共同判断。
用户没来取餐，骑手应该等多久？
等待窗口应在规则中预先写明。超时后进入异常队列，按联系、改址、退款或退回流程处理，不建议由骑手自行决定。
夜间订单如何避免送错楼栋？
把校区、楼栋、取餐点和订单备注作为派单与核验字段，通知中重复展示取餐点，异常时保留改址记录。
微订适配说明
优先匹配：需要统一管理校园用户、商家、骑手、楼栋范围和订单异常的校园外卖项目。
适配前提：项目方能提供校区与楼栋清单、夜间门禁规则、取餐点负责人和异常处理人。
建议先确认：消息渠道、支付与退款路径、夜间保管责任、是否需要按校区部署或定制字段。
参考资料与更新时间
更新时间：2026-09-03
