好分期热线客服系统的架构演进

客服是在用户服务体验不完美的时候，进一步提升用户体验及分析解决用户诉求的一种方式，是问题发生后的一种兜底方案，随着好分期业务的快速发展，强有力的客户服务越来越成为必不可少的一环，以下两点是系统核心设计原则：

• 技术层面在流量洪峰下如何保证系统的稳定

• 业务层面中用户的首解率 &满意度

架构设计

业务架构

进阶理解好分期用户一通电话是如何在和客服架构下流转的过程。主要分为三层（线路层、通讯组件、应用层）

名词概念：

• 线路：可以理解为支持并发的电话线路

• 通讯组件：解析分发通话的服务

• 应用层：一般性业务系统如客服系统、贷后系统、电销系统等

技术架构

好分期业务发展过程中随着进线量的增加及业务的复杂度的提升，客服系统暴漏的部分问题如下

1. 接入电话后数据内部流转缓慢、CTI 操作无响应、业务数据监控数据不准确

2. 缺失对流量的管控及洪峰的对应能力，如热线爆表而其他渠道波动较小如在线渠道等

针对如上问题客服系统从两个层面对系统进行设计分别为应用层(客服系统)、中间层(通讯组件)

1. 应用层客服系统设计

• 对业务系统输出统一的话务数据，提供统一 API 接口

• 提供可视化的流程引擎，或者通过 API 接口集成

主要目的是提供一个统一的管理平台，提供可视化的入口，主要有流程引擎及对外输出统一 API 接口。

以下通过两个核心设计来实现客服系统的高性能架构。

• 客服通讯组件实现外部电话的高效接入

• 电话接入后内部快速流转催生孵化的流程引擎

1.1 流程引擎的诞生

用户的每一次进线到好分期都会一个或者多个诉求，当一线坐席不能够在当前会话中解决用户的诉求，就需要根据用户诉求创建对应的工单流转至微财下的责任部门进行处理，同时记录用户诉求及当前处理方案。微财下的责任部门根据一线坐席转交的工单进行下一步处理，直至解决用户问题结束工单流程。每个工单代表一个诉求，一个用户可以拥有多个工单，同时每个工单需要记录每一步处理人的操作内容及处理结果，可以及时反馈给用户当前处理结果，同时对于内部流转可以留痕溯源。

其实热线通话一开始是从工单侧发起，工单作为客服域最为重要的跟进用户问题的凭证，客服每天都在和各种各样的工单打交道，与用户的实时沟通需求显得尤为迫切，这就是热线业务的初诞生，这个时期的热线只是依附于工单的一个功能。

这个阶段主要是实现与话务系统打通，做到如何让用户和客服能通上话才是重点，用户拨打电话到客服接收到电话，这个阶段的服务架构如下：

面对好分期业务的快速发展，很多为了提升用户首解率，降低投诉率的需求也都蜂拥而至，而在客服场景中很多场景都是有公共属性的例如：审批流程会应用到减免、余额提现、相关额度申请等，工单数据流转会在一线员工、主管、经理各个层级之间往复流转，流转规则穿插在业务中的各个环节中，很多的共通性带来了很多的重复开发，所以我们开始思考流程引擎的开发。好分期客服在处理用户问题痛点如下：

1. 针对呼叫中心模式如何辅助一线坐席快速处理用户反馈问题

2. 创建的工单如何准确的转交责任部门并快速响应处理

      如何应对业务变更中茫茫多的业务流程及研发的效率

3. 提升 24 小时内用户首次来电有效解决用户问题的效率

针对如上三个个核心问题，需要一套贴合呼叫中心模式的可视化流程引擎，可视化的引擎配置，不仅要解决研发人员大多数业务流程的开发工作，同时运营侧亦可根据业务场景进行配置，也为实际流程运行时的运营工作提供了便捷的处理方式，可视化能将流程实际运行情况清晰的展示到界面上，使得运营人员能快速对线上问题进行定位。

• 提供可视化的引擎配置，能够留痕溯源

• 以终端来电，计算用户轨迹，获取流程模板

• 预设工单流程，定义节点

• 根据业务策略，设定流转规则

• 可针对处理时效，设置节点阈值并进行预警

• 根据引擎规则，辅助一线坐席自动建单

始于终端用户的一通电话，通过计算用户 IVR 轨迹直接进入流程，完成智能自动建单，形成数据闭环。节省人工资源，减少工单流转率，提升首解率。

1.2 流程引擎设计

使用案例：如用户来电因为某种原因，希望进行减免操作，如下为引擎的建单过程

1. 用户来电过程会通过语音机器人识别的用户意图并合并历史用户轨迹重新定位用户意图进行机器学习，命中减免规则模板

2. 减免流程编排为开始节点->主干管审批节点->经理审批节点->部门负责人审批节点-结束节点

3. 流转规则设置审批金额小于"X"元一级审批结束；小于等于"Y"元审批至经理审批节点结束；大于"Z"元审批至部门负责人审批结束

4. 以主管审批节点为例，设置审批时效为派单起 1 小时，超时一级预警方式为消息提醒，二级预警方式为短信提醒，三级预警方式为电话提醒，当工单流转至主管审批时开始自动计时，按照超时级别对责任人进行提醒

5. 直至流转至结束节点停止计时和预警，开始节点到结束节点期间全部按照流程配置进行流转和预警

如上案例如何通过引擎快速创建工单及流转的全部过程，从用户来电创建工单及工单整体流转过程的处理时效和预警有效的解决当前业务的问题

• 接通电话快速建单

• 合理处理时效和有效的预警大大提升处理效率

• 业务调整仅需调整流程配置无需开发

