客服系統中的2個梗：人工與機器人
近幾天正在調研與落地客服系統，說到客服系統相信每個朋友心理的第一反應是親切的客服聲音。
客服系統所面臨的使用者，也就是我們說的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是產品體系的標準名稱。但客戶或使用者通過輸入法打出的是凱文，因此可以作為相似詞匹配。
02
客服訊息留痕與質檢
客服系統的建立，除了提高企業的客服效率以外，最重要的一項功能就是可以將客服的訊息進行流痕，不管是對於政府的監管還是企業的自查，都極具重要性。
尤其是對於金融行業，會話留痕不僅僅是企業自身的自查，也是證監會對於企業的一個抽查。一旦不合規，或隨機質檢出現問題，那麼企業就可能倒閉。
這裡，首先要建立一個質檢列表，質檢列表以會話為物件進行排練，將該會話的分類、接待客服、當前問題的狀態、滿意度、時間長度、質檢狀態等相關屬性進行羅列。
【質檢列表】
在這個產品設計中，我點選相應的會話，可以彈出該會話的詳情，如聊天記錄、使用者資訊，根據聊天記錄超級管理員可以對質檢進行評分，並且在這套客服系統中，可以設定一些緊急項，並且對於質檢可以進行評語，方便下級客服知道其原因和理由。
【質檢詳情】
03
工單建立
客服系統除開以上的模組，那麼最重要的就是反饋問題，從產品上可以反饋產品的功能使用問題或一些BUG，從業務上可以反饋產品業務是否能夠被使用者接受。
作為與使用者接觸的第一線，客服往往需要處理或收集來自公司業務或產品的各種問題。這個時候作為客服部門不能處理的問題，就需要相應的技術部門或其他部門進行共同解決。
由此會有工單模組，這裡的工單中心，以工單的狀態分為：新建工單、受理工單、完成的工單、回覆的工單、沒有處理的工單...
【工單中心】
工單也是以列表的形式進行展現。工單客服可以進行建立，圍繞上面的欄位，相應的欄位內容需要被填寫，工單填寫的越完整，其下一層處理問題的部門將會更加清楚。因此如何方便客服人員去描述工單，以及對工單的指派是工單中心的一個難點
【工單的建立】
並且工單的搜尋並不像我們日常中搜尋會話訊息，因為工單所處的狀態多種，其工單的搜尋以工單的狀態來進行篩選分類，這樣才會大大工單的查詢效率。
【工單的搜尋】
當然以上的搜尋欄位可以根據自身客服業務來進行選取或增加，如果你的客服人員沒有分組，那麼受理組這一選項欄位就不用存在。還是那句話，客服系統是基於公司客服體系服務的，時刻依靠公司業務。
但需要注意的是，每個工單都有優先順序，這裡的優先順序可以作為需求的優先順序理解，但從客服人員來說，其優先順序的判別一定有一套基於公司產品業務的判別方式，如購物平臺：金錢丟失》差評；工單解決一定要有權重。保重資源的合理安排，優先解決緊急的問題。
04
資料包表
如果以上模組是提升客服效率並且保證公司服務品質的直接功能模組，那麼資料包表就是整體客服系統的檢測結果，可以從資料上看當前使用者的問題量與客服的問題處理量，讓管理者及時知道當前公司的產品情況和業務情況。
但需要值得至於的是，不同於日常的資料分享平臺如友盟等，其客服的資料是以24小時進行區分。
【資料包表】
資料根據接入的渠道來定，有的可能只有接入APP，有的可能只有接入WEB，或微信，因此以上的資料需要公司客服體系是否願意接受其資料的評判。因此資料的展現欄位選取一部分也可。
不僅可以瞭解到資料的當前集合情況，也可以瞭解到每個客服的資料情況，有助於很快定位客服人員的工作情況，幫助企業定位KPI
另外對於資料的篩選，我們可以從使用者的渠道和回覆的物件進行區分，由此除開給予資料主頁，我們也可以做一些詳細的資料記錄。
【詳細的資料記錄】
可以進行客服、留言、機器人、工單資料、訂單績效進行篩選，但這裡要說明訂單績效解釋為：該訂單服務後直接生成相應的企業效益，這裡需要與CRM系統打通。
所以客服系統的連結往往會存在以下情況：
當然具體的要根據企業客服部門的劃分和業務的情況，還是那句話，緊緊圍繞客服業務體系。
以上客服系統原型基於網易七魚，作為競品調研而進行採取。
這篇文章讀完後，你還可以瞭解的客服系統:
七陌 、合力億捷...
我已經堅持產品分享1年，最近更新：
UGC與演算法|2017行業產品FEED流產品設計，我如何落地UGC資訊流？
案例總結，使用者體系6個難點 |如何落地，利用資料、函式模型使用者成長體系
騰訊公益贏了還是人性的本質？|“小朋友”的公益畫冊刷爆朋友圈背後的產品邏輯
繼續更新中......
2017年，讓我們繼續前進！
與KEVIN一起在產品中學習交流QQ群：257051609
我的個人微信574319420，歡迎新增請修改備註