智慧诊断在客户服务中心的应用

边江涛 叶晖 汪亮

（中国电信安徽公司 安徽省合肥市 230000）

1 引言

客户是企业生存的基石，如何为广大客户打造更加便捷、高效、更有温度的产品服务，是企业面临的重要任务。客服人员在日常处理客户投诉时，首先需要查询客户信息，然后分析判断导致客户投诉的原因，进而给出相应的处理建议。通过近年来统一客服信息门户的建设，客户信息查询的便捷性已有很大提升，不再需要登录到不同的业务系统查询，但对于用户问题原因的分析判断仍依赖人工，而由于电信业务的复杂性，人工分析判断耗时长，对人员业务能力要求高，且易出现误判、不同人回复口径不一致等问题。

针对上述问题，智慧诊断从具体业务场景切入，提供了一套从客户信息查询，到问题原因判断，再到给出处理建议的端到端解决方案。其基本思路是：首先利用数据挖掘技术，分析输出当前的热点服务场景，然后针对具体场景，梳理固化处理流程和规则，实现问题原因的自动分析定位，最后匹配相应的处理建议，以诊断报告形式反馈给客服人员。

本文内容组织如下：第2 章是智慧诊断系统的整体介绍；第3章是智慧诊断系统设计的关键技术；第4 章是智慧诊断系统的应用效果；第5 章是总结和展望。

2 智慧诊断系统

2.1 智慧诊断业务流程

传统的话务流程是用户来电后，客服代表首先与用户沟通，获取用户诉求，然后自行判断用户问题点，利用自身知识和经验给出解决方案。本文提出的智慧诊断系统，可在获取用户诉求后，一键完成对用户的问题定位，输出全面准确的诊断报告，客服代表可根据诊断报告，对用户问题做出快速处理，业务流程如图1所示。

（1）10000 号话务员与客户沟通，了解客户的诉求。

（2）如客户问题属于智慧诊断支持的场景范围，则选择相应场景启动诊断。例如手机上网资费争议（流量诊断）、宽带障碍、ITV（Interactive Television）障碍等，如图2所示。

（3）智慧诊断系统根据场景的预设流程和规则，自动进行诊断，输出诊断报告，给出客户问题原因和处理建议。

如图3所示为宽带障碍诊断报告，通过自动诊断，系统判断出导致客户宽带问题的原因是联创平台拨号报错，并在相应的诊断问题环节提供远程重置密码或解除绑定的操作按钮。

（4）10000 号客服代表根据诊断报告与客户解释沟通或进行相关业务处理。

2.2 智慧诊断系统模型

智慧诊断系统由诊断场景、诊断流程和环节、诊断因子、诊断规则、诊断报告5 个部分组成，智慧诊断系统模型各部分组成及关系如图4。

图1：智慧诊断业务流程

图2：诊断场景分类示例图

图3：宽带障碍诊断报告示例图

2.2.1 诊断场景

即某个特定的业务场景，如手机上网、增值业务、宽带障碍等。

2.2.2 诊断流程和环节

每个业务场景有一个针对该场景定制的诊断流程，流程包括多个诊断环节，流程可存在多个环节分支。

2.2.3 诊断因子

每个诊断环节可以调用1 个或多个诊断因子。诊断因子是诊断的最小单元，是组成一个诊断流程的原子服务，是判断逻辑的具体实现。诊断因子可以在不同的场景复用。如“付费模式判断”因子在各个资费类场景中均会用到。

图4：智慧诊断系统模型

图5：智慧诊断系统技术架构

诊断因子运行机制，首先是通过调用CRM（Customer Relationship Management）、计费等后台服务，查询到所需的客户信息，然后调用规则组件，输出诊断结果。

2.2.4 诊断规则

诊断规则是对业务逻辑的固化，诊断因子根据设定规则输出诊断结果。结果包括诊断因子正常或异常的状态描述，匹配诊断规则给出的问题原因和用户建议，最后将每条诊断结果做拼接，作为诊断报告中的输入信息。

2.2.5 诊断报告

诊断流程和环节执行完毕后，输出相应的诊断报告，报告主要包括三个组成部分，一是客户问题和处理建议，二是每个环节的诊断信息及是否正常，三是相关联的操作链接，如查详情、发送短信、业务退订等。

