有知乎的网友看到了我三年前的文章 其实，我是一个客服 ，已经过去太久，回复完他的评论，突然有了更多想要去说的话，正好将此篇文章作为已经离开的这个岗位的总结，随便聊一聊，仅供参考。
工作背景：一款工具性产品的客服；客服只是我日常的一半工作；不涉及较重的呼叫中心业务。
客服工作是一个流程化的任务
做客服工作的时候有一条原则，即，**如果一项任务没有流程，就需要创造流程。流程包含处理的步骤和决策的原则。**比如，其实日常用户所遇的90%的问题实际都是已知问题，那么之前所沉淀的案例就可以总结为固定的流程，并设置模板，尽量以流程来减少做决策的部分。
由于客服人员每天都会遇到大量的重复性的工单，如果缺少固定的流程，密集的决策会放大可能的人为性的错误，甚至影响处理的效率。一个只需要模板回复的用户邮件，与一个需要斟酌每一个字来回复的邮件相比，所需时间相差甚远。
「磨刀不误砍柴工」
如果涉及到需要决策的部分，可以靠提前设定原则来规避。最为基本的，客服至少需要知道在回复一个用户时需要了解的基本要素，或者不同的渠道应该以什么底线和什么针对性的方式来回复，比如哪些事情必须做，哪些事情不能做，尽量以清单的形式反复打磨来呈现。
处理的步骤和决策的原则都需要在培训或者日常的会议中反复强调，尤其是遇到了合适的案例，可以借题来发挥，最终能够完成意识上的统一。这里，文字化所有的流程是一个必要的开始。口径不统一，流程混乱，是用户最不愿意看到的。
从更高的角度上来讲，我的日常任务就是要确保整个客服系统的稳定运行，从基础框架的搭建（硬件），到客服的专业服务意识（软件）。在之前的工作中，我会在电脑桌面放上一个整体的思维导图，以此映射整个客服系统，在每一次的讨论中，反复修正。
关于思维导图，可以参考另外一篇文章：https://zhuanlan.zhihu.com/p/35277679
扩展客户服务的边界，从用户找到我们之前就开始
客服工作确实是被动的，等待用户与我们联系，甚至有时是在等待产品BUG的出现。不过，这种被动的情形下，可以更为主动的出击。在2017年的一次用户调研中，除了打电话以外的方式中，搜索仍然是排名第一的。那么对于搜索内容的干预就是重要但不紧急的第二象限工作。我们可以从日常的数据中挖出最为常见的问题Top 10，然后以用户的视角尝试在百度搜索，将这些问题的解决方法放在用户在搜索中可以看到的位置。
更为主动的态度始于我们以用户接触我们的途径来思考，他们会在百度知道和知乎提问，甚至一部分用户是在应用商店看到我们。这些所有可以涉及的地方，从成本上考虑之后，我们既可以直接进行内容干预，也可以增设联系的途径，避免用户情绪无处宣泄。
搭建自己的论坛或者使用第三方论坛服务也是在让用户找到我们之前，让用户以自助或者互助的方式解决问题，减少用户到达客服服务这一步的需要，这个似乎与上一段有所悖论，实际上我们既想让用户找到我们，又不想让用户找到我们，这两个分别是从满意度和成本来考虑的，这两个角度在客服工作的很长时间里会一直角逐着。
客户服务的边界也可以扩展到产品开发上，比如软件本身有自检功能，在常见问题发生时即时显示在发生问题的地方。
最为重要的客服思维：闭环的原则
这是一个最为简单但最为有效的原则，一句话概括就是「问题从哪里来，最终还是需要回到哪里去」。
- 用户提出了问题，一部分我们可以立刻解决，一部分，我们需要询问更多的信息；
- 在询问了足够的信息之后，一部分可以立刻解决，一部分需要与技术人员沟通；
- 在沟通之后，问题得到确认，一部分可以立刻解决，一部分需要等待产品更新，还有一部分无法解决
- 产品更新之后，需要尽可能的通知到这些用户，用户满意度和忠诚度的提升就源于这种闭环的负责到底的态度
- 无法解决的问题，也需要从态度上和必要的原因上给出恰当的回复
所有问题的解决必须是问题最终回到了用户那里，只是问题已经变成了各种各样的答案，哪怕这个事情已经过去了很久。
实现 SLA 承诺，靠系统来规避人的惰性
每一家产品的客服都会给出解决问题的承诺，比如免费用户1个工作日、VIP 用户工作日内30分钟。对于如何实现这类的承诺，仅靠团队人员的自觉甚至规章制度的惩罚都是不够的。就像区块链从技术上解决交易的信任问题是以不信任任何人来作为基础设定的。那么从系统上思考如何实现SLA承诺，也需要以不相信任何团队人员为出发点，当然，这只是解决问题的思考假设。
这个时候，平台的统一性尤为重要，用户有各种各样联系我们的方式，但是通过客户服务平台，可以汇总所有渠道的内容和数据，这样就完成了系统化的第一步。市面上有很多客户服务的工具可以实现这样的系统化，不过，基本的思路有两个角度，从客服的角度，有一个经过系统判定和调试的「队列」可以让客服人员按照顺序从容不迫的处理，队列的顺序与服务承诺直接相关，甚至用颜色的深浅来标明优先级和状态；从管理的角度，有一个实时显示当前所需处理的任务的状态页面，具体的颗粒度以实际情况而定。
漏斗原理，决定满意度和成本的考量
之前有提到，客户服务就是在成本和满意度之间进行平衡和考量，每次在说明这个看法的时候，我都会举一个极端的例子。假如我们精力无限、人员绝对充足，最理想的解决问题的方式是站在用户的旁边手把手代为解决，但是，这永远无法达到。
为了完成成本和满意度之间的平衡，我们需要首先将用户联系我们的整个路径绘制出来（以最长路径为示例），然后以「漏斗」原理来辅助决策，最后达成一个设定的指标。其中，每一环的过滤取决于上一步解决问题的有效度以及当前这一步获取答案的便捷度，最好的答案是出现在发生问题时候的答案。
之前工作中达成的指标有些缺陷，由于数据支撑的缺乏，我只能关注最后单次回复解决问题的比例。如果每一步数据跟踪到位的话，可以更为有效控制漏斗的过滤，确保以低成本完成较高的满意度。
数据的挖掘，找出满意度的黑洞
数据的挖掘依然在平台统一的前提下，汇总的数据可以以更细的维度来挖掘出有效的信息来。比如，之前在看到满意度下滑的时候，分别以问题分类来查看满意度的数据，之后在问题分类中再以分属不同的平台来查看满意度，最终可以找到较大程度影响满意度的因素，当颗粒度足够小的时候，还可便览属于此分类的用户反馈来查看具体可见的问题。这里只是一个极为简单的例子，真正的数据挖掘还会有更大的效用，这个等我经验积累足够之后再单独写一篇总结。
把客服工作放到整个客户购买流程中去理解
公司本身的目标仍然是利益最大化，以满意度来衡量客服的工作只是其中一个角度，我们可以在产品购买的整个流程中去思考，尤其是针对To B的产品。放到整个流程是为了从利润最大化的情况下，再决定客户服务需要关注的因素，比如针对大客户和小客户的服务区别等等。
维护与开发团队的沟通渠道
产品毕竟还是开发团队的作品，如果要主动应对产品方面的问题，需要与开发团队有一个积极的沟通渠道，而他们也会很在意用户的反馈。从产品发布的角度来看，发布前的产品沟通可以让客服团队提前为已有的问题做好准备，尤其是一些已知的问题。从用户反馈的角度来看，一份好的用户反馈报告，可以让开发团队从直观上看到用户关注和吐槽的重点。为了沟通的方便，部门之间的会议可以考虑周期化。
另外，好的沟通氛围可以帮助解决一些极端情况，尤其是重大产品BUG的出现。在我工作的那段时间里，不管是运维还是产品都出现过这类紧急问题，只有第一时间与负责的部门直接沟通，才能有机会最小化问题的影响。
类似的道理也可以套用到其他更多的部门，客服作为与用户接触的一线，任何与公司相关且会引起用户反映的活动都需要客服来处理，也都需要有有效的沟通渠道。
定期的客服服务调研，为优化提供支撑
从早期微信客服渠道仅作为噱头开始，不知不觉，微信已经属于很多公司基础性的渠道之一。2017年做过的那次客服调研发现，微信渠道接受度已经一定程度上高于电话，加上微博本身十分混乱的接口，本来能成为劲敌之一的社交媒体渠道，现在微信占了大头。这也意味着，在优化客户服务时，在微信上需要投入更多的精力。
在之前与业内人士交流的时候发现，越来越多的人不再接受长篇大论的邮件的处理，更喜欢短句的对话，一问一答，俗称「Conversation is the future of Customer Support」。在用户习惯逐步随着潮流变化的时候，可以通过各种调研形式来逐步辅助自己服务的优化。
向其他企业学习，三人之行必有我师
一直觉得，客服是交流甚少的行业，在我从事工作的三四年中，除了在推销客户服务工具的销售员那里，在其他地方几乎听不到同行的声音。但是每一家企业呈现的客服都有着自己的思路，我们仍然应该虚心查看同行的作品，可以尝试作为用户逐个体验，或者用抓包的形式找到服务背后所应用的工具名称，甚至直接勾搭客服找到幕后工作者。我自己尝试了很多互联网产品的客服，并收为案例来研究。
注意客服团队的稳定，一个负能量爆棚的部门
每天，都有无数个用户从各个渠道与我们联系，我们可以听到各种抱怨、指责甚至谩骂，当然也有一部分夸奖，但是，负面情绪的人更愿意发出声音。我一直觉得，客服其实是最弱势的，当愤怒的用户到来时，他们是无法还嘴的，否则用户抱怨的方向就从产品变成了人身攻击。换位思考来看，面对那些无还手之力的客服，恰恰可以看出一个人的素质，不过，这都是题外话。回到客服本身，面对如此多的负能量，确实需要及时沟通和纾解。
首先，虽然我们鼓励换位思考，但是，如果客服无法将用户对产品的指责与对服务本身的指责区分开，负能量就会迅速积累甚至过激反应，这是日常需要达成的重要共识。其次，团队内部定期的1对1对话需要坚决执行，可以帮助及时了解团队客服的工作感受和问题。
未能完成的一点，用户反馈的语义分析
现如今，用户发声的渠道太多了，虽然我们可以在产品内做引导，让其进入我们的反馈系统，但是，仍然有很多用户会去微博、应用商店甚至知乎上抱怨，而且这种抱怨很多是不需要直接应对的，重在收集。对于这类自发声的用户反馈，希望可以在未来通过爬虫或者其他服务将这些反馈抓取到数据库里，再通过语义分析和清洗，以标签来分类，最后可以得出更为饱满且直观的反馈数据，甚至可以及时主动察觉产品的新问题。
目前已经看到国外有几家提供这类服务的公司，不过，暂时还没有看到国内的。
以上的总结较为粗糙，每个部分其实都可以展开再细分挖掘。不过，时间有限，希望现有的这些可以偶尔帮助到从事客服工作的你们。