案例
外卖 · 站点
外卖站点管理小程序案例：骑手排班与异常单处理｜互联商通
直接回答：互联商通为华东一个外卖站点落地站点管理小程序，用「排班 → 异常单状态 → 对账导出」三件事替代表格排班与群里吼单，四周内灰度跑通。试点期异常单可督办、月底对账可导出，验收标准从「上线了」改为「异常单闭环率与对账时效达线」。
4 周从开工到灰度跑通全流程
可督办异常单处理状态（试点口径）
3 件事排班、异常单、对账导出
导出化月度对账，一键出表
一、客户背景与痛点
这个外卖站点配送几十名骑手，站长日常靠 Excel 排班、微信群处理异常单。
四个最疼的问题：
- 排班靠表格：班表改一次发一次，谁看的是哪版说不清。
- 异常单靠群吼：餐损、超时、联系不上顾客全在群里刷屏，处理无闭环。
- 对账月底痛苦：补贴、扣罚、异常单赔偿逐笔人工核，月底熬夜出表。
- 责任难划分：异常单谁跟进、到哪一步，事后查无实据。
二、方案总览：3 件事把站点管理搬进小程序
首版克制，不做调度算法，只把「表格 + 群」变成「排班 + 状态 + 导出」。
- 排班上线：班表在小程序内维护，改动即时生效，骑手各看各的班。
- 异常单状态流转：异常单登记、指派、处理、关闭全程有状态，可督办。
- 对账导出：按月导出异常单与扣补明细，财务与站长用同一张表。
- 权限最小化：骑手只见自己的班与单，站长看全站，账号不共用。
完整能力清单见 外卖站点解决方案。
三、核心功能清单
- 班表管理：排班改动即时生效，告别群里发图对版本。
- 异常单流转：登记、指派、处理、关闭四态可督办。
- 对账导出：月度明细一键导出，财务站长同口径。
- 角色权限：骑手、站长、财务各看各的，账号不共用。
- 处理留痕：异常单谁跟进、怎么结的，事后可查。
四、落地实施过程
总览里的三件事讲的是方案逻辑，这一节讲它怎么落到站点里：四周完成灰度，拆成下面五个动作，前一步跑顺再进下一步。
- 进场前准备：班表与规则入库。开工先把现役骑手名单、班次与扣补规则逐项录入校对，异常单分类与处理时限先定义清楚，规则没定稿的先不放开给骑手。站长看到的是班表与规则一页页对完；骑手此时还看不到变化，但上线那一刻数据已经是完整的。
- 异常单流转对接：登记到关闭先跑通。上线前打通异常单全链路——群里吼的每类异常都有入口，登记后自动指派，处理结果留痕可查。责任不再靠口头对质，按单号就能查到谁跟进、怎么结的；站长感知是群里吼单少了，督办有了抓手。
- 员工培训：一条主线加两套权限。骑手培训只强调一条：异常先登记再处理。站长学会班表维护、异常指派与月度导出；骑手端权限刻意最小化——只看自己的班与单，不碰对账数据。
- 灰度试点：一班骑手先跑，改完再全站。全量放开前先拿一个班次试跑，站长跟着盯：班表对不对、异常单登记顺不顺、导出数据准不准。试出来的问题当场改——分类补全、规则调整，再全站铺开；试点期不做数字考核，只看流程顺不顺、问题清单收不收敛。
- 值班与应急：首月月底驻场。上线后首个月底对账驻场，值班覆盖导出差异、权限申请、异常申诉三类突发。导出数据与财务对不上当场核；骑手不会用，站长代为登记兜底，表格与小程序并行过渡不强制。试点暴露的问题全部进了第七节的复盘清单。
五、明确没做的事（对比与取舍）
首版不做智能调度、不接平台深接口。先保证排班、异常单、对账三件事可验；调度算法依赖数据积累，等异常单数据沉淀后再二期评估，平台对接先走窄接口。
六、上线后效果（试点数据口径）
试点期内：
- 异常单可督办，处理闭环有状态可查。
- 月度对账可导出，出表时间明显缩短。
- 站长验收只看「异常闭环与对账时效」，而不是打开次数。
所有数字为项目试点口径，复制前请重估站点规模与扣补规则；数据对比写清分子分母与排除周。
七、坑与复盘
- 账号共用：初期多骑手共用一个账号，班次与异常记录串人；改成一车一号、权限最小化后数据才可信。
- 定位说明缺失：骑手端定位权限用途没写清，审核被拒；补齐定位说明与隐私指引后过审，见 定位说明。
- 扣补规则没前置：扣罚规则没定稿就上线，骑手逐单来问；规则先成文再放开，申诉才有序。
复盘沉淀为方法论：把可勾选验收句写进开工单，避免「上线了」代替「指标达线了」；数据导出合规口径从第一天就定，见 数据导出合规。
八、常见问题 FAQ
能对接外卖平台系统吗？
可窄接口：首版只同步必要的异常单信息，不做深对接；等流程跑稳再评估平台侧接口范围。
多个站点一起上吗？
先单站：先把一个站点的班表、异常单与对账跑通，再复制到其他站点，站点间数据隔离。
骑手端给哪些权限？
权限最小化：骑手只看自己的班表与自己相关的异常单，不开放对账与全站数据。
