其實，我是一個客服

和之前的一些文章一樣，這也是一篇順便寫的隨想，因為要給新加入的同事做入門引導，在整理的過程中突然有了寫下工作總結的興緻，其實，那麼久了，我一直就是一個客服。

說起來，大多數人對於「客服」的理解與我們自己對於「客服」的感知有很大不同，這與用戶遇到的問題和我們自己對於其問題的不同理解有著異曲同工之妙，屬於同一印象在不同腦海里畫面的直接衝突。我不能和家裡人介紹我的工作是客服，因為他們腦海里固有的客服認知足以抹殺長久以來培養起的那份驕傲，「我家娃兒在外就是個搞客服的，太不爭氣了！」。

不過，先撇開這些顧慮，作為一個互聯網產品的客服人員，首要過關的依然是對產品足夠的熟悉和足夠清晰的邏輯思維能力。前者是為了保持對問題發掘的敏感性以及綜合判斷問題的能力，後者是為了在混沌的狀態下理出一條思考的路線，一步一步解決問題。

如何精準地理解一個問題——很少有用戶知道發生了什麼

用戶最擅長的僅僅是描述一個簡單並對問題的解決沒有多少幫助的當前狀態，大多數情況下可能只是情緒的表達，所以，我們首先是一個心理輔導師，然後才是客服，而且以用戶對於產品的理解，很少有能獨立講清楚自己問題的，在我們認真傾聽之後，「提出更好的問題」會成為下一個大的挑戰。這個時候我們應該會想起一個很多人知道的「5W1H」分析法，什麼時間什麼人在什麼地方使用什麼方法做了什麼事情，為什麼？

這裡推薦《學會提問》這本書，原因如書名。

另外，即使在用戶精準回復問題之後，為了減少轉述過程中的信息失真，越能還原問題的影像會越有用，這個時候，效果：現場觀察錯誤>視頻錄製問題/遠程查看>截圖與活動日誌>文字或者語音描述。

如何判定與解決問題——重啟電腦真的可以解決一半的問題嗎？

「重啟電腦可以解決一半以上的問題」，這個說法確實被誇張了，但這恰恰是為了表達一種客服的基本處理思路。很多軟體的問題僅僅是電腦或者移動設備運行過程的一個故障，退出重新打開或者直接重啟設備可以排除這樣偶然運行故障的干擾，避免投入過多的精力，這個也可以作為我們日常使用軟體的「必備技能」。

與重啟電腦類似的必備操作是，務必確保軟體和系統版本為最新，既可以減少舊版本Bug的干擾，也可以在與程序員溝通的時候不讓他們抓著舊版本這個變數不放。

而當我們做完以上的預設操作並精準理解用戶的問題之後，後面的步驟更類似於大學裡的論文，客服要提出一種或者多種假設，想想你經常收到的那句「俗氣」的客服語句就可以感受到，「根據您的反饋，我們猜測可能的問題是······」，而這裡提出假設的精準度與處理問題的經驗和對產品的了解程度正相關。

每每提到「經驗」二字，我就想起大學裡管理學課程的兩派，科學管理派和經驗管理派，「經驗」是一種複雜的積累和思考方式，作為一個客服，可以嘗試將重要的問題Case作為一個個案例認真分析，像經驗派那樣嘗試分析並整理出判定問題的決策圖，決策圖就可以變成一種其他人可以遵循的科學判定方式，衍生成一種「科學」，這也可以間接說明科學管理派和經驗管理派並不是對立的，走題了。

當提出假設之後，我們就需要通過與用戶的互動來獲得更多信息並驗證我們的假設，然後就可以給出已有的解決方案。

如何Debug一個未知的問題——問題是絕逼可以重現的

處理問題的原則：

1. 問題是可以重現的

2. 如果問題不能重現，請參考第一條

我以非技術人員的角度大膽總結，程序員的世界其實是一個有著嚴謹邏輯的世界，所以，在這個世界裡的每一件事情有著必然存在的因果關係，程序的Bug就是其一，客服要與程序員一起找出每個bug的原因。當然，如果你想了解一個不一定得有因果關係的世界，可以點擊查看果殼的一篇文章《世界上為什麼存在靈魂？》

如果要一句話概括現有我理解的重現問題的方法就是，採用控制變數法，窮舉可能的場景並不斷進行簡單的QA（Quality Assurance），然後縮小問題的範圍，再重新採用控制變數法，窮舉可能的場景，重複以上的操作，直到QA重現問題。（我不是專業QA，你可以隨意吐槽我的觀點）

