其實，我是一個客服（終篇）

有知乎的網友看到了我三年前的文章 其實，我是一個客服 ，已經過去太久，回復完他的評論，突然有了更多想要去說的話，正好將此篇文章作為已經離開的這個崗位的總結，隨便聊一聊，僅供參考。

工作背景：一款工具性的產品客服；客服只是我日常的一半工作；不涉及較重的呼叫中心業務。

客服工作是一個流程化的任務

做客服工作的時候有一條原則，即，如果一項任務沒有流程，就需要創造流程。流程包含處理的步驟和決策的原則。比如，其實日常用戶所遇的90%的問題實際都是已知問題，那麼之前所沉澱的案例就可以總結為固定的流程，並設置模板，盡量以流程來減少做決策的部分。

由於客服人員每天都會遇到大量的重複性的工單，如果缺少固定的流程，密集的決策會放大可能的人為性的錯誤，甚至影響處理的效率。一個只需要模板回復的用戶郵件，與一個需要斟酌每一個字來回復的郵件相比，所需時間相差甚遠。

「磨刀不誤砍柴工」

如果涉及到需要決策的部分，可以靠提前設定原則來規避。最為基本的，客服至少需要知道在回復一個用戶時需要了解的基本要素，或者不同的渠道應該以什麼底線和什麼針對性的方式來回復，比如哪些事情必須做，哪些事情不能做，盡量以清單的形式反覆打磨來呈現。

處理的步驟和決策的原則都需要在培訓或者日常的會議中反覆強調，尤其是遇到了合適的案例，可以借題來發揮，最終能夠完成意識上的統一。這裡，文字化所有的流程是一個必要的開始。口徑不統一，流程混亂，是用戶最不願意看到的。

從更高的角度上來講，我的日常任務就是要確保整個客服系統的穩定運行，從基礎框架的搭建（硬體），到客服的專業服務意識（軟體）。在之前的工作中，我會在電腦桌面放上一個整體的思維導圖，以此映射整個客服系統，在每一次的討論中，反覆修正。

擴展客戶服務的邊界，從用戶找到我們之前就開始

客服工作確實是被動的，等待用戶與我們聯繫，甚至有時是在等待產品BUG的出現。不過，這種被動的情形下，可以更為主動的出擊。在2017年的一次用戶調研中，除了打電話以外的方式中，搜索仍然是排名第一的。那麼對於搜索內容的干預就是重要但不緊急的第二象限工作。我們可以從日常的數據中挖出最為常見的問題Top 10，然後以用戶的視角嘗試在百度搜索，將這些問題的解決方法放在用戶在搜索中可以看到的位置。

更為主動的態度始於我們以用戶接觸我們的途徑來思考，他們會在百度知道和知乎提問，甚至一部分用戶是在應用商店看到我們。這些所有可以涉及的地方，從成本上考慮之後，我們既可以直接進行內容干預，也可以增設聯繫的途徑，避免用戶情緒無處宣洩。

搭建自己的論壇或者使用第三方論壇服務也是在讓用戶找到我們之前，讓用戶以自助或者互助的方式解決問題，減少用戶到達客服服務這一步的需要，這個似乎與上一段有所悖論，實際上我們既想讓用戶找到我們，又不想讓用戶找到我們，這兩個分別是從滿意度和成本來考慮的，這兩個角度客服工作的很長時間裡會一直角逐著。

客戶服務的邊界也可以擴展到產品開發上，比如軟體本身有自檢功能，在常見問題發生時即時顯示在發生問題的地方。

最為重要的客服思維：閉環的原則

這是一個最為簡單但最為有效的原則，一句話概括就是「問題從哪裡來，最終還是需要回到哪裡去」。

