當你在轉轉咨詢客服時，你的問題是如何發(fā)送到客服的？客服又是如何快速精準回答的呢？這篇文章將從前端的視角，帶你了解轉轉客服通信的整體流程。

客服通信的整體架構?

首先看一看用戶與客服通信的整體架構，如下圖

• 「入口管理」：不同的客服入口，比如商品詳情頁、訂單詳情頁、客服中心等，都會相應的機器人或者客服來處理用戶的咨詢。入口管理用來配置客服入口的不同參數(shù)，用以路由到不同的客服服務。
• 「用戶服務」：用戶服務主要包括了機器人會話、人工會話、用戶評價等。機器人會話是指用戶與智能機器人聊天，用于快速回復用戶一些基礎問題。人工會話是指用戶與客服的對話，通常是處理一些較復雜的咨詢。無論是機器人還是人工，用戶都可以對服務進行評價，這也是衡量客服服務水平的一個重要指標。
• 「客服服務」：客服服務主要包括機器人管理和客服工作臺。機器人管理是指客服人員對機器人的配置，比如業(yè)務線和訂單識別規(guī)則、機器人的回復、相似問題的匹配邏輯等?？头ぷ髋_是指客服人員在工作時操作的界面，也是客服系統(tǒng)中最重要的一個系統(tǒng)，包含了客服與用戶溝通的 IM、用戶進線信息展示、工單的創(chuàng)建與管理等。
• 「知識庫」：客服知識庫是整個客服最底層的基建，包含了客服所有需要的知識，像機器人的回復、客服的回復等。當有足夠的知識時，對機器人和客服，快速精準的回答用戶的問題，都有很大的幫助。

會話的基礎架構

客服會話的基礎結構如圖

每次用戶進線后，會創(chuàng)建一個用戶會話，該會話也可以叫大會話。用戶可能先進入機器人模式下咨詢，然后再進入人工客服，也可能直接進入人工客服。但每個環(huán)節(jié)會生成的新的會話，這種會話也叫子會話。大會話和小會話的關系是一對多的關系，即一個大會話可以包含多個小會話。當用戶結束服務或會話超時關閉時，那么整個會話就算結束。

消息協(xié)議

在客服與用戶的對話中，使用 WebSocket 進行數(shù)據(jù)通信。格式上，采用??JSON??格式，可以兼顧可讀性和傳輸效率。消息的格式大體如下

{
  "type": 73,  // 消息類型
  "uid": "",  // 用戶id
  "content": {
    "msgType": 1,  // 消息展示類型
    "data": {
      "sendTime": 1680095134107,  // 時間戳
      "text": "你好",
    }
  }
}

上面是一個最簡單的消息結構，其中??type??表示消息的類型，IM 會話中存在多種不同類型的消息，如下圖

不同類型的消息，通過 WS 傳輸，用戶側與客服側執(zhí)行相應的邏輯。

機器人會話?

當用戶進入客服會話時，通常會先進入機器人會話，機器人會話是指用戶與智能機器人聊天，用于快速回復用戶一些基礎問題。機器人會話的整體流程如下圖

用戶咨詢后，首先會根據(jù)用戶鏈接中不同的參數(shù)，匹配到不同的機器人或行為，這里面包括了 ??機器人ID???、??商品ID???、??訂單ID??等。然后根據(jù)用戶的咨詢，匹配到相應的答案，并發(fā)送給用戶。

機器人配置

機器人需要根據(jù)用戶進入的不同渠道，展示不同的信息或者話術。當用戶攜帶商品 ID 時，會先查詢商品信息，如果該商品用戶已購買，那么會自動匹配到訂單的邏輯。如果該商品未購買，則展示商品的信息卡片，方便用戶查看咨詢的商品。如果用戶攜帶訂單 ID，那么會直接匹配到訂單的邏輯，展示訂單的信息卡片，同時還包括物流售后等信息。如果用戶沒有攜帶任何參數(shù)，那么會展示默認的機器人回復，以及一些推薦的商品或訂單信息。