2.3 智慧诊断系统技术架构

客服24 小时在线，且忙时并发量较大，对系统的性能、可靠性和扩展性要求较高。综合考虑上述系统模型和用户需求，系统采用了服务化架构设计实现，解耦为应用、能力、数据3 层，以提升系统整体处理速度、可靠性和扩展性，智慧诊断系统技术架构如图5所示。

2.3.1 应用层

采用极简化设计，系统按具体业务进行场景封装，如手机上网、分月返还等，核心页面包括诊断场景选择、诊断过程展示和诊断报告，各诊断过程环节的诊断详情按照一定规则组合，形成诊断报告，诊断报告放在页面的最上方。应用层可以扩展，根据客户投诉热点的变化，封装新的业务场景。

表1：流量特征期望信息

表2：停机特征期望信息

表3：返还特征期望信息

表4：流量样本概率

表5：停机样本概率

表6：返还样本概率

表7：三种特征条件熵

表8：流量场景各环节特征增益计算结果

2.3.2 能力层

包括服务、流程、规则3 个核心模块，服务模块通过调用各业务系统的数据接口，查询所需的各类客户信息；流程模块用于诊断环节的实现和诊断流程的编排；规则模块用于诊断规则的配置。

2.3.3 数据层

表9：系统3 个月应用指标

包括数据库和分布式缓存[1]，数据库用于基础数据的持久化存储，分布式缓存用于加载诊断过程中频繁使用的数据、规则、业务字典、流程配置等，以提升数据存取速度和流程执行性能，实现单个流程环节秒级运算。

3 智慧诊断系统设计的关键技术

3.1 通过ID3算法确定业务诊断场景并设计诊断流程

构建诊断场景前，首先需分析运营商业务和用户投诉的相关性，确定哪些业务或者环节最易引发用户的投诉，优先把这些相关性较高的业务建设成为智慧诊断的场景，本系统选用决策树作为分析算法。

ID3[2]是决策树学习的其中一种算法，ID3 算法认为“信息增益”高的属性是好属性，通过计算历史数据中每个类别或属性的“信息熵”获得“信息增益”，并选择“信息增益”最高的类别或属性作为决策树中的决策节点。因此我们利用ID3 算法计算每个特征的信息增益，以增益大小作为选择某些业务作为诊断场景，以及场景中诊断流程和相关诊断环节编排的依据。下面我们以流量、停机、返还3 个特征与用户投诉的相关性为例，说明如何根据不同特征的增益来选择诊断场景，并设计流程的诊断环节。

我们取某客服中心6 个月的话务数据共193 万条作为样本数据集，按如下步骤分步计算熵值。

步骤一：计算信息熵。

193 万条话务数据中包含投诉话务数据共225810 条，计算得到投诉概率为225810/1930000=11.7%，非投诉概率为1704190/1930000=88.3%。

根据信息熵计算公式：

得到结果为：

E(S)=-0.883*log20.883-0.117*log20.117 ≈0.522

步骤二：计算条件熵。

计算流量、停机、返还三种业务特征与用户投诉一起出现的期望信息[3]，计算结果如表1、表2、表3所示。

再计算3 类特征划分的各属性样本在总体数据中出现的样本概率，其中P(c)=频率/话务总量，计算结果如表4、表5、表6所示。

通过以上两组值，根据决策树条件熵计算公式：

以流量特征为例，E（投诉，流量）=0.566*×0.474+0.434×0.575≈0.5179，依次计算得到三种特征的条件熵如表7所示。

步骤三：根据信息增益计算公式：

Gain(T,X)=E(S)-E(T,X)

得到流量对投诉的信息增益为：Gain(投诉，流量)=0.522-0.5179=0.0041

依次计算可得停机信息增益是0.0005，返还信息增益是0.0001；可以看出流量与投诉的相关性远高于停机和返还，因此我们优先选择流量作为一种诊断场景，提高诊断场景与投诉业务的匹配度。

在流量场景的诊断流程中，我们根据词频再选取大流量、流量包、套餐、漫游、欠费、订购、短信提醒等特征作为诊断环节，重复上述步骤，分别计算各个特征对流量投诉的增益值，所得结果如表8所示。

