当前位置：网站首页>得物客服热线的演进之路

得物客服热线的演进之路

2022-07-07 11:33:00 【InfoQ】

一、业务背景

得物为什么需要单独的热线？

随着得物业务的快速发展，强有力的客户服务越来越成为得物必不可少的一环，在原有IM聊天基础上，得物催生出属于自己的热线系统。主要意义有：

在通话中解决用户问题，帮助用户查询订单，为用户咨询创建工单进行跟踪；

为在线客服分流一部分咨询压力，满足一部分偏爱电话用户解决紧急复杂问题的场景，提升用户体验。

二、热线功能点

如今的得物客服热线到底可以做些什么？

内呼：
用户通过400电话呼入咨询客服，增加用户咨询渠道，减轻IM客服接待压力，提升服务质量；

用户点击专属热线，打开手机拨号，如下图所示：

客服侧在接到来电之后又可以用得物热线工作台做些什么呢？如下图所示：

状态：
客服可以在热线工作台进行状态切换，例如：空闲、忙碌、小休、会议等；默认状态为空闲，空闲接入电话，其他状态不会接入电话；

操作台：
展示当前坐席接待的最近历史10通通话，如果有通话记录被删除则递补；

接电话：
前端获取到响铃事件与数据，带入来电信息到客服操作台，在这里获取用户基本信息，核实用户身份，查询相关订单，工单打点，跳转到工单详情。通话记录的内容包括：手机号、来电时间（接通电话时间）、归属地（省市）、添加备注、技能组、按键轨迹、删除通话记录；

电话条动作：
电话条主要是让客服可以在通话过程中主动发起一些动作。

a.点击保持：保留通话，用户侧听到为音乐；

b.点击恢复：恢复通话；

c.点击转接：转接至空闲客服，可取消转接，被转接客服接听后转接客服挂断，转接至客服组，通话挂断，被转接客服组内轮询至空闲客服；

d.点击咨询：咨询空闲客服和客服组；

e.点击转调查：挂断电话；

f.点击邀评：用户评价；

g.点击挂断：挂断电话。

坐席外呼：
使用客户端电话软件向外拨打电话，主要场景是二线客服，在处理工单的时候，为了及时有效的和客户沟通，坐席通过外呼和客户联系。

三、得物热线发展史

先来看看现在的得物热线有哪些功能，如下图所示：

如上图所示，现在的得物热线功能主要包括工单管理、用户管理、订单管理、查询历史信息和电话管理五大功能模块，功能相对比较完善，基本满足了所有用户进线咨询的需求，然而其实热线的发展也不是一开始就这么完备的。经历了以下几个阶段：

下面来看一下得物热线是如何技术实现这每一个大步的~的~

1.从工单衍生的需求

1.1 背景

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

1.2 技术实现

这个阶段主要是实现的与第三方电话软件的接通，如何让用户和客服能通上话才是重点，用户拨打电话到客服接收到电话，过程如下图：

首先热线的代码里面会注入电话相关SDK，这里使用的是第三方合力SDK，它主要负责三件事情：

负责监听服务器下发的响铃事件；

监听客服主动发起的电话条动作，如来电弹窗转接等；

以轮询的方式向服务器发送请求，及时更新客服状态，例如是否离线，是否有当前坐席的数据变更，获取转接组数据等，如截图所示，前端会保存这些数据。

合力：
热线主要用的是合力三方热线服务，通过合力提供的电话服务做二次热线服务能力的开发。

SDK如何监听响铃时间和监听电话条动作，以响铃事件为例：

来电首先会通过合力服务器下发，调用SDK中的_softphonebar_evtRing方法；

通过全局注册的hollyglobal.ringEvent，下发ringEvent事件以及数据；

代码里的事件监听所捕获，在handleRingEvent方法里执行业务逻辑，加工数据；

其他电话条操作同理。

这样基本的通话功能就完成了，接下来只需要操作工单就可以了。

工单时期的热线一览：

2.辅助模块的诞生

2.1 背景

