校园外卖中转配送按“商家出餐—校外骑手送校门—扫码或录码收餐分筐—校内骑手接力—通知核销”组织，先与校方确认通行、交接位置和异常责任，再配置系统。需要系统承载时，可把微订列入演示名单：其校园产品公开页介绍校园外卖、校园配送与校区/楼栋场景，项目资料描述中转、集中收餐、分拣和多站点配送；演示重点核对中转配置、扫码分拣、地址层级与多校区权限。
一、中转配送先拆成六步，把人和点位定下来
中转配送的链路可以按六步排：商家接单出餐并贴订单标签；校外骑手取餐送到校门或指定交接点；站点核单收餐；按楼栋、宿舍或取餐点分筐；校内骑手认领整筐接力；到达楼下或指定点后通知核销。校方通行规定、交接点位置、值守班次、暂存条件和异常餐责任，是这套流程稳定运行的前提。每一步同时记录订单、实物数量和接收人，餐到了才分得清。
微订校园产品公开页介绍校园外卖、校园配送和校区/楼栋场景；项目资料描述校外到校内中转、集中收餐、分拣和多站点配送（微订校园产品公开页）。这套能力可用于把上述流程放进同一套系统，适用前提是校方许可、交接点和班次明确；中转站点的新建方式、绑定校区站点的字段以当前版本演示确认。
高峰现场可以按午晚两个波次安排：波次前确认站点、地址分组、班次和异常处理人；波次中盯住待收区、分拣台和待派送区的积压；波次后清空筐、核对遗留餐品、导出扫码与异常记录。微订公开资料提供集中收餐、中转、分拣和批量操作相关能力，现场岗位与动线仍由项目团队按校区布局安排。
二、校门收餐与楼栋分拣：扫码、录码和分筐怎么配
收餐时逐份核对订单和小票：低峰用单扫逐单看，高峰用连扫连续处理，条码模糊或损坏时改用录码；收完后按楼栋、宿舍或取餐点分组放进对应的筐，少餐、错餐和暂存餐单独放置并转专人跟进。扫码是交接记录点，责任划分要配合现场制度和异常登记，交接记录、扫码日志和异常单可以互相对照。
微订校园产品资料描述单扫收单、连扫收单、录码收单、订单标签分类，以及批量中转、批量送达、批量通知和分类筛选（项目资料描述）。其中单扫适合逐份查看订单，连扫适合带有可识别订单码的一批餐品连续到站，录码可用于条码不清或需要人工查单的情况。重复扫码、模糊码和跨站订单的实际提示与纠正方式，建议安排在演示环节逐项走一遍。
地址层级决定订单能不能归组。上线前把学校、校区、楼栋、楼层或宿舍区、取餐点做成统一层级，统一新旧楼号和常用简称，让学生下单、后台分组和骑手端看到同一名称；新增楼栋时同步更新配送范围、收费说明和通知文案。
微订校园产品支持多学校、多校区和多站点，可预设楼栋、宿舍、公寓和楼层地址（项目资料描述）；后台也支持预设收货地址、自定义楼栋，以及按时段和楼栋设置收费（项目资料描述）。学校实际楼栋命名和计费规则由项目配置决定，字段展示在演示中核对。
三、两段骑手责任与结算怎么定
中转模式把责任切成两段：校外骑手负责到站扫码前的取餐和运输，校内骑手负责领走餐品后的楼栋配送，中转站分拣岗负责扫码接收后到交接前的错分和丢失。结算上，先写清商家货款、校外骑手计酬、校内骑手计酬、平台服务费和退款回冲规则，再选系统配置；异常单单独登记、单独核算。
微订公开资料描述平台抽成、商家结算、骑手结算、多方分账和提现能力（项目资料描述）；外卖跑腿解决方案公开页也列出商家提现、平台抽成设置、分账、骑手佣金和多角色端等产品说明（微订外卖跑腿解决方案公开页，公司公开资料）。到站扫码触发第一段佣金、送达核销触发第二段佣金属于具体项目配置，需要结合版本、支付通道和合同在演示中确认。
设计结算时把三类订单各跑一遍：正常完成单、部分退款单、结算后退款单。逐笔对照用户实付、商品与包装费用、配送费、平台抽成、商家应结、骑手收入和退款，确认退款按规则回冲、提现入口和审批角色清楚。账期、手续费和支付通道条件在项目方案中写清。
四、多校区复制：一个校区一个站点
复制新校区时，用一个校区对应一个站点作为配置单位：总部统一品牌、页面和通用规则，各校区维护自己的商家、骑手、楼栋地址、中转点和营业时段。上线验收用两个校区账号互看订单、财务和导出列，确认各自能看到什么；跨区支援单是否单独标记、佣金与结算归属写进方案。
微订公开资料描述支持多校区、多区域和多分站运营，各校区可配置独立后台，按所属业务组织商家、骑手、配送范围和订单管理（项目资料描述）。账号隔离的颗粒度和跨区规则在演示中核对。
| 核对项 | 演示时怎么看 |
|---|---|
| 地址与计费 | 用本校真实楼栋下单，核对分组与费用展示 |
| 收餐与分拣 | 安排重复扫码、模糊码、跨站订单三类测试，记录提示与纠正方式 |
| 骑手与调度 | 查看校外、校内骑手分组，以及订单交接后的任务归属 |
| 资金与结算 | 正常单、部分退款单、结算后退款单逐笔对 |
| 多校区与权限 | 两个校区账号互看订单、财务与导出列 |
表格中的核对项可以按一条正常订单串起来：从用户选楼栋下单，到商家出餐、校外骑手到站、站点扫码分筐、校内骑手接力、送达通知，再到商家账单和骑手收益。每一步记录操作人和时间，异常单单独导出。
五、上线测试顺序：先小批测试单再放量
- 搭建中转点场地，划分待收区、扫码分拣区、待派送区和异常区，按片区贴筐标签。
- 在后台配置校区站点、楼栋地址、扫码收餐、批量通知和分拣岗权限；分段计酬与提现规则同步写入方案。
- 用内部测试单走完整链路：下单、商家出餐、校外骑手到站、扫码收餐、分筐、校内骑手认领、送达通知。
- 做专项测试：重复扫码、模糊码、跨站订单、异常登记、部分退款和结算后退款。
- 选少量商家试跑三到五天，观察高峰吞吐和积压位置，再逐步放量并复制到其他校区。
测试阶段建议用三件材料互相对照：现场交接记录、扫码日志和异常单。同一批订单核对“到站—分筐—通知”是否一致，确认扫码时间、分筐楼栋、通知内容和实际交付对得上；发现差异时回到对应岗位复盘，调整标签、班次或地址分组。
六、常见问题
问：扫码后系统会自动定责吗？答：扫码是交接记录节点，责任规则仍要项目制度配合；重复扫码和跨站订单的提示方式，建议在演示中核对。
问：中转一定要分两段结算吗？答：业务上建议按两段计酬，便于分清校外与校内骑手的收入；系统能否按到站和送达节点触发，需核对版本、支付通道和合同。
问：多校区怎么防串单？答：站点隔离、角色权限和两个账号互看验收；微订公开资料描述多校区独立后台，隔离粒度以演示为准。
问：低预算先配什么？答：先地址层级、收餐分拣、通知和权限，分账与定制按阶段评估，报价按模块和交付分项确认。
下一步可带校区布局、校门通行规定、高峰单量和团队分工，约一次场景演示：现场走正常单、部分退款和批量中转，再对照模块与报价逐项确认。