根据结果我们选择欠费、漫游、流量包、套餐、短信提醒这5个与流量增益较大的特征作为诊断环节，因诊断流程为串行流程，我们选择相关性较大的特征在流程前段诊断，可有效过滤大量异常用户，避免进入不必要的诊断环节以及额外诊断环节查询对接口性能的消耗，所以我们根据增益大小作为环节编排顺序，从而提高诊断效率。

3.2 快速准确定位客户问题原因

话务代表与用户每次交互，等待服务时长不应超过15s，这就要求一个业务诊断场景需在15s 内完成分析，并提供诊断报告。这对于环节较少的简单流程不是问题，但对于复杂流程（20 个环节以上），想满足这一目标极其困难，需要把单个环节平均执行时间降到1s 以内，而大多数诊断环节都有数据接口调用操作，需获取数据后再通过计算公式做逻辑判断，且某些判断规则复杂，计算量大，因此我们需要通过合理的技术手段，提升各环节执行效率。

3.2.1 基于流程引擎的多路分支，实现并行计算

为提升流程执行速度，针对流程中可能有多个走向的环节，且各个走向条件不互斥时，采取并行计算的方式，将流程按照并行多环节进行任务分解，每个环节按照配置的业务规则启动各自线程并行计算，减少串行计算等待时间，提高流程的整体处理效率。

3.2.2 动态脚本语言实现灵活配置

智慧诊断系统使用Groovy[4]动态脚本语言实现故障原因自动诊断。通过梳理故障可能涉及的原因，将其拆分成一个一个的诊断元数据和故障原因判断的诊断规则，元数据可以是欠费金额、用户状态、用户余额或手机上网累积量等用户故障可能的要素点，而故障原因判断的诊断规则包括是否有省外流量、是否超出流量在订购可选包之前等用户故障判断规则；通过服务、接口从外系统获取元数据，与诊断规则组装成诊断因子。诊断因子的条件脚本决定流程走向，结果脚本判断诊断结果，异常脚本定位故障点；最后根据流程报告脚本对各诊断因子的诊断结果进行收集整理，得出流程诊断报告。使用Groovy 脚本可实现智能诊断的快速、灵活配置。

3.2.3 大数据助力提升海量数据查询效率

运营商的流量话单数据规模在每月百亿条左右，针对如此海量数据，传统数据库已无法满足系统快速查询的要求。因此我们采用Hadoop 开源框架，打通传统关系型数据库到Hbase 的转储接口，话单数据实时入库，利用Hbase[5]对海量数据可快速查询的优点，建立数据访问接口，实现查询的秒级响应。

3.3 清晰易懂的诊断报告

诊断报告是智慧诊断的最终输出，通过一系列的诊断环节后，系统最终会将它判断的结果以报告的形式展现给客服代表，如何提高报告的可读性和准确性是一个关键技术。

我们对诊断报告采用了模板化和定制化结合的配置方式，首先根据用户关注的热点问题，将问题涉及业务信息配入报告模板，然后定制化地针对各诊断场景报告内容用自然语言重新组织，最后将展示结构重新分布，让话务员一眼即可关注到自己最关心的问题。

4 系统实际应用效果

我们采集了手机上网资费争议、增值业务资费争议两个场景的基础数据，用以分析系统的实际使用效果。分析结果主要体现在平均通话时长、手机上网资费争议的预处理率、增值业务资费争议的预处理率这三个重要指标上。其中，预处理率指用户咨询或投诉问题在客服中心直接办结，无需再向后台部门派单的成功率，通过后台监控系统取数，得到系统使用前后三个月各指标的值，详见表9。

从表9 可看出，系统上线后业务投诉的解决效率有明显提升，较好地满足了客服中心提升服务效率的需求，为客服代表的日常工作提供了很好的工具支持。

5 总结与展望

智慧诊断系统有效集成各系统能力，设计出场景化智慧诊断流程，实现客户热点难点服务问题的快速解决，降低客服中心人工学习和培训成本，有效推进了企业服务的智慧化。后期可结合WEB、微信等互联网服务渠道，将诊断能力向用户开放，实现用户问题的自助诊断和处理，进一步降低客服人工服务压力，提升服务效率。