已有骑手团队搭建校园外卖平台：准备清单与订单状态机验收

已有骑手团队时，准备顺序可以概括为：先取得校方准入并明确经营主体、保险与合作协议，再把配送拆成可定责的节点，最后按阶段选择系统。系统路线通常从试运营SaaS开始，订单稳定后再评估私有化或源码，确有特殊流程再谈定制。验收时不要只看功能表，用一笔真实订单走完商家出餐、校外运输、校门核单、楼栋分拣、校内接力、送达通知和退款对账，并加入五类异常单。

一、先准备什么：校方准入、主体、保险和协议

已有骑手不等于可以直接开跑。校方准入和主体责任没落纸，系统上线后也可能因通行、食品安全或责任边界被叫停。建议先向后勤、保卫、学工或宿管部门书面确认能否入校、校门交接点、配送时段和禁送要求，再按撮合平台或自营餐品核对主体与商家资质。

若平台只撮合商家，商家通常需具备相应资质并由平台审核留存；若自营餐品，运营方需按当地监管办理。具体许可范围、平台责任和校方条件应向当地市监与学校确认，系统能力不能替代这些前置事项。

二、把配送拆成状态机，已有骑手才有可管理性

已有骑手团队的优势是熟悉路线和班次，缺的是统一状态与交接凭证。建议把主链路定义为：商家出餐→校外运输→校门核单→楼栋分拣→校内接力→送达通知→退款对账。每个节点记录操作人、时间、订单状态、实物数量、通知结果和金额变化。下面是一个设计示例，用于说明数据结构，不代表任何产品内部实现。

订单状态：
CREATED -> PAID -> MERCHANT_ACCEPTED -> PICKED_UP -> GATE_RECEIVED
-> SORTED_BY_BUILDING -> CAMPUS_DELIVERING -> DELIVERED -> SETTLED

异常事件：
SHORT_ITEM（少餐） -> GATE_REVIEW
WRONG_ITEM（错餐） -> RESORT
DUPLICATE_SCAN（重复扫码） -> REJECT_DUPLICATE
ADDRESS_CHANGED（改址） -> RESORT_OR_REASSIGN
PARTIAL_DONE（部分完成） -> PARTIAL_DELIVERED
REFUND_AFTER_SETTLE（结算后退款） -> LEDGER_REVERSAL

约束：
1. 每个状态记录 operator、timestamp、order_id、physical_count、notify_result
2. 跳状态或回退状态必须人工复核并留下原因
3. 退款、补送、丢餐赔付要关联原订单和责任人

状态机的价值是把“谁在什么时候接手、异常单卡在哪、退款是否已冲回”变成可查记录。排班、取餐核单、改址转单、丢餐赔付和高峰加人规则应与状态字段一致；如果后台规则与骑手协议不一致，结算和售后就容易扯皮。

三、系统路线怎么选：按阶段，不按功能表长短

选择依据不是功能表谁更长，而是校区数量、单量、技术团队、数据要求和特殊流程。单校或2—3个校区、无专职技术团队时，先用标准SaaS跑通下单、支付、商家接单、骑手配送、退款和对账，风险更可控；订单稳定、需要自有环境时再评估私有化；有技术团队且计划长期维护时再考虑源码；多校区深度对接且标准功能不足时再谈定制。

询价时把软件模块、终端入口、校区数、部署环境、培训、维护、第三方服务（支付、短信、云资源）和定制范围拆开，分别列一次性费用与续费。历史成交价只能作背景，不能当作统一报价；当前报价应以配置清单和需求确认书为准。

四、用一笔订单验收：正常流程和五类异常

验收时用本校真实地址建校区和楼栋，安排一笔订单从商家出餐走到退款对账。正常单跑通后，再加入少餐、错餐、重复扫码、改址和部分完成五类异常；如果涉及结算后退款，还要加一笔退款冲回。

1. 建真实校区、楼栋、取餐点和校门交接点，确认地址选项与实际路线一致。
2. 走正常单：下单、支付、商家接单出餐、校外运输、校门核单、楼栋分拣、校内接力、送达通知、对账。
3. 加入五类异常：少餐、错餐、重复扫码、改址、部分完成，观察订单状态与实物数量是否一致。
4. 记录每个节点的操作人、时间、订单状态、实物数量、通知结果和金额变化。
5. 要求服务商标明哪些是标准配置、哪些需要接口或定制，并核对校方通行、站点空间、设备和人员权限。

通过标准是记录一致、责任可追溯、异常有闭环，而不是页面功能多。验收后的复盘要回到经营判断：哪些节点需要加人，哪些地址需要调整，哪些异常会推高退款和客服成本。

五、预算、结算与上线顺序：哪些写进合同

预算至少拆成软件套餐、增值模块、部署环境、第三方服务、定制开发、培训和持续维护，并区分一次性费用与续费。骑手结算先写规则再上系统：基础单价、远距离或超重加价、高峰期补贴、差评与超时扣罚、丢餐赔付、结算周期，都要在骑手协议和后台配置中一致。演示时看骑手接单、转单、送达、收益查看，以及平台对账、退款冲回和提现状态。支付通道、分账开通、账期和手续费写入合同；已有骑手团队尤其要核对临时转派和异常订单是否影响结算。

上线顺序建议为：校方书面确认→主体、保险、协议与商家资质审核流程→SaaS试跑→商家入驻和菜单配置→骑手培训→一笔订单加五类异常→小范围试运营→复盘扩校。校方政策变动、订单波动、食品安全、骑手事故和资金隔离属于经营风险，应各自设置负责人和核对项。寒暑假订单下降时，跑腿、代取快递等业务是否承接，要提前评估；商家货款、骑手佣金按时结算，避免混用。

常见问题

没有食品经营许可证能不能做校园外卖平台？

若平台撮合商家，商家通常需具备相应资质并由平台审核留存；若自营餐品，运营方需按当地监管办理。平台责任与许可范围应向当地市监和校方确认，系统能力不能替代许可。

已有骑手，是否必须买保险？

应把骑手意外险、第三者责任和协议责任写清。具体险种、承保范围和费用向保险机构确认，并把保单与骑手协议对应起来。

校园外卖系统一年多少钱？

按模块、终端、校区数、部署、定制、培训、维护和第三方服务分项询价，分别列一次性费用与续费。历史成交价只作配置背景，当前报价以需求和当次方案为准。

已有骑手先做直送还是中转分拣？

由校门通行、站点空间、单量、分拣人力和异常处理能力决定。先用一笔订单和五类异常压测，再判断是否增加中转点、分拣员和校内接力骑手。

下一步，把校门规定、楼栋布局、高峰单量、异常订单和结算样例整理成一页需求，要求服务商按正常单、少餐、错餐、重复扫码、改址、部分完成和退款做一次完整演示，并把确认结果写入交付清单与合同。