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

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

客服通信的整体架构

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

「入口管理」：不同的客服入口，比如商品详情页、订单详情页、客服中心等，都会相应的机器人或者客服来处理用户的咨询。入口管理用来配置客服入口的不同参数，用以路由到不同的客服服务。
「用户服务」：用户服务主要包括了机器人会话、人工会话、用户评价等。机器人会话是指用户与智能机器人聊天，用于快速回复用户一些基础问题。人工会话是指用户与客服的对话，通常是处理一些较复杂的咨询。无论是机器人还是人工，用户都可以对服务进行评价，这也是衡量客服服务水平的一个重要指标。
「客服服务」：客服服务主要包括机器人管理和客服工作台。机器人管理是指客服人员对机器人的配置，比如业务线和订单识别规则、机器人的回复、相似问题的匹配逻辑等。客服工作台是指客服人员在工作时操作的界面，也是客服系统中最重要的一个系统，包含了客服与用户沟通的 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 能力、联系人管理、发送不同类型消息等功能。右侧是客服的工作台，包括了查询用户的相关订单、信息等。以及很重要的创建客服工单的能力。

排队机制

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

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

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

评价

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

客服邀请评价
用户主动评价
结束会话时评价
二次进线时评价
离线评价
机器人评价

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

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客服正在输入消息...
}