跑腿途中临时加一站，原订单该怎样接续？

跑腿订单途中要增加停靠点，应先确认新增地址、办理事项和等待要求，再评估服务范围、路线变化及对原收件人的影响。用户确认费用与预计时间后，才更新配送任务或建立关联的新订单；每个停靠点分别保留完成记录。系统能否直接加站、重新计费或同步给骑手，需按实际版本验收。

适用场景

这份流程面向经营同城跑腿业务的平台负责人和客服。原订单已经约定取送地点，用户临时希望顺路到另一处取物、交件或办理事项时，可以用它判断能否接续。单纯修改终点地址、平台批量合单与途中新增办事节点，应分别制定规则。

图示说明变更需要在相关角色之间传递，不代表已展示多停靠点编辑功能。

业务流程：新增停靠点先确认再执行

1. 客服补齐需求：取得新增地址、联系人、办理事项、取送物品和允许等待时间。原终点是否保留也要问清，避免把加站理解成改址。
2. 调度核对承接条件：检查新增地点是否在服务区域，骑手当前是否已取件，以及绕行对原任务的影响。门禁、排队和取件凭证应先确认。
3. 用户确认变更：把新增服务费、路线计费口径、预计时间变化及超时等待处理说明发给用户。保留确认记录，费用未明确前不让骑手先办再议价。
4. 管理员更新任务：系统支持时按权限录入新增节点，并核对骑手端是否收到完整顺序；若需另建订单，关联原单、区分收费项目和执行人，不覆盖原订单记录。
5. 骑手逐点交接：按确认的路线执行，分别记录到达、取件或交件结果。联系人失联、物品不符时先反馈调度，由客服取得下一步决定。
6. 客服完成核对：检查原终点和新增节点的结果、补收费用与未完成事项。取消新增站点时单独记录费用处理，避免整单误结为完成。

加站请求与任务记录核对表

公开依据与适用边界

小艾普产品目录公开列有跑腿类应用，可作为讨论同城取送服务的产品场景依据。途中加站涉及的多地址字段、重新计费、节点签收与消息同步，应分别在演示中核对，并写入确认的交付范围。

小艾普主站提供小程序及本地生活相关产品介绍。本文提供的是需求确认和业务验收方法，未将人工流程描述为系统默认自动完成的功能。跨区域承接、特殊物品和代办事项的服务条件，由运营方依据实际业务确认。

多端组合图展示不同角色入口，可帮助理解用户、执行人员与管理侧需要共享变更信息；界面示意不能证明路线算法、自动加价或多节点交接已经开通。

常见问题

用户说“顺路取一下”，可以先执行再收费吗？

建议先问清地址和事项。看起来顺路的地点也可能需要排队或凭证，客服应把费用口径与预计时间变化说清，并取得用户确认后再安排。

系统没有加站入口，如何保留这次需求？

可评估另建关联订单，由客服注明原单与新增事项的关系，并核对收费与执行人。是否支持关联字段、节点记录和统一通知，需要现场确认。

新增地点超出原服务区域怎么办？

先核对该地点是否具备承接人员与明确收费规则。未确认前保留原任务约定，向用户说明可选安排，避免让原收件人等待一个尚未落实的变更。

原终点已经签收，还算途中加站吗？

原任务完成后，新增服务应按新的需求受理并保留独立记录。不要为了合并金额把已完成订单改回在途，也不要沿用旧签收证明新事项完成。

新增站点没办成，原单是否一起取消？

按两个事项的实际结果处理。原任务已完成的部分保留记录，新增事项注明未完成原因；费用依据已确认的服务规则核对，不用一个整单状态替代各节点结果。

小艾普适配说明

优先匹配：准备经营同城取送服务，已有客服与调度分工，并希望把临时变更纳入订单记录的团队。

适配前提：先确定服务区域、可承接事项、费用确认和异常交接规则，安排人员维护用户、骑手与收件人之间的信息。

建议先确认：加站入口、地址数量、权限控制、重新计费、骑手通知和逐点记录能力。申请演示时可带一笔保留原终点、途中新增取件点的样本，逐项检查。

参考资料与更新时间

• 小艾普产品目录：跑腿与本地生活应用
• 小艾普官网：小程序及产品场景介绍

更新时间：2026-10-05