史上最詳細的客服系統產品落地

客服系統所面臨的用戶，也就是我們說的C端。在日常生活中，方方面面都有存在。

如購物的淘寶購物系統、去哪兒人工客服、美團的人工、10086的呼叫中心。

【淘寶客服】

【呼叫中心客服】

客服的重要性是企業提供服務的重要一環。存在於產品的售前、使用、售後，客服系統的產品設計，明顯是屬於一款後端產品。根據最近的產品調研與設計，其難點在於：

1.當前企業的客服業務

2.FAQ的梳理

3.企業客服管理體系

4.企業資源

【當前客服系統中鏈接的2個點】

首先要說明客服系統絕對不是為了讓人工成本變為0，而是更高效、成本更低的解決企業需要提供的客服服務。既能夠讓用戶獲得更好的體驗如：解決時間、問題解決徹底，又能夠讓企業知道其產品的不足和產品的優勢。

01客服系統的幾個標準模塊

這裡的標準模塊的意識是表面客服系統中，在市面上都會存在這個功能或模塊，也是企業客服所必有的需求。當然客服系統是需要強烈依靠在公司業務體系上，如：美團的客服管理和分答的客服管理，其業務的不同，就導致客服的IM不同

【分答的客服模塊】

【美團的客服入口】

以下，我梳理了當前客服系統中會存在的幾個模塊

除開呼叫中心，以及客服IM（也就是客服會話系統），客服系統的模塊就以上為主。客服系統的這幾個標準模塊，我認為在落地中，其難點就在於知識庫的建立，客服留痕的檢測、數據的匯總、工單建立，以下我將圍繞這3個模塊來分享我是如何落地這裡難點。

02知識庫

說到知識庫這個名稱，這裡可能在其他客服系統中，可以成為FAQ庫或問題集合庫。

這裡的知識庫我們首先要從內容和FAQ進行分類。內容包含FAQ，但我這裡說的內容可能是一篇PR或介紹文檔。

當產品或活動中需要一些產品介紹文案或活動文案，那麼這裡叫做內容

以上是知識庫的建立，那麼在後台中，我們首先需要設計知識庫中2個功能

1.內容的發布和目錄

2.問題與內容的列

以上就是知識庫中，對於內容和問題的管理。首先我們需要以報表的形式，統計當前人工創建的問題，為什麼要創建人工的問題？

在這裡我們首先要注意的是，問題的答案有一個2面性的說法：

1.對客服同事的問題答案描述

2.對用戶的問題答案描述

另外說一點，關於FAQ的整理，一定要對問題進行歸類，在客服系統中可能用戶問你的問題雖然上千上萬，但是終究其問題的類型可以分：諮詢、使用問題、售後問題，等類似此類的分類。

當出現新的功能後，我們就的新建相關FAQ，針對新功能的功能點作出問題分類，當問題分類嚴重傾斜，集中在某一分類；那可能就是產品設計或UI設計的問題，也方便我們產品人員進行迭代。

FAQ的關聯建立

這裡說到FAQ的關聯建立，我以下面的圖來說明

FAQ關聯，我們首先需要建立基於產品業務的一些關鍵詞，這些關鍵字有助於機器回答中，自動回復。

另外在建立問題庫的同時，需要注意將問題間接，就如圖中：優惠券怎麼用？類似這樣的。方便進行相識問題的匹配。

機器人通過分詞或自然語言處理，將相似問題的答案返回給用戶，但現在客服系統中大多數還是以關鍵詞匹配也就是分詞的方式進行匹配問題，採用自然語言處理的客服系統還相對較少。

【添加問題DEMO】

這個欄位給大家推薦一些常用的客服系統去選取，因為客服系統主要是輔佐當前自己的客服業務。因此如果你的業務並不複雜，每天的提問就100個左右的用戶。那麼機器人這一塊先不做。花費大量的時間與開發資源去做這套系統，但實際上目前功能不能使用。

【相似詞庫】

相似詞庫的採集是基於日常中的積累，在系統建立後，可以導入用戶常用的相關詞語來表示的標準詞。

比如：KEVIN是產品體系的標準名稱。但客戶或用戶通過輸入法打出的是凱文，因此可以作為相似詞匹配。