現在問題來了，為什麼要重現問題？因果關係是，程序員說，只有可以重現的問題他們才可以解決，是不是很有道理？

如何寫一個好的解決方案——授人以魚不如授之以漁

剛開始做客服的時候，我就吭哧吭哧給每個遇到的新問題寫下解決方法模板，並分享給其他人，以為其他同事可以直接引用，但後來發現，部門裡每個同事基本上都會有一套屬於自己的方法模板。這個直到有一天才想明白，其實真正的解決方法模板應當不僅包括解決方案還要包含問題判定思路，否則，其他人無法把這些解決方案放到一個合適的場景中使用，也不能理解這個解決方案的深意。

一個一個獨立的解決方案是一種顯性的存在於我們腦海里的思路，我們可以很輕易將其捕捉並呈現在文檔里，但那種以「經驗」和對產品的理解做出的問題判斷是快速並且很難捕捉到其思維過程的，我們需要逐步推敲，再將其文字化。這一段有點類似那本講述思考的《思考，快與慢》，強烈推薦。

判定思路與解決方案合起來也是一種更能系統理解這個問題的方法，所以，新的解決方法模板必須包含基本的判定思路和幾個解決方案，這樣之後，其他人才可以理解並使用模板。

那麼，一個好的解決方案格式需要遵循什麼原則呢？

1. 列表式

將操作步驟變更為「1. 2. 3.」或者「（1）、（2）、（3）」，並且每一步盡量只包含一個操作

2. 不要給用戶多個方法

有時，我們會為了證明自己的方法多，而盡量一一列舉。用戶對於產品的理解遠遠比不上客服本身，客服其實需要根據自己的經驗和對產品的了解直接給出最優的方案，當然，如果不能解決，可以再給第二個

3. 不使用模糊或者可能造成模糊的操作說明

比如在一個網頁上操作，你直接給對方一個直達某個頁面的操作，比告訴用戶點擊左下角或者左上角什麼按鈕要好的多；

4. 要有「大局」思想，置身其中

如果在一些工單系統中，用戶收到我們的郵件或者回復將不只是解決方案本身，還有定製的郵件片頭和片尾，在使用之前需要先了解這個解決方案用在什麼地方。

如何更好的讓用戶接受你的回復——憤怒的孩子

一個再好的解決方案，如果用戶根本不接受你的建議，一切都是枉然。

解決問題之前，請先解決用戶的情緒問題，這也是做客服的難點所在。想起了一本看過的書《別以為你懂孩子的心》，當然，我並不是將用戶比喻成孩子，而是兩者屬於同樣場景的問題，想像你和一個正在哭鬧的孩子使勁講道理，這顯然不是一部政治正確的電影，後者確實可以通過講道理解決一切問題。

不要說廢話，委婉需有度。越直接面對用戶的問題，可以越讓用戶感覺到客服的誠意，當然，有時會因為公司PR的要求，有些話不能直接講，這個是最難受的——客服和用戶都很難受。

回復需有針對性，不要過度依賴模板。模板越來越完善也會讓客服越來越像機器人，缺少靈活度，甚至當用戶回復了信息之後，客服在判定這些信息沒有意義情況下，便會直接忽略，然後再次粘貼模板回復。

作為一名客服需有的態度——較真，你就輸了

用戶帶著問題諮詢時，多半還會帶著情緒，作為一個正常人類，在打交道的過程中，我們的情緒也必然會隨之而起，但千萬不要動怒，我們需要區分清楚，其實，用戶遷怒的一般只是是產品本身，與客服的人身和能力沒有關係。

「始於憤怒，必終於羞恥」——《查理智慧書》

曾經在思考，為什麼產品經理不直接接觸這麼多的用戶？這樣不是可以更了解用戶的需求和問題么？其實不然，當用戶與客服接觸時，由於用戶對產品的不了解所而帶來的無法正確表達自己的需求，以及用戶本身的情緒，客服會成為一道很好的過濾網，過濾掉那些用戶聲音的噪音，之後再將其中有用的部分傳遞給產品經理。

最後，作為一名客服，我也在琢磨著，如何更有效的傳遞用戶的聲音給產品經理，如何幫助產品經理了解產品問題的真實緊急重要程度，有機會再分享。