和之前的一些文章一样，这也是一篇顺便写的随想，因为要给新加入的同事做入门引导，在整理的过程中突然有了写下工作总结的兴致，其实，那么久了，我一直就是一个客服。
说起来，大多数人对于"客服"的理解与我们自己对于"客服"的感知有很大不同，这与用户遇到的问题和我们自己对于其问题的不同理解有着异曲同工之妙，属于同一印象在不同脑海里画面的直接冲突。我不能和家里人介绍我的工作是客服，因为他们脑海里固有的客服认知足以抹杀长久以来培养起的那份骄傲，“我家娃儿在外就是个搞客服的，太不争气了！"。
不过，先撇开这些顾虑，作为一个互联网产品的客服人员，首要过关的依然是对产品足够的熟悉和足够清晰的逻辑思维能力。前者是为了保持对问题发掘的敏感性以及综合判断问题的能力，后者是为了在混沌的状态下理出一条思考的路线，一步一步解决问题。
如何精准地理解一个问题——很少有用户知道发生了什么
用户最擅长的仅仅是描述一个简单并对问题的解决没有多少帮助的当前状态，大多数情况下可能只是情绪的表达，所以，我们首先是一个心理辅导师，然后才是客服，而且以用户对于产品的理解，很少有能独立讲清楚自己问题的，在我们认真倾听之后，“提出更好的问题"会成为下一个大的挑战。这个时候我们应该会想起一个很多人知道的"5W1H"分析法，什么时间什么人在什么地方使用什么方法做了什么事情，为什么？
**“5W1H"分析法套用在产品上之后就可以变成：**什么时间什么网络下在什么系统版本的什么设备中什么版本的产品上做了什么操作之后出现了什么样的错误提示。
这里推荐《学会提问》 这本书，原因如书名。
另外，即使在用户精准回复问题之后，为了减少转述过程中的信息失真，越能还原问题的影像会越有用，这个时候，效果：现场观察错误>视频录制问题/远程查看>截图与活动日志>文字或者语音描述。
如何判定与解决问题——重启电脑真的可以解决一半的问题吗？
“重启电脑可以解决一半以上的问题”，这个说法确实被夸张了，但这恰恰是为了表达一种客服的基本处理思路。很多软件的问题仅仅是电脑或者移动设备运行过程的一个故障，退出重新打开或者直接重启设备可以排除这样偶然运行故障的干扰，避免投入过多的精力，这个也可以作为我们日常使用软件的"必备技能”。
与重启电脑类似的必备操作是，务必确保软件和系统版本为最新，既可以减少旧版本Bug的干扰，也可以在与程序员沟通的时候不让他们抓着旧版本这个变量不放。
而当我们做完以上的预设操作并精准理解用户的问题之后，后面的步骤更类似于大学里的论文，客服要提出一种或者多种假设，想想你经常收到的那句"俗气"的客服语句就可以感受到，“根据您的反馈，我们猜测可能的问题是······"，而这里提出假设的精准度与处理问题的经验和对产品的了解程度正相关。
每每提到"经验"二字，我就想起大学里管理学课程的两派，科学管理派和经验管理派，“经验"是一种复杂的积累和思考方式，作为一个客服，可以尝试将重要的问题Case作为一个个案例认真分析，像经验派那样尝试分析并整理出判定问题的决策图，决策图就可以变成一种其他人可以遵循的科学判定方式，衍生成一种"科学”，这也可以间接说明科学管理派和经验管理派并不是对立的，走题了。
当提出假设之后，我们就需要通过与用户的互动来获得更多信息并验证我们的假设，然后就可以给出已有的解决方案。
如何Debug一个未知的问题——问题是绝逼可以重现的
处理问题的原则：1. 问题是可以重现的2. 如果问题不能重现，请参考第一条
我以非技术人员的角度大胆总结，程序员的世界其实是一个有着严谨逻辑的世界，所以，在这个世界里的每一件事情有着必然存在的因果关系，程序的Bug就是其一，客服要与程序员一起找出每个bug的原因。当然，如果你想了解一个不一定得有因果关系的世界，可以点击查看果壳的一篇文章《世界上为什么存在灵魂？》
如果要一句话概括现有我理解的重现问题的方法就是，采用控制变量法，穷举可能的场景并不断进行简单的QA（Quality Assurance），然后缩小问题的范围，再重新采用控制变量法，穷举可能的场景，重复以上的操作，直到QA重现问题。（我不是专业QA，你可以随意吐槽我的观点）
现在问题来了，为什么要重现问题？因果关系是，程序员说，只有可以重现的问题他们才可以解决，是不是很有道理？
如何写一个好的解决方案——授人以鱼不如授之以渔
刚开始做客服的时候，我就吭哧吭哧给每个遇到的新问题写下解决方法模板，并分享给其他人，以为其他同事可以直接引用，但后来发现，部门里每个同事基本上都会有一套属于自己的方法模板。这个直到有一天才想明白，其实真正的解决方法模板应当不仅包括解决方案还要包含问题判定思路，否则，其他人无法把这些解决方案放到一个合适的场景中使用，也不能理解这个解决方案的深意。
一个一个独立的解决方案是一种显性的存在于我们脑海里的思路，我们可以很轻易将其捕捉并呈现在文档里，但那种以"经验"和对产品的理解做出的问题判断是快速并且很难捕捉到其思维过程的，我们需要逐步推敲，再将其文字化。这一段有点类似那本讲述思考的《思考，快与慢》 ，强烈推荐。
判定思路与解决方案合起来也是一种更能系统理解这个问题的方法，所以，新的解决方法模板必须包含基本的判定思路和几个解决方案，这样之后，其他人才可以理解并使用模板。
那么，一个好的解决方案格式需要遵循什么原则呢？
1. 列表式
将操作步骤变更为"1. 2. 3.“或者”（1）、（2）、（3）"，并且每一步尽量只包含一个操作
2. 不要给用户多个方法
有时，我们会为了证明自己的方法多，而尽量一一列举。用户对于产品的理解远远比不上客服本身，客服其实需要根据自己的经验和对产品的了解直接给出最优的方案，当然，如果不能解决，可以再给第二个
3. 不使用模糊或者可能造成模糊的操作说明
比如在一个网页上操作，你直接给对方一个直达某个页面的操作，比告诉用户点击左下角或者左上角什么按钮要好的多；
4. 要有"大局"思想，置身其中
如果在一些工单系统中，用户收到我们的邮件或者回复将不只是解决方案本身，还有定制的邮件片头和片尾，在使用之前需要先了解这个解决方案用在什么地方。
如何更好的让用户接受你的回复——愤怒的孩子
一个再好的解决方案，如果用户根本不接受你的建议，一切都是枉然。
**解决问题之前，请先解决用户的情绪问题，这也是做客服的难点所在。**想起了一本看过的书《别以为你懂孩子的心》 ，当然，我并不是将用户比喻成孩子，而是两者属于同样场景的问题，想象你和一个正在哭闹的孩子使劲讲道理，这显然不是一部政治正确的电影，后者确实可以通过讲道理解决一切问题。
**不要说废话，委婉需有度。**越直接面对用户的问题，可以越让用户感觉到客服的诚意，当然，有时会因为公司PR的要求，有些话不能直接讲，这个是最难受的——客服和用户都很难受。
**回复需有针对性，不要过度依赖模板。**模板越来越完善也会让客服越来越像机器人，缺少灵活度，甚至当用户回复了信息之后，客服在判定这些信息没有意义情况下，便会直接忽略，然后再次粘贴模板回复。
作为一名客服需有的态度——较真，你就输了
用户带着问题咨询时，多半还会带着情绪，作为一个正常人类，在打交道的过程中，我们的情绪也必然会随之而起，但千万不要动怒，我们需要区分清楚，其实，用户迁怒的一般只是是产品本身，与客服的人身和能力没有关系。
“始于愤怒，必终于羞耻”——《查理智慧书》
曾经在思考，为什么产品经理不直接接触这么多的用户？这样不是可以更了解用户的需求和问题么？其实不然，当用户与客服接触时，由于用户对产品的不了解所而带来的无法正确表达自己的需求，以及用户本身的情绪，客服会成为一道很好的过滤网，过滤掉那些用户声音的噪音，之后再将其中有用的部分传递给产品经理。
最后，作为一名客服，我也在琢磨着，如何更有效的传递用户的声音给产品经理，如何帮助产品经理了解产品问题的真实紧急重要程度，有机会再分享。