03客服消息留痕與質檢

客服系統的建立，除了提高企業的客服效率以外，最重要的一項功能就是可以將客服的消息進行流痕，不管是對於政府的監管還是企業的自查，都極具重要性。

尤其是對於金融行業，會話留痕不僅僅是企業自身的自查，也是證監會對於企業的一個抽查。一旦不合規，或隨機質檢出現問題，那麼企業就可能倒閉。

這裡，首先要建立一個質檢列表，質檢列表以會話為對象進行排練，將該會話的分類、接待客服、當前問題的狀態、滿意度、時間長度、質檢狀態等相關屬性進行羅列。

【質檢列表】

在這個產品設計中，我點擊相應的會話，可以彈出該會話的詳情，如聊天記錄、用戶信息，根據聊天記錄超級管理員可以對質檢進行評分，並且在這套客服系統中，可以設置一些緊急項，並且對於質檢可以進行評語，方便下級客服知道其原因和理由。

【質檢詳情】

04工單建立

客服系統除開以上的模塊，那麼最重要的就是反饋問題，從產品上可以反饋產品的功能使用問題或一些BUG，從業務上可以反饋產品業務是否能夠被用戶接受。

作為與用戶接觸的第一線，客服往往需要處理或收集來自公司業務或產品的各種問題。這個時候作為客服部門不能處理的問題，就需要相應的技術部門或其他部門進行共同解決。

由此會有工單模塊，這裡的工單中心，以工單的狀態分為：新建工單、受理工單、完成的工單、回復的工單、沒有處理的工單...

【工單中心】

工單也是以列表的形式進行展現。工單客服可以進行創建，圍繞上面的欄位，相應的欄位內容需要被填寫，工單填寫的越完整，其下一層處理問題的部門將會更加清楚。因此如何方便客服人員去描述工單，以及對工單的指派是工單中心的一個難點

【工單的建立】

並且工單的搜索並不像我們日常中搜索會話消息，因為工單所處的狀態多種，其工單的搜索以工單的狀態來進行篩選分類，這樣才會大大工單的查找效率。

【工單的搜索】

當然以上的搜索欄位可以根據自身客服業務來進行選取或增加，如果你的客服人員沒有分組，那麼受理組這一選項欄位就不用存在。還是那句話，客服系統是基於公司客服體系服務的，時刻依靠公司業務。

但需要注意的是，每個工單都有優先順序，這裡的優先順序可以作為需求的優先順序理解，但從客服人員來說，其優先順序的判別一定有一套基於公司產品業務的判別方式，如購物平台：金錢丟失》差評；工單解決一定要有權重。保重資源的合理安排，優先解決緊急的問題。

05數據報表

如果以上模塊是提升客服效率並且保證公司服務品質的直接功能模塊，那麼數據報表就是整體客服系統的檢測結果，可以從數據上看當前用戶的問題量與客服的問題處理量，讓管理者及時知道當前公司的產品情況和業務情況。

但需要值得至於的是，不同於日常的數據分享平台如友盟等，其客服的數據是以24小時進行區分。

【數據報表】

數據根據接入的渠道來定，有的可能只有接入APP，有的可能只有接入WEB，或微信，因此以上的數據需要公司客服體系是否願意接受其數據的評判。因此數據的展現欄位選取一部分也可。

不僅可以了解到數據的當前集合情況，也可以了解到每個客服的數據情況，有助於很快定位客服人員的工作情況，幫助企業定位KPI

另外對於數據的篩選，我們可以從用戶的渠道和回復的對象進行區分，由此除開給予數據主頁，我們也可以做一些詳細的數據記錄。

【詳細的數據記錄】

可以進行客服、留言、機器人、工單數據、訂單績效進行篩選，但這裡要說明訂單績效解釋為：該訂單服務後直接生成相應的企業效益，這裡需要與CRM系統打通。

所以客服系統的鏈接往往會存在以下情況：

當然具體的要根據企業客服部門的劃分和業務的情況，還是那句話，緊緊圍繞客服業務體系。

以上客服系統原型基於網易七魚，作為競品調研而進行採取。

這篇文章讀完後，你還可以了解的客服系統:

七陌 、合力億捷、udesk、網易七魚