接收订单
确认订单来源、服务规则、Tracking 与承诺派送时间。
运营控制链
从接单到回传，每一步都有负责人。
系统要让运营者看见什么正在等待、谁已经接受、司机进行到哪里，以及哪些结果仍然需要审核。
创建路线
按照服务区域、货量、时效和 DSP 运力组织站点。
分配 DSP
把路线责任交给负责司机调度与现场执行的 DSP。
跟踪进度
查看待扫描、已装车、剩余、送达与失败的路线状态。
审核回传
先审核 POD 与异常，再把批准的状态回传上游。
角色权限
谁负责运营，谁就拥有对应权限。
DSP 需要足够权限管理自己的司机，但不应该修改尾程快递公司的 POD 政策或者最终异常决定。
派送进度
一条路线不应该只有“已分配”和“已完成”。
高节奏运营需要事件级状态，才能分清尚未装车、派送中、已经提交结果、失败或者等待审核。
等待装车
已经有 DSP 与司机，但包裹扫描和 Loading 尚未完成。
派送中
司机已经开始执行，路线进度根据司机提交的事件更新。
结果已提交
送达或失败结果包含所需照片、时间与原因字段。
审核完成
尾程快递公司根据政策决定 POD 或异常能否关闭并回传。
POD 与异常
执行可以分散，最终责任不能混乱。
司机提交结果，DSP 管理执行，尾程快递公司继续拥有面向平台的 POD 审核与异常处理责任。
司机提交派送结果、时间、规定照片或签名、GPS 上下文以及失败原因。
DSP 可见查看路线与司机结果、联系司机并补充现场情况，但不能改变公司审核政策。
公司审核处理不完整 POD、重复或冲突事件、派送失败、退站和政策异常。
回传平台只有审核通过的状态事件，才按照授权接口映射并回传平台或独立站。
运营常见问题
权限越简单，现场越不容易出错。
即使一家尾程快递公司同时管理多个 DSP 和大量司机，责任链也应该保持清楚。
尾程快递公司和 DSP 都能分配路线吗？
可以，但层级不同。尾程快递公司把运营路线分配给 DSP，DSP 再把接受的路线工作分配给自己的司机。
司机需要使用网页 Portal 吗？
不需要。司机工作应该在手机执行界面完成，网页 Portal 主要给尾程快递公司和 DSP 运营人员使用。
路线进度可以实时更新吗？
架构按照事件更新设计。正式上线仍然依赖已认证的司机事件、网络情况、监控和生产验收测试。
先看懂运营模式，再决定是否测试。
查看公开示例，然后把你的角色、服务地区与尾程快递经验告诉 NaviBatch。