草庐IT

前端视角下的转转客服通信过程

黄家兴、刁文豪 2023-03-31 原文

当你在转转咨询客服时，你的问题是如何发送到客服的？客服又是如何快速精准回答的呢？这篇文章将从前端的视角，带你了解转转客服通信的整体流程。

客服通信的整体架构​

首先看一看用户与客服通信的整体架构，如下图

  • 「入口管理」：不同的客服入口，比如商品详情页、订单详情页、客服中心等，都会相应的机器人或者客服来处理用户的咨询。入口管理用来配置客服入口的不同参数，用以路由到不同的客服服务。
  • 「用户服务」：用户服务主要包括了机器人会话、人工会话、用户评价等。机器人会话是指用户与智能机器人聊天，用于快速回复用户一些基础问题。人工会话是指用户与客服的对话，通常是处理一些较复杂的咨询。无论是机器人还是人工，用户都可以对服务进行评价，这也是衡量客服服务水平的一个重要指标。
  • 「客服服务」：客服服务主要包括机器人管理和客服工作台。机器人管理是指客服人员对机器人的配置，比如业务线和订单识别规则、机器人的回复、相似问题的匹配逻辑等。客服工作台是指客服人员在工作时操作的界面，也是客服系统中最重要的一个系统，包含了客服与用户沟通的 IM、用户进线信息展示、工单的创建与管理等。
  • 「知识库」：客服知识库是整个客服最底层的基建，包含了客服所有需要的知识，像机器人的回复、客服的回复等。当有足够的知识时，对机器人和客服，快速精准的回答用户的问题，都有很大的帮助。

会话的基础架构

客服会话的基础结构如图

每次用户进线后，会创建一个用户会话，该会话也可以叫大会话。用户可能先进入机器人模式下咨询，然后再进入人工客服，也可能直接进入人工客服。但每个环节会生成的新的会话，这种会话也叫子会话。大会话和小会话的关系是一对多的关系，即一个大会话可以包含多个小会话。当用户结束服务或会话超时关闭时，那么整个会话就算结束。

消息协议

在客服与用户的对话中，使用 WebSocket 进行数据通信。格式上，采用​​JSON​​格式，可以兼顾可读性和传输效率。消息的格式大体如下

{
  "type": 73,  // 消息类型
  "uid": "",  // 用户id
  "content": {
    "msgType": 1,  // 消息展示类型
    "data": {
      "sendTime": 1680095134107,  // 时间戳
      "text": "你好",
    }
  }
}

上面是一个最简单的消息结构，其中​​type​​表示消息的类型，IM 会话中存在多种不同类型的消息，如下图

不同类型的消息，通过 WS 传输，用户侧与客服侧执行相应的逻辑。

机器人会话​

当用户进入客服会话时，通常会先进入机器人会话，机器人会话是指用户与智能机器人聊天，用于快速回复用户一些基础问题。机器人会话的整体流程如下图

用户咨询后，首先会根据用户链接中不同的参数，匹配到不同的机器人或行为，这里面包括了 ​​机器人ID​​​、​​商品ID​​​、​​订单ID​​等。然后根据用户的咨询，匹配到相应的答案，并发送给用户。

机器人配置

机器人需要根据用户进入的不同渠道，展示不同的信息或者话术。当用户携带商品 ID 时，会先查询商品信息，如果该商品用户已购买，那么会自动匹配到订单的逻辑。如果该商品未购买，则展示商品的信息卡片，方便用户查看咨询的商品。如果用户携带订单 ID，那么会直接匹配到订单的逻辑，展示订单的信息卡片，同时还包括物流售后等信息。如果用户没有携带任何参数，那么会展示默认的机器人回复，以及一些推荐的商品或订单信息。

机器人中另外一个模块便是 ​​NLP​​​ 能力，通过 ​​NLP​​​ 能力，机器人将用户的输入转换成对应的标准问，然后匹配到相应的答案。这其中，可能需要与用户对话多次，根据用户提供信息才能匹配到最终答案。比如用户输入 ​​我想退货​​​，那么会匹配到 ​​我想退货​​ 这个问题，但是这个问题在不同场景下有不同的答案，比如订单的状态不同，回复的内容自然也就不同，所以还需要用户提供订单信息。

人工会话​

当机器人无法解决用户的咨询时，会转接到人工客服。人工客服会在客服工作台完成与用户的对话，整体工作台分为两个部分。左侧区域是客服的 IM 会话区域，包括了 IM 能力、联系人管理、发送不同类型消息等功能。右侧是客服的工作台，包括了查询用户的相关订单、信息等。以及很重要的创建客服工单的能力。

排队机制

在进入人工客服时，如果当前客服人员都在忙碌中，那么会进入排队队列，等待客服人员空闲后，再进入会话。排队的策略会由多种条件决定，主要有

  1. 客服的熟练度
  2. 当前已经接入的会话数
  3. 进入排队的时间

