原创 Lily 得物技术 

一、业务背景

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

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

• 在通话中解决用户问题，帮助用户查询订单，为用户咨询创建工单进行跟踪；
• 为在线客服分流一部分咨询压力，满足一部分偏爱电话用户解决紧急复杂问题的场景，提升用户体验。

二、热线功能点

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

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

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

• 状态：客服可以在热线工作台进行状态切换，例如：空闲、忙碌、小休、会议等；默认状态为空闲，空闲接入电话，其他状态不会接入电话；
• 操作台：展示当前坐席接待的最近历史10通通话，如果有通话记录被删除则递补；
• 接电话：前端获取到响铃事件与数据，带入来电信息到客服操作台，在这里获取用户基本信息，核实用户身份，查询相关订单，工单打点，跳转到工单详情。通话记录的内容包括：手机号、来电时间（接通电话时间）、归属地（省市）、添加备注、技能组、按键轨迹、删除通话记录；
• 电话条动作：电话条主要是让客服可以在通话过程中主动发起一些动作。

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

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

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

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

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

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

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

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

三、得物热线发展史

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

1.从工单衍生的需求

1.1 背景

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

1.2 技术实现

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

• 负责监听服务器下发的响铃事件；
• 监听客服主动发起的电话条动作，如来电弹窗转接等；
• 以轮询的方式向服务器发送请求，及时更新客服状态，例如是否离线，是否有当前坐席的数据变更，获取转接组数据等，如截图所示，前端会保存这些数据。

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

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,与查询的当前用户实现联动，自动带出页面信息，大幅节省客服时间。

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

4.1 背景

为什么需要核身？

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

4.2 业务流程

• 客服会通过进线用户是否本人，或者非本人是否核身情况，条件获取到用户信息，订单详情，服务轨迹以及为用户创建工单；
• 全程需要记录当前用户是否核身，核身结果会影响web做出不一样的响应，不同身份展示不同数据，业务场景如下图：

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

• 缓存：老热线只需要缓存查询出来的结果，客服并没有太多操作需要记录，并且以前默认用户进线号码就是咨询号码，只有这一种情况，缓存相对简单，但随着核身功能的加入，用户的信息变得多了起来，用户本机进线还是非本机进线，客服是否对用户核身，怎么核身的，核身是否通过，这些都是需要记录的数据，怎样维护缓存当前的数据，让客服切换左侧电话列表的同时不丢失上一次的操作，成了一个技术核心；
• 数据联动的弊端：由于代码里面势必会用到大量watch监听，一个最麻烦的现象就是一个数据的变动被好几个不相关的watch给监听到，于是执行了很多重复的逻辑，非常影响性能这个部分主要是依靠前端对于代码结构的优化。

4.4 解决办法

• 缓存的解决办法：

把之前一些组件state的数据信息，迁移至store存储，以左边的进线列表，每一通电话都会被记录成以通话ID为key的Object,value为搜索出的结果信息以及客服操作信息；

在切换列表的时候，用watch实现监听，将当前即将离开的页面（old）的state信息commit进store里面实现保存；

对于切入的目标会话（new），就拿取store里面存的值，这里的值也是来源于上一次切出时候保存的最新的值，所以一定是最新的。这里就实现了只需要保存最近结果而不需要保存客服每一次操作。

• 监听过多的解决办法：

确定watch的范围，什么时候该放大，什么时候该放小，比如一些watch其实是可以合并的，把相同的逻辑合在一起处理；

在一些处理发送接口的逻辑上，尽量缩小watch范围，否则接口就会频繁的触发；

将store结构进行改写，比如热线这里就把基本信息的数据信息单独提取了出来，作为一个常用的watch监听，这样不会干扰其他数据的监听。

到这里，如今的得物热线就这么诞生了~

四、项目成效

取数范围：4.17-4.26

五、未来规划

当然，现在的得物热线与行业内其他时间更长，更成熟的产品相比还有一定的进步空间，未来主要会做这几步：

• 合力SDK升级：现阶段电话相关功能都依赖于第三方合力接口，这也使得热线线上稳定性不太容易得到保障，很多时候避免不了和合力的沟通，这一点前期会主要推进合力SDK的升级与规范，梳理核心链路，补充兜底逻辑，总结常见问题，做到快速定位并解决问题，后期还会逐步开始自研一套电话核心SDK供使用；
• IVR核身升级：增加自助功能，把一些人工查询就能解决的前置到IVR，因为可以看到IVR核身的出现，已经达到了让人工通话时长降低的成效，这在一定程度上说明将大量冗余的人工操作放在电话语音部分是非常有必要的，因此这一部分还会继续保持，前置更多必要的自助功能；
• 工作台：短中期是会再增加一些坐席在作业中要用的查询信息（比如用户个人信息，订单信息和寄售信息的透出），这一部分主要是前端页面的改动；
• 规则类的配置：现在的热线还是基于只要是空闲状态就会被分配电话，这一部分准备与在线保持一致，会做一些排队规则，分配规则的配置页面，让热线客服也能被合理安排资源，提升效率，减少成本。

总体来说，得物热线的出现，让得物客服域生态更加完备，也让用户多了一个沟通的渠道，以后的热线也将致力于优化业务逻辑，以提高客服解决问题效率为目标，增强用户与得物客服之间的双向体验~

*文/Lily

 关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～