• 用戶提出了問題，一部分我們可以立刻解決，一部分，我們需要詢問更多的；
• 在詢問了足夠的信息之後，一部分可以立刻解決，一部分需要與技術人員溝通；
• 在溝通之後，問題得到確認，一部分可以立刻解決，一部分需要等待產品更新，還有一部分無法解決
• 產品更新之後，需要儘可能的通知到這些用戶，用戶滿意度和忠誠度的提升就源於這種閉環的負責到底的態度
• 無法解決的問題，也需要從態度上和必要的原因上給出恰當的回復

所有問題的解決必須是問題最終回到了用戶那裡，只是問題已經變成了各種各樣的答案，哪怕這個事情已經過去了很久。

實現SLA承諾，靠系統來規避人的惰性

每一家產品的客服都會給出解決問題的承諾，比如免費用戶1個工作日、VIP用戶工作日內30分鐘。對於如何實現這類的承諾，僅靠團隊人員的自覺甚至規章制度的懲罰都是不夠的。就像區塊鏈從技術上解決交易的信任問題是以不信任任何人來作為基礎設定的。那麼從系統上思考如何實現SLA承諾，也需要以不相信任何團隊人員為出發點，當然，這只是解決問題的思考假設。

這個時候，平台的統一性尤為重要，用戶有各種各樣聯繫我們的方式，但是通過客戶服務平台，可以匯總所有渠道的內容和數據，這樣就完成了系統化的第一步。市面上有很多客戶服務的工具可以實現這樣的系統化，不過，基本的思路有兩個角度，從客服的角度，有一個經過系統判定和調試的「隊列」可以讓客服人員按照順序從容不迫的處理，隊列的順序與服務承諾直接相關，甚至用顏色的深淺來標明優先順序和狀態；從管理的角度，有一個實時顯示當前所需處理的任務的狀態頁面，具體的顆粒度以實際情況而定。

漏斗原理，決定滿意度和成本的考量

之前有提到，客戶服務就是在成本和滿意度之間進行平衡和考量，每次在說明這個看法的時候，我都會舉一個極端的例子。假如我們精力無限、人員絕對充足，最理想的解決問題的方式是站在用戶的旁邊手把手代為解決，但是，這永遠無法達到。

為了完成成本和滿意度之間的平衡，我們需要首先將用戶聯繫我們的整個路徑繪製出來（以最長路徑為示例），然後以「漏斗」原理來輔助決策，最後達成一個設定的指標。其中，每一環的過濾取決於上一步解決問題的有效度以及當前這一步獲取答案的便捷度，最好的答案是出現在發生問題時候的答案。

之前工作中達成的指標有些缺陷，由於數據支撐的缺乏，我只能關注最後單次回復解決問題的比例。如果每一步數據跟蹤到位的話，可以更為有效控制漏斗的過濾，確保以低成本完成較高的滿意度。

數據的挖掘，找出滿意度的黑洞

數據的挖掘依然在平台統一的前提下，匯總的數據可以以更細的維度來挖掘出有效的信息來。比如，之前在看到滿意度下滑的時候，分別以問題分類來查看滿意度的數據，之後在問題分類中再以分屬不同的平台來查看滿意度，最終可以找到較大程度影響滿意度的因素，當顆粒度足夠小的時候，還可便覽屬於此分類的用戶反饋來查看具體可見的問題。這裡只是一個極為簡單的例子，真正的數據挖掘還會有更大的效用，這個等我經驗積累足夠之後再單獨寫一篇總結。

把客服工作放到整個客戶購買流程中去理解

公司本身的目標仍然是利益最大化，以滿意度來衡量客服的工作只是其中一個角度，我們可以在產品購買的整個流程中去思考，尤其是針對To B的產品。放到整個流程是為了從利潤最大化的情況下，再決定客戶服務需要關注的因素，比如針對大客戶和小客戶的服務區別等等。

維護與開發團隊的溝通渠道

