异常发生在取件前还是送达后？按订单阶段做一次处理位置记录

先回答：异常处理精力该投在哪一步

不要笼统地问“售后怎么处理”，而要按订单阶段把异常拆成四个可记录的位置：取件前、取件后、送达前、送达后。每发生一次异常，就逐单标记它发生在哪个位置、由哪一端发现、由谁处理。这样做的目的不是追求一个行业通用的阶段顺序，而是让城市运营者能用自己的订单记录，看清异常处理精力实际落在哪一步，再决定往哪里投。

需要说明：下面的对比表、步骤和清单是运营自评工具，不是行业标准，也不构成对任何平台政策或产品能力的描述。

四个处理位置怎么区分

处理位置	记录时问自己的问题	需要同时记下的两项
取件前	异常是否发生在骑手取到物品之前？	由哪一端发现（用户端、商家端、骑手端、管理后台等）；由谁处理
取件后	异常是否发生在取件之后、送达之前？	同上
送达前	异常是否在临近送达环节才暴露？	同上
送达后	异常是否在订单送达之后才被提出？	同上

这张表只提供记录维度，不预设哪个位置更重要、哪个位置异常更多。位置判断以订单实际记录为准，运营者应逐单填写，而不是凭印象归类。

按订单阶段做记录的四步

1. 选一个时间窗口内的订单作为样本，逐单回看异常记录。
2. 对每一条异常，先判定它发生在取件前、取件后、送达前还是送达后，填入对应位置。
3. 在同一行补记“由哪一端发现”和“由谁处理”，不要只写“已处理”。
4. 汇总后按位置统计条数，形成本期异常处理位置分布，作为下一期自查的对照基线。

第4步的汇总只用于自身纵向对比，不与其他城市或行业数据比较，也不据此推导固定阈值。

异常处理位置自查表（checklist）

以下清单为运营自评工具，可按团队实际情况增删项目：

• 本期样本订单范围已确定，并写明起止时间。
• 每条异常都已标记位置：取件前 / 取件后 / 送达前 / 送达后。
• 每条异常都已记录发现端：用户端、商家端、骑手端、管理后台或其他实际存在的端。
• 每条异常都已记录处理人，而不是只写处理结果。
• 位置标记与发现端、处理人记录在同一行，可逐单回溯。
• 已按四个位置分别汇总条数，形成本期分布。
• 已标注哪些记录因信息不全而无法定位，并单独列出。
• 下一期复查时，沿用同一套位置口径，保证可比。

记录时的三个常见偏差

• 只记“已解决”，不记位置：事后无法判断精力落在哪一步。
• 把发现端和处理人混为一谈：发现异常的一端不一定就是处理异常的一方，两项应分开填。
• 用印象代替逐单标记：位置分布应来自订单记录，而不是复盘会上的大致判断。

这套记录适合谁

在聚合配送模式下，城市服务商可把重心放在订单管理、异常处理和本地运营，不必在起步阶段自建庞大骑手团队。对这类运营者来说，异常处理位置记录是一种低成本的自查动作：不需要新增系统能力，只需要在现有订单管理流程中固定四个位置字段和两项责任字段。系统侧涉及用户端小程序、商家端小程序、骑手端小程序、骑手 App、管理后台和可选增值插件等界面，记录时应以实际使用的端为准。业务场景上，帮取、帮送、帮买、万能帮和商家版等场景都可能产生异常，记录口径应保持一致，便于跨场景对照。

资料来源

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

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