随着客服域章鱼工作台的独立孵化，热线作为重要的一部分，从工单迁移至章鱼工作台，这个时候的章鱼只能接打电话，查询基本信息，因为从工单迁移出来失去了和工单的绑定，因此与工单的重新结合，成为热线的一个里程碑式升级。

2.2 技术实现

在这个地方，热线从之前的iframe内嵌工单页面，转变成接入工单的远程组件。

iframe缺点
：热线有不止一处用到工单，每一次打开就是加载另一个完整项目，客服要不断地切换不同通话，整个体验非常卡顿，性能非常不好；

模块联邦优点
：从项目降维到组件，不用加载别人整个项目，只需要像使用自己项目里的平常组件一样去使用别人项目里的组件，只需关注这一个组件，开箱即用。

除此之外，服务轨迹模块也绑定了与来电用户手机的绑定，热线从只支持转接到一个客服组，变成还可支持单独的一个坐席，完善了整个转接模块与辅助模块功能。

3.与App金融侧完成对接

3.1 背景

仅仅只有工单打点，查询用户基本信息，热线功能依然是不完善的，用户来电势必会有各种各样的疑问，不仅是名下订单咨询，随着App金融侧计划上线面向用户使用后，询问寄售单以及金融情况的用户大量增多。

增加寄售单查询的功能，满足寄售单查询场景，不再需要单开寄售单查询系统；

增加佳物借贷：客服帮助来电用户查询或询问在分期内提供提现能力，回答备贷贷开通等相关事宜。

3.2 技术实现

这里因为只有在特定情况下才会进行金融，寄售查询，并且页面只是一个简单的查询结果页面，这里采用iframe嵌入寄售与金融查询两个tab，src查询参数为用户ID,与查询的当前用户实现联动，自动带出页面信息，大幅节省客服时间。

4.语音链路大升级-ivr核身

IVR核身这一升级标志着得物的客服热线系统整条链路已经基本完备。

4.1 背景

为什么需要核身？

得物热线拉取2021年10月份至今的数据，非进线手机咨询量占比为40%，需核身的场景占总进线的20%左右；占比非常之高，且每通电话核身耗时为30S左右，一定程度上拉长平均处理时长，影响用户体验；

人工核身本身存在出错率。

4.2 业务流程

客服会通过进线用户是否本人，或者非本人是否核身情况，条件获取到用户信息，订单详情，服务轨迹以及为用户创建工单；

全程需要记录当前用户是否核身，核身结果会影响web做出不一样的响应，不同身份展示不同数据，业务场景如下图：

核身功能加入后：

4.3 技术挑战

除了合力侧需要在进入人工前的电话环节配置相应的语音提示节点，记录用户输入的手机号或者身份信息，后端返回相应的用户查询结果之外，在进入人工后热线前端主要解决的技术挑战有两个：

缓存：
老热线只需要缓存查询出来的结果，客服并没有太多操作需要记录，并且以前默认用户进线号码就是咨询号码，只有这一种情况，缓存相对简单，但随着核身功能的加入，用户的信息变得多了起来，用户本机进线还是非本机进线，客服是否对用户核身，怎么核身的，核身是否通过，这些都是需要记录的数据，怎样维护缓存当前的数据，让客服切换左侧电话列表的同时不丢失上一次的操作，成了一个技术核心；

数据联动的弊端：
由于代码里面势必会用到大量watch监听，一个最麻烦的现象就是一个数据的变动被好几个不相关的watch给监听到，于是执行了很多重复的逻辑，非常影响性能这个部分主要是依靠前端对于代码结构的优化。

4.4 解决办法

缓存的解决办法：
把之前一些组件state的数据信息，迁移至store存储，以左边的进线列表，每一通电话都会被记录成以通话ID为key的Object,value为搜索出的结果信息以及客服操作信息；
在切换列表的时候，用watch实现监听，将当前即将离开的页面（old）的state信息commit进store里面实现保存；
对于切入的目标会话（new），就拿取store里面存的值，这里的值也是来源于上一次切出时候保存的最新的值，所以一定是最新的。这里就实现了只需要保存最近结果而不需要保存客服每一次操作。