• 时限内处理完成工单，有效提升首解率

流程引擎架构图：

1.3 核心组件

• 流程（Flow）：  设置流程编号使用权限范围及流程基础信息

• 流程任务（Todo）：具体执行流程树的最小的分支，具体到某个人员的代办事项

• 流程节点（Node）：主流程中设置的阶段性节点，预设多种节点类型（建单、审批会签、审批或签、审批依次签、处理、回访、提醒、闭单）等等，无需开发。可按照节点类型自定义节点，节点可扩展性强，如特殊处理节点可自定义实现，配置节点类型即可使用

• 流程处理人（People）：流程流转过程中的内置处理人，可指定多类型处理人（指定具体人、指定多级处理人、在线用户、指定组织机构、抄送人员）等等，指定任务分配方式内置（平均分配、轮询分配）等等。以及接收任务时的提醒方式内置（发起提醒、完成提醒）等方式，同时可通过动态参数方式指定任意处理人

• 流转条件（Control）：流程编排中节点间的流转条件，可使用内置参数，也可以动态参数指定

• 流程节点处理时限（SLA）：流程编排中每个节点的要求完成时长，流转至当前节点创建任务自动计算当前任务要求完成时长，创建任务后为当前处理人自动计时。通过节点预警设置的预警方式进行有效的提醒

• 流程节点预警（Warning）：流程编排中节点设置处理时限超时后的预警方式，可设置多级预警级别适配不同预警方式，内置预警方式（企业微信消息提醒、短信提醒、邮件提醒、电话提醒）等方式。确保处理人在要求完成时间内处理当前工单 

1.4 流程引擎效果

• 贴合呼叫中心模式，终端来电与与流程引擎无缝连接，通过用户 IVR 轨迹直接进入流程

• 提供可视化页面，简洁美观，扩展性强大，极大的降低代码维护

• 完全自定定义流程，可视化流程引擎配置，支持节点、流转规则自定义，丰富阈值预警

• 支持多租户，数据分离，支持热部署

• 标准简洁的 API 接口

引擎对比：

工单指标对比：

2.  通讯组件设计

通讯组件以往是一个统一的大服务，处理用户电话到客服系统间数据交换的服务，主要职能包含电话的解析(agent 数据、分机数据、技能组数据、间隔报表数据)等，各个渠道数据采集、CTI 数据处理、标准化数据入库、数据实时推送等。由于不能根据当前流量控制资源使用情况，会出现数据延迟、CTI 操作无响应、监控数据不准确等一系列问题。如下是针对以上问题设计的核心原则

• 通讯服务拆分及组件化，由一个服务按照数据流拆分多个组件，组件间进行互备

• 增加 Callcenter 路由组件可插拔，计算当前流量分配可使用的资源

• 主备话务服务改用路由（主备可同时使用），洪峰到来时可调用备用资源分摊压力

• 流量管控，按照当前资源设置阈值，根据阈值级别分流到不同渠道（分流智能 IVR、在线客服、按键 IVR）

• 服务降级，自动化三级降级策略，自动恢复、阈值决策、硬话机接听

通讯组件拆分及其功能：   

通讯服务按照使用渠道、流量压力及扩展性进行拆分，分别为数据采集、CTI 平台、数据接收、数据汇总、数据推送及控制台。

• 数据采集组件：为了方便扩展，每一种类型的数据来源做成一个组件服务，获取到数据后通过统一接口推送到服务层负责对数据进行处理。定位于适配各大厂商的 CTI 为现场监控或者大屏监控系统提供统一的数据接口

• CTI 组件：软电话服务用于业务行进行接打电话使用

• 数据接收组件：接收数据获取采集组件获取到的数据及 CTI 相关数据，对数据进行分类处理

• 数据汇总组件：接收各组各组件推送过来的数据进行计算及入库。并将数据推送给推送组件，数据包含标准话务数据（agent 数据、分机数据、技能组数据、间隔报表数据）等等

• 数据推送服务：对外提供接口，针对不同的接口进行数据推送分发

• 控制台：负责通过当前流量计算可以是使用组件,以及是否需要引流等操作

通讯组件对外提供给业务端的数据获取接口，Web 接口，WebSocket 接口，前端通过 js 接收数据。

报表系统通过 Web 接口来获取统计数据，实时监控系统通过 WebSocket 推送实时数据，通过 Web 接口获取历史明细数据。

项目成果

整体项目实施中，分为三个阶段

• 阶段一：单体架构，系统提供通话功能，首解率、系统 SLA、用户满意度均停留在较低水平

• 阶段二：多活架构，系统整合了多个金融服务，系统提供工单功能，首解率、系统 SLA、用户满意度趋于行业平均水平

• 阶段三：高可用架构，系统可进行弹屏辅助、动态压力感知，快速扩容，熔断降级的功能，首解率、系统 SLA、用户满意度均高出行业平均水平

未来规划

现阶段热线客服整体架构已经趋于完善，但是整体架构还是和客服服务耦合严重，如果想要快速的迁移和扩展则需要较大成本，介于此话务中台顺势而生，下个阶段将会将整套的高可用架构进行封装为话务中台，微财下各个呼入呼出场景的业务均能快速集成并使用。

如下为话务中台核心设计原则：

• 汇总当前所有接入渠道，统一由话务中台接入，输出统一的接入 SDK

• 增强话务中台的延展性，提供统一的控制中心

• 加强话务中台的核心价值及对业务系统的适配能力

作者信息：

刘志敏，微财数科高级工程师 

张兆强，微财数科资深工程师

李军，微财数科技术总监

吴迪，微财数科产品技术负责人