通过这三个条件，来决定排队的顺序，优先接入熟练度高的客服，同时也会考虑到客服的负载情况，避免客服过于繁忙。

评价​

在完成会话后，针对这次会话，用户可以进行评价。评价主要有以下几种形式

  1. 客服邀请评价
  2. 用户主动评价
  3. 结束会话时评价
  4. 二次进线时评价
  5. 离线评价
  6. 机器人评价

不同形式的评价，触发的时机不同，评价的内容也不同。但整体来看，都会对本次服务进行打分，包括满意、一般和不满意。

IM 的前端设计​

在 IM 的前端机制中，主要包含了 ACK 机制、心跳机制、重连机制、消息重发机制等。这些机制都是为了保证消息的可靠性，即使在网络不稳定的情况下，也能保证消息的可靠传输。

  • 「ACK 机制」：用户发送的每一条信息都有一个 ack 回执，通过该回执知道当前信息是否发送成功。相应的在用户端页面，收到 ack 消息，会把消息的 loading 状态去掉，代表发送成功。
  • 「心跳机制」：每隔一段时间（7 秒钟），客户端会发送一个心跳包，服务端会返回一个心跳包，用于检测客户端与服务端的连接是否正常。在机器人对话中，超过 2 分钟无心跳响应，或在人工会话中，超过 5 分钟无心跳响应，便会清除该会话。

更多 IM 的基础设计，可以参考之前的文章：​​WebIM 原理解析​​

除了基本的 WebSocket 类，还需要一个业务逻辑类，关键方法如下

class KFClient {
  sendInitialInfo() {}  // 发送初始信息
  sendNormalMsg() {}  // 发送普通消息
  sendMsgesRead() {}  // 发送消息已读状态
  requestQueue() {}  // 用户请求排队
  sendEvaluation() {}  // 用户发送评价
  onIMMsg(callback) {}  // 收到消息事件注册
  onMsgAck(callback) {}  // 收到ack消息事件注册
  onKfWriting(callback) {}  // 收到IM客服正在输入消息
  ...
}

总结​

以上便是客服系统的主要流程，从用户进入到客服系统，到最后的会话结束，整个流程中，客服系统会通过机器人、人工客服、评价等多个环节，来完成用户的咨询。客服系统也会通过多种手段，来提升用户的体验，更好的服务用户。

前端下spanstylecolor开发客服通信