產品畢竟還是開發團隊的作品，如果要主動應對產品方面的問題，需要與開發團隊有一個積極的溝通渠道，而他們也會很在意用戶的反饋。從產品發布的角度來看，發布前的產品溝通可以讓客服團隊提前為已有的問題做好準備，尤其是一些已知的問題。從用戶反饋的角度來看，一份好的用戶反饋報告，可以讓開發團隊從直觀上看到用戶關注和吐槽的重點。為了溝通的方便，部門之間的會議可以考慮周期化。

另外，好的溝通氛圍可以幫助解決一些極端情況，尤其是重大產品BUG的出現。在我工作的那段時間裡，不管是運維還是產品都出現過這類緊急問題，只有第一時間與負責的部門直接溝通，才能有機會最小化問題的影響。

類似的道理也可以套用到其他更多的部門，客服作為與用戶接觸的一線，任何與公司相關且會引起用戶反映的活動都需要客服來處理，也都需要有有效的溝通渠道。

定期的客服服務調研，為優化提供支撐

從早期微信客服渠道僅作為噱頭開始，不知不覺，微信已經屬於很多公司基礎性的渠道之一。2017年做過的那次客服調研發現，微信渠道接受度已經一定程度上高於電話，加上微博本身十分混亂的介面，本來能成為勁敵之一的社交媒體渠道，現在微信佔了大頭。這也意味著，在優化客戶服務時，在微信上需要投入更多的精力。

在之前與業內人士交流的時候發現，越來越多的人不再接受長篇大論的郵件的處理，更喜歡短句的對話，一問一答，俗稱「Conversation is the future of Customer Support」。在用戶習慣逐步隨著潮流變化的時候，可以通過各種調研形式來逐步輔助自己服務的優化。

向其他企業學習，三人之行必有我師

一直覺得，客服是交流甚少的行業，在我從事工作的三四年中，除了在推銷客戶服務工具的銷售員那裡，在其他地方几乎聽不到同行的聲音。但是每一家企業呈現的客服都有著自己的思路，我們仍然應該虛心查看同行的作品，可以嘗試作為用戶逐個體驗，或者用抓包的形式找到服務背後所應用的工具名稱，甚至直接勾搭客服找到幕後工作者。我自己嘗試了很多互聯網產品的客服，並收為案例來研究。

注意客服團隊的穩定，一個負能量爆棚的部門

每天，都有無數個用戶從各個渠道與我們聯繫，我們可以聽到各種抱怨、指責甚至謾罵，當然也有一部分誇獎，但是，負面情緒的人更願意發出聲音。我一直覺得，客服其實是最弱勢的，當憤怒的用戶到來時，他們是無法還嘴的，否則用戶抱怨的方向就從產品變成了人身攻擊。換位思考來看，面對那些無還手之力的客服，恰恰可以看出一個人的素質，不過，這都是題外話。回到客服本身，面對如此多的負能量，確實需要及時溝通和紓解。

首先，雖然我們鼓勵換位思考，但是，如果客服無法將用戶對產品的指責與對服務本身的指責區分開，負能量就會迅速積累甚至過激反應，這是日常需要達成的重要共識。其次，團隊內部定期的1對1對話需要堅決執行，可以幫助及時了解團隊客服的工作感受和問題。

未能完成的一點，用戶反饋的語義分析

現如今，用戶發聲的渠道太多了，雖然我們可以在產品內做引導，讓其進入我們的反饋系統，但是，仍然有很多用戶會去微博、應用商店甚至知乎上抱怨，而且這種抱怨很多是不需要直接應對的，重在收集。對於這類自發聲的用戶反饋，希望可以在未來通過爬蟲或者其他服務將這些反饋抓取到資料庫里，再通過語義分析和清洗，以標籤來分類，最後可以得出更為飽滿且直觀的反饋數據，甚至可以及時主動察覺產品的新問題。

目前已經看到國外有幾家提供這類服務的公司，不過，暫時還沒有看到國內的。

以上的總結較為粗糙，每個部分其實都可以展開再細分挖掘。不過，時間有限，希望現有的這些可以偶爾幫助到從事客服工作的你們。