平均工单响应时间＝统计期内所有纳入工单的（首次响应时间－工单创建时间）之和 ÷ 纳入工单数，结果通常以分钟或小时表示。算出一个数字并不难，难的是这个数字能被复算、被解释、被跨期比较。计算前需要先固定三件事：响应起点取创建时间还是受理时间、首次响应如何判定、哪些工单纳入分母。本文围绕这三项口径给出定义卡、字段规则、计算步骤和一个可复算的例子，并说明结果在什么条件下可比。
要点总览（TL;DR）
- 平均工单响应时间＝统计期内纳入工单的（首次响应时间－创建时间）之和 ÷ 纳入工单数，单位统一为分钟或小时。
- 计算前先固定三项口径：响应起点取创建时间还是受理时间、首次响应如何判定（人工回复、状态变更或系统自动回复）、哪些工单纳入分母。
- 未响应工单不计入均值，单独报告数量与占比；分母为零时报告“本期无有效工单”，不记为0。
- 平均值受长尾工单影响明显，建议同时输出中位数和90分位值，三者一起解读。
- 跨团队比较需统一工作日历、时区、渠道结构与剔除规则，口径变更要留版本记录并回溯重算。
这个指标要回答什么问题
平均工单响应时间衡量的是工单从进入系统到第一次被有效回应的等待水平。它服务的管理问题是：用户提交问题后多久能得到第一次反馈，哪类工单、哪个渠道、哪个时段等待更久，响应环节是否存在系统性延迟。这个指标适合放在服务质量监控的日常看板上，按周或按月观察趋势，定位需要改进的环节。
它与其他工单指标有明确分工。解决时长（从创建到关闭）回答的是问题处理完需要多久；满意度回答的是用户对处理结果和过程的评价；工单量回答的是需求规模。响应时间只覆盖“第一次被回应”这一段，是服务体验的入口环节，不能替代解决质量评价，也不适合单独作为个人绩效考核依据——工单难度、渠道分布和排班差异都会影响个人均值。
本文不涉及SLA等级与响应时限规则如何设定，也不讨论研发交付效率类度量。前者属于工单优先级与SLA管理，后者属于研发效能管理，两者都需要独立的指标设计。
指标定义、统计范围与时间窗
把口径写成一张定义卡，是保证多人复算结果一致的前提。定义卡需要固定名称、公式、起止点、纳入范围、时间窗和单位六项内容，任何一项变更都应记录版本。
| 项目 | 建议口径 | 说明 |
|---|---|---|
| 指标名称 | 平均工单响应时间 | 与“平均解决时长”区分命名，避免混用 |
| 公式 | Σ（首次响应时间－创建时间）÷ 纳入工单数 | 分子为各工单响应时长之和 |
| 起点 | 工单创建时间 | 若业务关注受理后的处理速度，可改用受理时间，但需全期统一 |
| 终点 | 首次有效响应时间 | 有效响应的判定见下一节 |
| 纳入范围 | 统计期内创建且已产生有效响应的工单 | 剔除规则见下一节 |
| 时间窗 | 按工单创建时间归期，自然月或自然周 | 按响应时间归期会把上期积压算进本期，需明确选择并保持稳定 |
| 单位与精度 | 分钟，保留一位小数；超过一定时长可换算为小时 | 统一单位便于横向比较 |
时间窗的归期方式直接影响趋势解读。按创建时间归期，反映的是“本期进入的工单等待了多久”，适合评估入口体验；按响应时间归期，反映的是“本期发生的响应有多快”，适合评估当期人力投入的效果。两种方式都合理，但不能混用，跨期对比时必须确认前后采用同一种。
数据口径：字段、缺失值与异常处理
分母是否可信，取决于取数规则是否写清楚。计算所需的基础字段包括：工单ID、创建时间、首次响应时间、工单状态、来源渠道、优先级。工单ID用于去重，渠道和优先级用于分组下钻，状态用于判断工单是否处于可响应阶段。
首次响应的判定是口径中最容易产生分歧的一项。人工客服的第一条实质性回复通常计入；系统自动回复（如“已收到您的工单”）是否计入，取决于它是否代表真实的服务动作。如果自动回复只是确认收到，把它计入会系统性压低响应时间，掩盖真实等待；如果自动回复本身解决了问题，则应当计入。团队需要在口径文档中写明选择，并对机器人消息单独标注，便于必要时重算。
| 情形 | 处理规则 | 对分母的影响 |
|---|---|---|
| 统计期内创建、已有有效响应 | 纳入 | 计入 |
| 统计期内创建、期末仍未响应 | 不计入均值，单独报告未响应工单数与占比 | 不计入，避免用截断值拉低均值 |
| 上期创建、本期才响应 | 按归期规则处理：按创建时间归期则归上期，需回溯重算 | 视归期方式而定 |
| 重复工单、测试工单、内部演练工单 | 剔除，并在取数时保留剔除清单 | 不计入 |
| 首次响应时间缺失或早于创建时间 | 视为数据异常，退回核查，不直接参与计算 | 暂不计入，异常数单独记录 |
| 跨时区团队 | 统一换算到同一时区后再计算差值 | 不影响数量，影响时长 |
工作日历口径需要提前约定。响应时长按自然时间计算还是按工作时段计算，会带来明显差异：夜间和周末提交的工单，自然时间口径下等待更长。若团队采用工作时段口径，需要明确工作时间段、节假日表，并保证所有对比对象使用同一份日历。
在系统层面，这些字段需要有稳定的记录来源。ONES Desk 提供工单分析报表，可汇总工单处理情况并追溯工单响应过程，支持自定义工单属性与字段配置，企业版还提供多维度数据统计与分析能力。具体报表中是否预置“平均响应时间”指标、创建时间与首次响应时间对应哪些字段，需要在产品内确认后再固化到口径文档中。
计算步骤与公式
计算可以拆成五步，每一步都产出可核验的中间结果，便于他人复算。
- 确定统计期与归期方式，导出该期内符合条件的工单明细。
- 按剔除规则清理数据：去掉重复、测试、内部工单，标记未响应和异常记录，形成纳入清单。
- 逐条计算响应时长：单条工单响应时长＝首次响应时间－创建时间，统一换算为分钟。
- 求和并除以纳入工单数：平均值＝纳入工单响应时长之和 ÷ 纳入工单数。
- 补充分布指标：同时计算中位数和90分位响应时长，观察长尾情况。
边界情况需要单独约定。分母为零时，应报告“本期无有效工单”，不能记为0——0会被误读为响应极快，扭曲趋势图。存在极端值时，不要直接删除，先核查是否为真实的长等待工单；如果是真实情况，保留在均值中，同时用中位数和分位数说明分布，避免均值被少数工单主导。
建议在报表中固定输出三个数：平均值、中位数、90分位值。平均值反映总体水平，中位数反映典型工单的等待，90分位反映较慢那部分工单的体验。三者一起看，才能判断改进是否惠及大多数用户。
算一个例子：从原始工单到结果
假设某团队统计某月创建的8张工单，原始数据与处理判断如下（示例数据，仅用于演示计算过程）。
| 工单ID | 创建时间 | 首次响应时间 | 响应时长（分钟） | 处理判断 |
|---|---|---|---|---|
| A01 | 3日 09:00 | 3日 09:25 | 25 | 纳入 |
| A02 | 3日 10:10 | 3日 11:40 | 90 | 纳入 |
| A03 | 5日 14:00 | 5日 14:12 | 12 | 纳入 |
| A04 | 8日 16:30 | 9日 09:20 | 1010 | 纳入，跨夜长等待，真实值保留 |
| A05 | 12日 09:05 | 12日 09:08 | 3 | 系统自动回复，按口径不计入首次响应，改用人工回复时间 |
| A06 | 15日 11:00 | — | — | 期末未响应，不计入均值，单独报告 |
| A07 | 18日 13:20 | 18日 13:35 | 15 | 与A02重复提交，剔除 |
| A08 | 22日 08:50 | 22日 09:30 | 40 | 纳入 |
纳入计算的工单为A01、A02、A03、A04、A08共5张（A05按人工回复时间重算后纳入，示例中简化处理）。响应时长之和为25＋90＋12＋1010＋40＝1177分钟，平均值＝1177÷5＝235.4分钟，约3.9小时。将5个值排序为12、25、40、90、1010，中位数为40分钟。
结果说明：平均值被A04这一张跨夜工单明显拉高，典型工单的等待其实只有40分钟。如果只看均值，会误判整体响应偏慢；结合中位数和90分位（本例90分位接近1010分钟），可以判断问题集中在少数长等待工单上，改进方向是夜间和跨班次时段的响应衔接，而非整体提速。同时应报告本期有1张未响应工单，占创建工单的12.5%。
结果怎么读：可比性、局限与验证
平均值对长尾敏感，这是它的固有特性。工单响应时间通常呈右偏分布，少数跨夜、跨周末或复杂工单会显著抬高均值。因此解读时应以中位数描述典型体验，以高分位数描述较差体验，均值用于总量层面的趋势观察。三者出现明显背离时，优先排查长尾工单的成因。
跨团队比较需要满足同一口径条件：相同的响应起点与终点判定、相同的自动回复处理规则、相同的工作日历与时区、相同的剔除范围、相同的归期方式。任何一项不一致，比较结果都不可靠。渠道结构差异也会影响可比性，电话与在线工单的响应节奏本就不同，混合统计时应按渠道分组呈现。
口径一旦调整，需要留下版本记录并回溯重算历史数据，否则趋势线会出现无法解释的跳变。验证口径稳定性的做法包括：每月抽取若干工单人工核对时间戳；对同一期数据用新旧口径各算一次，量化差异；在报表中固定展示纳入数、剔除数、未响应数，让分母始终可见。
最后需要明确，响应时间只描述服务入口的及时性。它不能说明问题是否被正确解决，也不能替代满意度与解决质量评价。把响应时间与解决时长、满意度、一次解决率放在一起看，才能形成对服务质量的完整判断。
常见问题
工单在统计期末仍未响应，应该计入分母吗？
不建议计入均值分母。未响应工单没有终点时间，无法计算响应时长；如果强行用统计期末时间截断计算，会得到一个被人为压低的上限值，拉低整体均值。
更稳妥的做法是把它单独列出：本期未响应工单数、占本期创建工单的比例，以及这些工单的等待时长分布。这样读者既能看到响应速度，也能看到积压规模。如果未响应占比持续偏高，说明问题出在人力配置或分派机制上，单看均值发现不了。
系统自动回复算不算首次响应？
取决于自动回复是否代表真实的服务动作。如果它只是“已收到您的工单”这类确认消息，计入会系统性压低响应时间，掩盖用户真实等待；如果自动回复本身给出了处理方案或分流结果，可以计入。
无论选择哪种，都要写进口径文档，并在数据中对机器人消息单独标注，便于后续按另一种规则重算。同一份报表里混用两种判定，趋势线会失去意义。
按自然时间还是工作时段计算响应时长？
两种口径都可用，区别在于对夜间和周末提交工单的处理。自然时间口径下，非工作时段提交的工单等待会被完整计入，均值偏高；工作时段口径只累计工作时间，更贴近人力实际投入。
选择哪一种取决于指标用途：评估用户体验用自然时间，评估团队处理效率用工作时段。采用工作时段口径时，需要明确工作时间段和节假日表，并保证所有对比对象使用同一份日历，否则跨团队数字不可比。
平均值和中位数差很多，应该看哪个？
两个都看，它们回答不同问题。平均值反映总体等待水平，适合观察趋势；中位数反映典型工单的等待，不受少数极端值影响。两者差距大，说明存在长尾工单，比如跨夜、跨周末或复杂问题。
建议报表固定输出平均值、中位数、90分位值三个数。如果均值远高于中位数，改进方向通常是长尾时段的响应衔接，而不是整体提速。只看均值容易把少数工单的问题误判为普遍问题。
换了统计口径后，历史数据怎么处理？
口径变更需要留版本记录，说明变更内容、生效时间和变更原因，并对历史数据按新口径回溯重算，至少重算最近若干个统计周期。
如果不回溯，趋势线会在变更点出现无法解释的跳变，读者容易误读为服务质量突变。验证方式可以是对同一期数据用新旧口径各算一次，量化差异，并在报表中固定展示纳入数、剔除数和未响应数，让分母始终可见。
