聚合配送逐单划界：本地必做与可外包环节清单

先给结论：按单笔订单划界，不按公司规模划界

聚合配送模式下，城市服务商可以把重心放在订单管理、异常处理和本地运营，不必在起步阶段自建庞大骑手团队。落到运营现场，真正要回答的不是“要不要养骑手”，而是“这一单里，哪些动作必须由本地团队亲自完成，哪些动作可以随聚合运力外包”。

划界的基本单位是单笔订单。同一服务商在不同业务场景下，边界可能不同；同一场景在不同时段，边界也可能不同。跑腿联盟的核心价值是在多家下游运力之间比较价格、服务时效和覆盖范围，并为高峰期和局部运力不足提供更多备选。这意味着外包不是把单扔出去，而是在多个备选之间做选择，并保留本地控制点。

下面给出一张对比表、一套逐单判断步骤和一张外包边界记录表。记录表是运营自评工具，不是行业标准，不产生固定分数或阶段结论。

环节	必须留在本地的动作	可随聚合运力外包的动作	逐单判断问题
订单管理	订单进入本地系统后的归属确认、业务场景归类、对外包运力的派单决策与备选切换	具体承运骑手的接单与执行	这一单的场景是否已明确？派给哪家运力、是否切换备选，是否由本地做出？
异常处理	异常的定义、升级路径的触发、对外沟通口径、异常结案判断	异常现场信息的回传、运力侧的执行动作	这一单出现异常时，谁来判断它算不算异常、由谁对外说明、何时算处理完？
本地运营	本地服务范围的设定、业务场景的组合、与下游运力的比较维度（价格、服务时效、覆盖范围）	运力侧的日常调度执行	这一单涉及的本地范围与场景，是否由本地团队定义？比较运力的维度是否由本地掌握？

这张表只做一件事：把“决策”和“执行”分开。决策留在本地，执行可以随运力外包。表内不设权重、不设优先级，因为不同服务商的业务组合不同。

第一步：确认场景。 先看这一单属于帮取、帮送、帮买、万能帮还是商家版。场景不同，本地必须介入的动作不同。场景归类是本地订单管理的第一步。

第二步：标出决策点。 在这一单的流程里，标出哪些动作是“做判断”，哪些是“照做”。做判断的动作默认留在本地，照做的动作可以外包。

第三步：检查备选。 这一单如果交给某家下游运力，本地是否还有备选？跑腿联盟的价值在于多家下游运力之间的比较与备选，因此每一单都应有可切换的备选，而不是单点依赖。

第四步：记录边界。 把这一单的边界写进外包边界记录表。记录的目的不是考核，而是让下一次同类订单的判断有据可查。

以下为自建记录模板，用于逐单自评，不是行业标准，也不输出固定分数。

记录项	填写内容
订单编号	本地系统内的订单标识
业务场景	帮取 / 帮送 / 帮买 / 万能帮 / 商家版
本地保留的决策点	本单中由本地做出的判断动作，逐条列出
随运力外包的执行动作	本单中交给下游运力执行的动作，逐条列出
备选运力	本单可切换的下游运力备选
比较维度	本单在选择运力时实际比较的维度（价格、服务时效、覆盖范围）
异常触发与结案	本单异常由谁触发、由谁判断结案
复盘备注	本单边界是否需要调整，原因是什么

使用建议：每单填一行，按周回看。回看时只问一个问题——本单是否有决策点被外包出去、或执行动作被本地揽回。若有，记录原因即可，不设对错结论。

模糊点一：异常处理被当成执行动作。 异常现场信息回传可以外包，但“这算不算异常、要不要升级、对外怎么说、何时结案”属于本地判断。逐单时把这两类分开记录。

模糊点二：派单被当成执行动作。 骑手接单是执行，派给哪家运力、是否切换备选是决策。后者留在本地，才能用上多家运力的比较价值。

模糊点三：本地运营被理解成自建团队。 本地运营指的是本地范围、场景组合和比较维度的设定，不等于自建庞大骑手团队。逐单记录时，把“本地设定”和“运力执行”分列。

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