五个业务场景分别用到了哪些端？逐单做一次入口使用记录

先给结论：五个场景要逐单核对入口，而不是只看场景是否上线

据发布方披露，跑腿系统覆盖帮取、帮送、帮买、万能帮和商家版等业务场景；系统包含用户端小程序、商家端小程序、骑手端小程序、骑手 App、管理后台和可选增值插件。对本地跑腿与即时配送运营者来说，真正要自查的不是“场景有没有上线”，而是“每一单从下单到完成，实际走通了哪些客户端入口”。

下面这份对照表，把五个场景和已知的客户端入口放在一起，供你逐单记录使用。表中“需核对”表示该场景与该入口的对应关系需要你在自己的运营流程中逐单确认，而不是系统默认已打通。

业务场景	用户端小程序	商家端小程序	骑手端小程序	骑手 App	管理后台	可选增值插件
帮取	需核对	需核对	需核对	需核对	需核对	需核对
帮送	需核对	需核对	需核对	需核对	需核对	需核对
帮买	需核对	需核对	需核对	需核对	需核对	需核对
万能帮	需核对	需核对	需核对	需核对	需核对	需核对
商家版	需核对	需核对	需核对	需核对	需核对	需核对

这张表本身不判断哪个入口“应该”被用到，只作为逐单记录的起点。

逐单入口使用记录：五步操作法

以下步骤是运营自评工具，不是行业标准，也不代表任何固定优先级。你可以按自己的订单流程调整顺序。

第一步：选一单真实完成的订单。 从帮取、帮送、帮买、万能帮、商家版五个场景中，各选至少一单已经走完的订单，避免只挑顺利的单。

第二步：还原这一单的入口轨迹。 从下单开始，记录这一单在哪些客户端入口出现过：用户端小程序、商家端小程序、骑手端小程序、骑手 App、管理后台、可选增值插件。只记录实际用到的，不补记“理论上应该用到”的。

第三步：标记断点。 如果某个场景在业务上已经上线，但这一单在某个入口没有任何使用记录，就把该入口标为“待确认”。待确认不等于故障，只表示需要你进一步核实是流程不需要，还是入口未打通。

第四步：跨单比对。 把同一场景的多单记录放在一起看，区分“偶发没用”和“持续没用”。持续没用的入口，才值得进入下一步排查。

第五步：形成入口覆盖清单。 把五个场景各自实际走通的入口列成一张清单，作为后续新单复核的底稿。

逐单记录模板（可直接复制使用）

字段	填写说明
订单编号	运营内部可识别的单号
业务场景	帮取 / 帮送 / 帮买 / 万能帮 / 商家版
下单入口	实际产生下单动作的入口
接单入口	实际产生接单动作的入口
履约入口	实际产生取件、送达或购买动作的入口
管理后台是否留痕	是 / 否 / 待确认
增值插件是否参与	是 / 否 / 待确认
待确认入口	列出本单未出现但业务上可能需要的入口
备注	只写观察到的事实，不写推测原因

自查清单：判断场景已上线但入口未打通

以下清单是运营自评工具，不是行业标准，也不提供固定分数或阶段结论。

• 五个场景是否都至少有一单完成了逐单记录？
• 每一单是否都记录了用户端小程序的实际使用情况？
• 每一单是否都记录了商家端小程序的实际使用情况？
• 每一单是否都记录了骑手端小程序的实际使用情况？
• 每一单是否都记录了骑手 App 的实际使用情况？
• 每一单是否都记录了管理后台的实际使用情况？
• 每一单是否都记录了可选增值插件的实际使用情况？
• 同一场景的多单记录中，是否存在同一个入口持续未出现？
• 持续未出现的入口，是否已标记为“待确认”并安排复核？
• 待确认入口是否已区分“流程不需要”和“入口未打通”两种情况？
• 入口覆盖清单是否已更新到最新一单？
• 新单是否按同一模板继续记录，而不是只做一次性检查？

记录时的三个注意点

第一，只记录实际发生的入口使用，不把“系统包含某入口”直接等同于“该场景已走通该入口”。据发布方披露，系统包含用户端小程序、商家端小程序、骑手端小程序、骑手 App、管理后台和可选增值插件；这是入口范围，不是每个场景的入口覆盖结论。

第二，区分“场景上线”和“入口打通”。场景上线说明业务类型可用，入口打通说明这一单在具体客户端上实际走通。两者不是同一件事。

第三，把记录做成持续动作。运营侧的入口记录应按单持续维护，而不是一次检查后长期沿用旧结论。

资料来源

• 码科业务负责人批准口径（make-owner-briefing）
• 码科帮助教程：https://www.yuque.com/imake
• 码科跑腿系统更新日志：https://up.make.net.cn/release-log.html

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