有关前端视角下的转转客服通信过程的更多相关文章

  1. ruby-on-rails - Rails 应用程序之间的通信 - 2

    我构建了两个需要相互通信和发送文件的Rails应用程序。例如，一个Rails应用程序会发送请求以查看其他应用程序数据库中的表。然后另一个应用程序将呈现该表的json并将其发回。我还希望一个应用程序将存储在其公共(public)目录中的文本文件发送到另一个应用程序的公共(public)目录。我从来没有做过这样的事情，所以我什至不知道从哪里开始。任何帮助，将不胜感激。谢谢! 最佳答案 无论Rails是什么，几乎所有Web应用程序都有您的要求，大多数现代Web应用程序都需要相互通信。但是有一个小小的理解需要你坚持下去，网站不应直接访问彼此

  2. MIMO-OFDM无线通信技术及MATLAB实现（1）无线信道：传播和衰落 - 2

     MIMO技术的优缺点优点通过下面三个增益来总体概括：阵列增益。阵列增益是指由于接收机通过对接收信号的相干合并而活得的平均SNR的提高。在发射机不知道信道信息的情况下，MIMO系统可以获得的阵列增益与接收天线数成正比复用增益。在采用空间复用方案的MIMO系统中，可以获得复用增益，即信道容量成倍增加。信道容量的增加与min(Nt,Nr)成正比分集增益。在采用空间分集方案的MIMO系统中，可以获得分集增益，即可靠性性能的改善。分集增益用独立衰落支路数来描述，即分集指数。在使用了空时编码的MIMO系统中，由于接收天线或发射天线之间的间距较远，可认为它们各自的大尺度衰落是相互独立的，因此分布式MIMO

  3. ruby - Ruby 中的 block 和过程 - 2

    我已经开始学习Ruby，我已经阅读了一些教程，甚至还买了一本书(“ProgrammingRuby1.9-ThePragmaticProgrammers'Guide”)，我遇到了一些以前从未见过的新东西使用我知道的任何其他语言(我是一名PHP网络开发人员)。block和过程。我想我明白它们是什么，但我不明白的是为什么它们如此伟大，以及我应该在何时何地使用它们。我到处都看到他们说block和过程是Ruby中的一个很棒的特性，但我不理解它们。这里有人能给像我这样的Ruby新手一些解释吗？ 最佳答案 block有很多好处。电梯演讲:bloc

  4. 智能客服 | 浅谈人工智能聊天机器人ChatGPT - 2

    2022年底，OpenAI的预训练模型ChatGPT给人工智能领域的爱好者和研究人员留下了深刻的印象和启发，他展现的惊人能力将人工智能的研究和应用热度推向高潮，网上也充斥着和ChatGPT的各种聊天，他可以作诗、写小说、写代码、讨论疫情问题等。下面就是一些他的神回复：人命关天的坑： 写歌，留给词作者的机会不多了。。。 回答人类怎么样面对人工智能： 什么是ChatGPT？借用网上的一段介绍，ChatGPT是由人工智能研究实验室OpenAI在2022年11月30日发布的全新聊天机器人模型，一款人工智能技术驱动的自然语言处理工具。它能够通过学习和理解人类的语言来进行对话，还能根据聊天的上下文进行互动

  5. ruby-on-rails - Rails 中 View 的解析过程 - 2

    rails中View的解析过程是怎样的？我对View中erb标记中原始html与ruby​​代码的解析顺序部分感兴趣。我认为这是View代码被解析并最终发送给请求者的顺序:Controller调用ViewView代码从上到下解析当Rails在解析过程中遇到erb标记时:rails解析它并将结果附加到解析的html(这包括erb标签引用助手)一旦整个View被解析，整体结果将发送给请求者这似乎并非如此。看来View代码会扫描任何erb片段并首先解析那些片段(包括对助手的引用)。之后，rails然后从上到下解析所有View代码并将结果发送给请求者。以这个View为例:#_form.html

  6. ruby-on-rails - 在 Rails 应用程序的前端获取实时日志 - 2

    在Rails3.x应用程序中，我正在使用net::ssh并向远程pc运行一些命令。我想向用户的浏览器显示实时日志。比如，如果两个命令在net中运行::ssh执行即echo"Hello",echo"Bye"被传递然后"Hello"应该在执行后立即显示在浏览器中。这是代码我在ruby​​onrails应用程序中使用ssh连接和运行命令Net::SSH.start(@servers['local'],@machine_name,:password=>@machine_pwd,:timeout=>30)do|ssh|ssh.open_channeldo|channel|channel.requ

  7. ruby - 如何在转换器插件中访问页面属性(YAML 前端) - 2

    我正在为Jekyll编写一个转换器插件，需要访问一些页眉(YAML前端)属性。只有内容被传递给主要的转换器方法，似乎无法访问上下文。例子:moduleJekyllclassUpcaseConverter关于如何在转换器插件中访问页眉数据有什么想法吗？ 最佳答案 基于Jekyll源代码，无法在转换器中检索YAML前端内容。根据您的情况，我看到了两种可行的解决方案。您的文件扩展名可以具有足够的描述性，以提供您本应包含在前言中的信息。看起来Converter插件的设计就是这么基本的。如果修改Jekyll是一个选项，您可以更改Convert

  8. Cesium源码解析一（terrain文件的加载、解析与渲染全过程梳理） - 2

    快速导航（持续更新中…）Cesium源码解析一（terrain文件的加载、解析与渲染全过程梳理）Cesium源码解析二（metadataAvailability的含义）Cesium源码解析三（metadata元数据拓展中行列号的分块规则解析）Cesium源码解析四（Quantized-Mesh(.terrain)格式文件在CesiumJS和UE中加载情况的对比）目录1.前言2.本篇的由来3.terrain文件的加载3.1更新环境3.2更新和执行渲染命令3.3数据优化3.4结束当前帧4.总结1.前言  目前市场上三维比较火的实现方案主要有两种，b/s的方案主要是Cesium，c/s的方案主要是u

  9. 转转测试环境docker化实践 - 2

        测试环境对于任何一个软件公司来讲，都是核心基础组件之一。转转的测试环境伴随着转转的发展也从单一的几套环境发展成现在的任意的docker动态环境+docker稳定环境环境体系。期间环境系统不断的演进，去适应转转集群扩张、新业务的扩展，走了一些弯路，但最终我们将系统升级到了我们认为的终极方案。下面我们介绍一下转转环境的演进和最终的解决方案。1测试环境演进1.1单体环境    转转在2017年成立之初，5台64G内存的机器，搭建5个完整的测试环境。就满足了转转的日常所需。一台分给开发，几台分给测试。通过沟通协调就能解决多分支并行开发下冲突问题。1.2动态环境+稳定环境    随着微服务化的进

  10. 1个串口用1根线实现多机半双工通信+开机控制电路 - 2

    功能需求：主机使用一个串口，与两个从机进行双向通信，主机向从机发送数据，从机能够返回数据，由于结构限制，主机与从机之间只有3根线（电源、地、数据线），并且从机上没有设物理的电源开关，需要通过与主机连接的数据线来控制开机，总结如下：1、数据线只有1根2、能够双向通信3、主机能够控制从机开机4、主机可以单独向1个从机发数据，也可以同时向两个从机发送数据根据需求，设计出如下电路：工作原理分析：VCC_24V_IN、GND、LINE_L（LINE_R）三根线接线连接到从机，电源开启电路是从机内部的电源控制。开机的逻辑：*主机先上电，LINE_L因为主机的R1上拉而有高电平，使Q6导通，Q5的G极电压被

随机推荐