找出得物客服的方法得物客服在哪里找( 三 ) _生活百科

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

4.2 业务流程

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

文章插图

文章插图

核身功能加入后：

文章插图

文章插图

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

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