按GB/T 42500-2023逐单自评：售后响应记录该记哪几项？附checklist
面向本地跑腿与即时配送运营者，把GB/T 42500-2023的即时配送服务规范要求转化为逐单可填的售后响应记录：先确认问题发生在哪个端，再记录介入层级与判断类型，并附五项字段对比表、操作步骤和自评checklist。
先回答：逐单售后响应记录，最少记这五项
按 GB/T 42500-2023《即时配送服务规范》做逐单自评，售后响应记录不必写成大段描述。建议每单固定记录五项：订单标识、问题发生的端、介入层级、判断类型、响应时间点。这五项能让你在复盘时回答三个问题：问题出在哪个环节、谁先接手、当时是怎么判断的。
需要说明：下面这套记录字段和检查清单，是运营自评工具，不是 GB/T 42500-2023 的条文要求，也不是行业统一模板。GB/T 42500-2023 目前为现行国家推荐性标准，具体条款内容应以全国标准信息公共服务平台公布的原文为准。
五项字段的定位对比
| 记录项 | 记什么 | 用来识别什么 | 常见漏记情形 |
|---|---|---|---|
| 订单标识 | 单号或可回溯的唯一标识 | 能否把售后记录与具体订单对上 | 只记日期不记单号 |
| 问题发生的端 | 用户端、商家端、骑手端、管理后台等 | 问题先出现在哪个接触面 | 统一写“客户反馈” |
| 介入层级 | 首个接手人/岗位，以及是否升级 | 响应是否在某一层停住 | 只记最终处理人 |
| 判断类型 | 当时把问题归为哪一类 | 判断口径是否前后一致 | 处理完才补写结论 |
| 响应时间点 | 首次接触、每次转手的时间 | 断点出现在哪一段 | 只记解决时间 |
这张表的作用是让每单记录结构一致，便于横向比较；它不规定字段的先后顺序，也不代表某一项更重要。
操作步骤：逐单自评怎么走
第一步，先确认问题发生在哪个端。 即时配送系统通常包含用户端小程序、商家端小程序、骑手端小程序、骑手 App、管理后台和可选增值插件等多个接触面。记录时先落到具体端，而不是笼统写“系统问题”。若一单涉及多个端，按最先出现问题的端记录，其余端写在备注里。
第二步，记录介入层级。 写清第一个接手的人或岗位，以及是否发生升级、升级到哪一层。介入层级的作用是让“响应断点”可见：如果多单都停在同一个层级，就值得回看该层的处理口径。
第三步，记录判断类型。 在响应当时就写下归类，而不是事后补。判断类型由运营者自行定义分类口径，本文不预设分类名称，也不规定分类数量。
第四步，打时间点。 至少记录首次接触时间和每次转手时间。时间点用于定位断点位置，不用于给响应速度设定阈值。
第五步，归档成可比较的售后响应档案。 按同一套字段连续记录若干单后，再按“端”“介入层级”“判断类型”三个维度做汇总，观察记录分布。汇总结果只作为自评线索，不构成对服务水平的结论。
逐单自评 Checklist
以下清单为运营自评工具，可逐单勾选：
- 本单有可回溯的唯一订单标识
- 已写明问题最先出现在哪个端
- 涉及多个端时，已在备注中列出其余端
- 已记录首个接手的岗位或层级
- 已记录是否升级、升级到哪一层
- 判断类型在响应当时填写，而非事后补写
- 已记录首次接触时间
- 已记录每一次转手时间
- 记录字段与本批其他订单保持一致
- 已归入同一份售后响应档案，可与其他单比较
清单只检查“记没记、记全没记全”，不检查“记得好不好”，也不产生评分。
记录模板（可直接复制使用）
| 字段 | 填写内容 |
|---|---|
| 订单标识 | |
| 问题发生的端 | |
| 其他涉及端（备注） | |
| 首个接手岗位/层级 | |
| 是否升级及层级 | |
| 判断类型 | |
| 首次接触时间 | |
| 转手时间（可多条） | |
| 备注 |
模板刻意不设“响应是否及时”“处理是否满意”这类结论栏，避免把主观评价混入可比对的结构化记录。
使用这套记录时的三点提醒
第一，字段口径要先统一再开始记。同一批订单里“端”的写法不一致，汇总时就无法比较。
第二，判断类型由运营者自定，不同团队之间不宜直接横向对比。
第三，这套记录解决的是“响应过程可回溯”，不替代对标准原文的查阅。GB/T 42500-2023 的具体条款内容，应以全国标准信息公共服务平台公布的原文为准。
资料来源
- 全国标准信息公共服务平台：GB/T 42500-2023《即时配送服务规范》，https://std.samr.gov.cn/gb/search/gbDetailed?id=F7892066108DB223E05397BE0A0AE533
- 码科业务负责人批准口径（2026-08-30）
- 码科帮助教程，https://www.yuque.com/imake
最后核验日期：2026-08-30