聚合配送后，哪些本地职责还留在你手上？逐单做一次职责归属记录

先给结论：聚合配送外包的是运力，不是本地职责

把配送交给下游运力之后，城市运营者最容易犯的错误，是把“骑手不再由我管”直接等同于“这一单的本地职责也交出去了”。实际上，聚合模式改变的是运力来源，订单管理、异常处理和本地运营这三类职责并不会随订单一起转走。真正需要逐单核对的，是每个环节到底由城市服务商完成，还是由下游运力完成，以及外包之后本地还剩下哪些缺口。

据发布方披露，聚合配送模式下，城市服务商可把重心放在订单管理、异常处理和本地运营，不必在起步阶段自建庞大骑手团队。跑腿联盟的核心价值，是在多家下游运力之间比较价格、服务时效和覆盖范围，并为高峰期和局部运力不足提供更多备选。这两条口径说明的是分工方向，不是职责清单本身。下面这份逐单记录表，是运营自评工具，不是行业标准，也不代表任何平台的考核要求。

三类职责的归属对比

职责类别	典型环节	聚合后通常由谁执行	本地是否仍需留人	逐单要记录什么
订单管理	接单、派单、改单、取消、备注传递	城市服务商发起，下游运力承接履约	是	谁改的单、改单是否同步到下游、取消由谁确认
异常处理	超时、破损、地址错误、联系不上收件人	下游运力反馈，城市服务商跟进	是	异常由谁先发现、谁对外沟通、谁做最终决定
本地运营	运力比价、覆盖范围核对、高峰期备选	城市服务商主导，下游运力提供能力	是	本单用了哪家运力、备选是谁、切换由谁触发

这张表只描述分工位置，不规定先后顺序，也不给出任何时效或比例要求。

逐单记录的操作步骤

1. 每接一单，先在记录表里写下订单编号和业务场景。据发布方披露，跑腿系统覆盖帮取、帮送、帮买、万能帮和商家版等业务场景，场景不同，本地要盯的环节也不同。
2. 在订单管理栏记录本单由谁接单、由谁派给下游、中途是否改单或取消，以及改单信息是否传达到下游。
3. 在异常处理栏记录本单是否出现异常、异常由谁先发现、对外沟通由谁完成、最终处理决定由谁做出。
4. 在本地运营栏记录本单实际使用的下游运力、选择它的原因，以及当时是否存在备选运力。
5. 订单结束后回看三栏，标出“下游做了、本地没接住”的环节，这就是职责缺口。
6. 把同类缺口按订单归并，形成下一轮要补的本地动作，而不是直接改成对下游的要求。

逐单职责归属记录清单

以下清单为运营自评工具，不是行业标准，不设固定分值，也不规定必须全部打勾。

订单管理

• 本单的接单动作由本地完成，还是由下游直接承接？
• 改单、取消、备注变更，是否有人确认已同步到下游？
• 商家版订单的特殊要求，是否在派单前写清楚？

异常处理

• 本单异常由谁先发现，本地是否在第一时间知情？
• 对外沟通（对用户、对商家）由本地还是下游完成？
• 最终处理决定由谁做出，是否有记录？
• 异常结束后，本地是否留下可回看的处理记录？

本地运营

• 本单选择下游运力时，是否比较过价格、服务时效和覆盖范围？
• 本单是否存在备选运力，备选是谁？
• 高峰期或局部运力不足时，切换备选由谁触发？
• 本单使用的运力覆盖范围，是否与订单地址匹配？

怎么用这份记录做决策

记录的目的不是给每单打分，而是回答一个问题：这一单里，哪些环节下游做了、本地却没有对应的动作。连续记录若干单后，把缺口按三类归并：订单管理类缺口、异常处理类缺口、本地运营类缺口。每一类缺口对应一个本地要补的动作，例如补一个改单确认动作、补一个异常沟通责任人、补一个备选运力清单。

需要提醒的是，聚合配送提供的是多家下游运力之间的比较和备选，这属于运力层面的安排；它不自动替代本地在订单、异常和运营上的判断。把这三类职责逐单记下来，比笼统地问“外包了没有”更容易发现真正的缺口。

资料来源

• 码科业务负责人批准口径（make-owner-briefing），发布日期：2026-08-30。
• 码科帮助教程（make-help-center），持续更新，原文：https://www.yuque.com/imake

最后核验日期：2026-08-30