機器人中另外一個模塊便是 ??NLP??? 能力，通過 ??NLP??? 能力，機器人將用戶的輸入轉換成對應的標準問，然后匹配到相應的答案。這其中，可能需要與用戶對話多次，根據(jù)用戶提供信息才能匹配到最終答案。比如用戶輸入 ??我想退貨???，那么會匹配到 ??我想退貨?? 這個問題，但是這個問題在不同場景下有不同的答案，比如訂單的狀態(tài)不同，回復的內(nèi)容自然也就不同，所以還需要用戶提供訂單信息。

人工會話?

當機器人無法解決用戶的咨詢時，會轉接到人工客服。人工客服會在客服工作臺完成與用戶的對話，整體工作臺分為兩個部分。左側區(qū)域是客服的 IM 會話區(qū)域，包括了 IM 能力、聯(lián)系人管理、發(fā)送不同類型消息等功能。右側是客服的工作臺，包括了查詢用戶的相關訂單、信息等。以及很重要的創(chuàng)建客服工單的能力。

排隊機制

在進入人工客服時，如果當前客服人員都在忙碌中，那么會進入排隊隊列，等待客服人員空閑后，再進入會話。排隊的策略會由多種條件決定，主要有

1. 客服的熟練度
2. 當前已經(jīng)接入的會話數(shù)
3. 進入排隊的時間

通過這三個條件，來決定排隊的順序，優(yōu)先接入熟練度高的客服，同時也會考慮到客服的負載情況，避免客服過于繁忙。

評價?

在完成會話后，針對這次會話，用戶可以進行評價。評價主要有以下幾種形式

1. 客服邀請評價
2. 用戶主動評價
3. 結束會話時評價
4. 二次進線時評價
5. 離線評價
6. 機器人評價

不同形式的評價，觸發(fā)的時機不同，評價的內(nèi)容也不同。但整體來看，都會對本次服務進行打分，包括滿意、一般和不滿意。

IM 的前端設計?

在 IM 的前端機制中，主要包含了 ACK 機制、心跳機制、重連機制、消息重發(fā)機制等。這些機制都是為了保證消息的可靠性，即使在網(wǎng)絡不穩(wěn)定的情況下，也能保證消息的可靠傳輸。

• 「ACK 機制」：用戶發(fā)送的每一條信息都有一個 ack 回執(zhí)，通過該回執(zhí)知道當前信息是否發(fā)送成功。相應的在用戶端頁面，收到 ack 消息，會把消息的 loading 狀態(tài)去掉，代表發(fā)送成功。
• 「心跳機制」：每隔一段時間（7 秒鐘），客戶端會發(fā)送一個心跳包，服務端會返回一個心跳包，用于檢測客戶端與服務端的連接是否正常。在機器人對話中，超過 2 分鐘無心跳響應，或在人工會話中，超過 5 分鐘無心跳響應，便會清除該會話。

更多 IM 的基礎設計，可以參考之前的文章：??WebIM 原理解析??

除了基本的 WebSocket 類，還需要一個業(yè)務邏輯類，關鍵方法如下

class KFClient {
  sendInitialInfo() {}  // 發(fā)送初始信息
  sendNormalMsg() {}  // 發(fā)送普通消息
  sendMsgesRead() {}  // 發(fā)送消息已讀狀態(tài)
  requestQueue() {}  // 用戶請求排隊
  sendEvaluation() {}  // 用戶發(fā)送評價
  onIMMsg(callback) {}  // 收到消息事件注冊
  onMsgAck(callback) {}  // 收到ack消息事件注冊
  onKfWriting(callback) {}  // 收到IM客服正在輸入消息
  ...
}

總結?

以上便是客服系統(tǒng)的主要流程，從用戶進入到客服系統(tǒng)，到最后的會話結束，整個流程中，客服系統(tǒng)會通過機器人、人工客服、評價等多個環(huán)節(jié)，來完成用戶的咨詢?？头到y(tǒng)也會通過多種手段，來提升用戶的體驗，更好的服務用戶。