校园外卖订餐小程序上线流程：准入约束、四端配置与异常单验收

自己做校园外卖订餐小程序，合理顺序是：先向学校确认校外餐能否入校、校门交接点、送达边界、配送时段和进校人员，再确定经营主体与支付结算负责人；随后按依赖关系完成小程序账号、认证、备案、服务类目和同主体收款配置；再配置校区、楼栋、商家、菜单、骑手与权限；用一笔正常单加缺货、退款、错楼栋、无人接单等异常单做验收，问题闭环后提交审核；审核通过先选一至两栋楼试运营，稳定后再扩商家和校区。

这条顺序中，校方准入和主体条件决定项目能否成立，系统配置和异常验收决定上线后能否接续处理问题。下面按业务约束、技术配置、验收方法和试运营展开。

一、先把校方准入转成可配置约束

第一步不是写代码，而是向学校后勤、保卫和场地管理方书面确认：校外餐能否入校、校门交接点设在哪里、送到楼下还是固定点位或寝室、允许的配送时段、哪些人员可以进校。同步明确经营主体、商家资质、支付与结算负责人。校方答复未明确前，先不投入不可逆的开发或采购。

把口头答复整理成配置字段，后续演示和验收才有对照物。地址层级建议统一为：学校、校区、校门或站点、楼栋或取餐点、服务时段、送达方式、收费规则。名称一旦确定，用户端选址、后台分拣和骑手交接都使用同一套叫法，减少错楼栋。

二、主体、认证、备案、类目与支付按依赖排序

账号与资金环节不要凭宣传文章排固定天数，按依赖关系推进，并以微信开放文档《小程序备案操作指引》《微信小程序认证指引》和主管部门现行页面核对要求。常见顺序是：确定经营主体，注册并认证小程序，按现行要求完成备案和选择与实际经营匹配的服务类目，保存AppID交给系统方绑定；再用营业执照和法人信息开立与经营主体一致的收款商户号；最后配置退款、结算、提现和对账责任人。

平台类外卖交易涉及商家货款、配送费和平台服务费时，应把分账、退款冲回、账期、提现和手续费写入项目约定，逐笔核对平台、商家、骑手三类账。系统能记录账务，不等于自动满足支付机构或监管要求，具体通道和开通条件按现行规则确认。

三、后台配置先定地址结构和订单状态

后台配置不要从页面装修开始，而要先定角色、地址和订单状态。用户端负责浏览、选址、下单和售后；商家端负责接单、出餐、缺货处理；骑手端负责取餐、交接、配送和送达；平台端负责商家、骑手、订单、退款、结算和权限。四端围绕同一笔订单协同，任何一端的状态定义不清，都会在现场交接时放大。

订单状态建议先画成可验收的状态表：待支付、已支付、商家已接单、已到校门、已分拣、配送中、已送达、已结算。每进入一个状态，写清触发动作、前置条件、责任人和异常分支。缺货、拒单、退款、错楼栋、无人接单、重复扫码都应有单独的处理路径，不能只验正常单。

下面用一段伪代码说明扫码交接的幂等验收思路。它是验收设计示例，不代表任何产品内部实现，也没有运行实测结论。

scanHandover(orderNo, scanId):
    if scanId in processed:
        return processed[scanId]
    processed[scanId] = 'PROCESSING'
    order = loadOrder(orderNo)
    if order.status != 'ARRIVED_CAMPUS_GATE':
        return 'STATUS_CONFLICT_MANUAL_CHECK'
    order.status = 'SORTED'
    saveOrder(order)
    processed[scanId] = 'SORTED'
    return 'SORTED'

预期结果是：同一扫码请求重复提交时返回原结果，不重复改状态或重复通知；状态不匹配时转人工核单。实际验收要在选定系统和测试数据上执行，保存环境、版本、输入、操作人、输出和处理时长，不能把设计示例当成现有系统的实测结论。

四、用正常单加异常单验收，再提审发布

上线前至少安排一笔正常单和一组异常单，由用户、商家、骑手、分拣员和平台管理员同时参与。每类场景都记录订单号、操作人、输入地址、系统状态、金额变化、处理结果和遗留问题。异常单走不通，先调整配置或流程，再提交审核。

提审时，页面说明、服务类目、功能描述、配送范围和履约方式要与实际一致，并设置商家资质公示和售后入口。审核关注的是页面承诺与实际功能是否匹配，系统配置完成不代表审核自动通过，应以平台现行审核意见为准。

五、试运营与扩量：先一至两栋楼，再复制校区

审核通过后先选一至两栋楼或一个片区试运营，不要直接全校推广。试运营要记录每波订单量、到站时间、分拣完成时间、未完成原因、退款处理时长、通知结果和客服问题。高峰时重点看订单能否按楼栋送完、异常单能否被下一班接续、含优惠订单能否对清平台、商家和骑手三类账。

稳定后再扩商家和楼栋。扩到第二校区时，先做配置差异表：哪些品牌页面和培训材料可复用，哪些商家、菜单、骑手、班次、楼栋地址、通行规则和结算归属要重新配置。新校区先用少量订单演练收餐、分拣、退款与汇总，确认数据归属和操作权限，再逐步放量。

常见问题

个人主体能不能做校园外卖平台？

先按微信和主管部门现行规则核对经营主体、服务类目与收款主体要求。不要把“能注册小程序”当成可以开展平台类外卖交易和支付的充分条件；经营主体、商户号、合同和结算责任应保持一致或能清楚说明关系。

上线一般要多久？

本次资料没有可公开核验的统一周期。实际进度受校方答复、认证备案、类目审核、商家资料、支付开通和测试问题影响，建议按里程碑管理，逐项记录完成标志，不承诺固定天数。

先用SaaS还是直接定制？

团队以运营为主、规则尚未稳定时，先用标准SaaS跑通下单、接单、配送、退款和对账；订单稳定、出现明确接口或特殊流程，再评估私有化、源码或定制。比较时把模块、终端、部署、第三方服务、培训和维护分项列清。

什么情况要重点演示校门中转和楼栋分拣？

校外配送人员通行受限、订单集中在午晚高峰、需要按校门收餐再分拣到楼栋时，应把校门交接、批量中转、部分送达、错楼栋改址和取餐通知放进同一场演示。演示结论要绑定版本、地址和操作人。

下一步，把校方书面答复、楼栋清单、商家菜单、骑手班次和异常单样例整理成一页需求，在演示环境走一笔正常单，再加入缺货、退款、错楼栋和无人接单，记录版本、输入、输出与处理人，再据此决定采购或开发范围。