首次解决报表

快速阅读

首次解决报表看首次来电是否在约定口径下被解决，以及是否形成重复来电。统计主体按座席、按热线号码分开。

• 本页的首次来电解决数、首次来电解决率按 观察时长一 计算。观察时长二、观察时长三在座席报表和呼入报表的「首次解决」列里看。
• 热线总体承接仍看呼入报表。某一通的过程看客户来电记录。
• 三个观察时长在属性设置里填写，须严格升序。当天修改后，次日 0 点起生效。

阅读地图

• 先确认两个子模块：读「二」「六」。
• 要看配置如何影响口径：读「七」。
• 要核对字段和导出：读附录 D、G、H。

一、文档说明

1.1 文档目的

本文说明呼叫中心 首次解决报表 的业务定位、子模块结构、数据来源、关键指标、使用方式，以及它与呼入报表、记录页和配置口径之间的关系。

1.2 文档范围

• 覆盖：按座席统计、按热线号码统计、导出，以及首次解决口径的配置影响。
• 首次解决所依据的企业配置、呼入明细和呼入报表，建议结合对应专题一起看。

1.3 文档对象

本文档适合以下场景阅读：

• 业务负责人看首次来电是否被有效解决
• 运营看座席和热线的首次解决表现
• 实施确认首次解决统计口径和配置范围
• 技术确认首次解决标记与报表查询的关系

二、产品总览

2.1 首次解决报表是什么

首次解决报表是以“客户首次来电是否在规定时效内被解决”为核心业务对象，对首次来电接听数、首次来电解决数、首次来电解决率等进行汇总分析的统计产品。

首次解决报表回答的是“客户第一次来电时的问题，有多少在第一次服务里就被真正解决了”。

2.2 首次解决报表主要解决什么问题

首次解决报表主要用于回答以下问题：

• 首次来电被接住了多少
• 首次来电真正解决了多少
• 哪些座席首次解决表现更好
• 哪些热线首次解决率更高
• 企业设置的观察时长一是否合理

2.3 首次解决报表包含哪些子模块

三、和呼入报表的分工

首次解决报表在呼入接听结果之上，按企业配置判断首次来电是否解决、是否重复来电。呼入报表回答热线接住了多少，不代替首次解决判断。

改企业配置后，用本页原有指标复核，不另起一套字段名。

四、模块关系与数据来源

4.1 首次解决报表整体关系

首次解决报表
├── 按座席统计：看座席维度首次解决结果
└── 按热线号码统计：看热线维度首次解决结果

4.2 主数据来源概览

从系统逻辑看，首次解决报表的数据主要来自以下几类：

4.3 哪些指标更偏“接听结果”，哪些更偏“首次解决口径”

更偏接听结果的指标

• 首次来电接听数

更偏首次解决判断的指标

• 首次来电解决数
• 首次来电解决率
• 首次来电时效
• 观察时长一

4.4 为什么首次解决报表和呼入报表不是一回事

五、产品能力地图

5.1 能力概览

5.2 常见使用方式

• 先看按座席统计，判断不同座席的首次解决能力
• 再看按热线号码统计，判断不同热线的服务闭环能力

六、各子模块详解

6.1 按座席统计

产品定位

用于从座席维度看首次来电接听和解决表现，适合用于服务质量复盘和座席辅导。

主要关注内容

• 首次来电接听数
• 首次来电解决数
• 首次来电解决率

6.2 按热线号码统计

产品定位

用于从热线维度看首次解决结果，适合评估不同热线服务闭环能力。

主要关注内容

• 热线首次来电接听数
• 热线首次来电解决数
• 热线首次来电解决率

七、配置影响与边界说明

7.1 自定义报表影响

当前系统逻辑下，未看到首次解决报表明确接入统一自定义报表链路。因此：

• 字段以系统预置口径为主
• 列名和指标不按统一自定义报表的字段能力来增删

7.2 企业配置影响

首次解决报表受属性设置里的 首次来电解决统计 影响。开关打开后，本页使用其中的首次来电时效和观察时长一。

三个观察时长按「天 × 24 + 时」比较，必须一档短于下一档。未单独保存时，观察时长二、三按 2 天、3 天；若这样不能严格长于上一档，则按上一档再加 1 天递推。当天修改后，次日 0 点起按新口径标记；已经生成的历史结果不随当天改配立即重算。

观察时长二、三尚未在属性设置中保存时，座席报表和呼入报表里观察时长一仍显示为「首次来电解决数」「首次来电解决率」「首次来电重复进线数」。两档都已保存后，这两张报表上三档列名改为按时长展示：只填了天时用「1天解决数」这种名称；天和小时都填了，则折成总小时，例如 1 天 2 时显示为「26小时解决数」。三档共用首次来电接听数作分母。重复进线数等于该档接听数减去该档解决数，按客户号码计，和呼入报表里的热线重复来电数不是同一列。历史行上还没有对应结果时，单元格显示为「—」，不用 0 代替。

7.3 影响范围判断

八、典型业务场景

8.1 运营看服务闭环能力

通过按座席统计快速判断：

• 哪些座席首次解决率更高
• 哪些座席更容易引发重复来电

8.2 管理者看热线服务质量

通过按热线号码统计识别：

• 哪些热线首次解决率更高
• 哪些热线可能需要优化知识、脚本或资源投入

8.3 实施验证配置是否合理

结合观察时长一，判断：

• 当前时长是否过短或过长
• 首次来电解决率是否与业务预期匹配
• 若还要看更长周期是否再次来电，改到座席报表或呼入报表核对观察时长二、三

九、上线与使用建议

9.1 上线前建议

• 明确首次来电和首次解决的业务定义
• 明确是否启用业务类型维度
• 与业务确认首次来电时效和观察时长一，以及是否还要在座席报表、呼入报表查看观察时长二、三

9.2 使用建议

• 日常运营先看按座席统计
• 需要看不同热线差异时，再看按热线号码统计
• 要解释单通是否算首次解决，应结合原始记录与配置一起看

9.3 验收建议

建议至少核对：

• 首次来电接听数是否符合预期
• 首次来电解决数与解决率是否符合配置逻辑
• 页面与导出结果是否一致

十、总结

首次解决报表的核心价值，是把“接住电话”进一步提升到“真正解决问题”这个服务质量层面来衡量。

客户第一次来电时的问题，有没有在第一次服务里就被有效解决。

附录 A：子模块速查

附录 B：实施检查清单

• 是否已确认首次来电和首次解决的业务定义
• 是否已确认首次来电时效和三个观察时长，以及升序、次日生效
• 是否已确认是否启用业务类型维度
• 是否已核对页面与导出结果一致

附录 C：前端入口与权限速查

C.1 使用提示

• 主页面更偏按座席统计。
• 按热线号码统计是独立子模块。

附录 D：核心指标速查

附录 E：接口与查询参数速查

E.1 常见接口前缀

E.2 常见查询参数

E.3 参数说明建议

• 首次解决报表的关键不是单纯时间范围，而是当前生效的首次来电时效和观察时长一。
• 导出结果解释时，应同步说明观察时长一。观察时长二、三的列名和数值以座席报表、呼入报表为准。

附录 F：与其它产品的边界关系

F.1 使用建议

• 看“服务是否一次性解决”，优先用首次解决报表。
• 看“某通电话为什么算或不算首次解决”，优先结合记录和配置判断。

附录 G：关键字段口径详表

附录 H：页面字段与导出列对照

说明：首次解决报表导出列通常与页面字段保持一致。解释时带上当前观察时长一；不要把座席报表、呼入报表上按时长改名的列和本页列名混用。

附录 I：术语表