浅谈我眼中的“服务意识”

转自本人运营的微信公众号“ 携程技术中心PMO”（ID：cso_pmo）

作者介绍

YY哥，近10年IT行业从业经验，曾就职于金融软件、移动电商、互联网金融和智慧旅游等行业，现从事项目管理工作，热衷于组织级过程改进和敏捷开发，同时也是Atlassian产品的忠实粉丝。

引言

受某书上提到“快速交付的产品迭代下需建立通畅的反馈渠道”触动，而我之前从事过近5年的软件服务业，对服务有一定程度的理解，所以想和大家聊聊“服务意识”。下面通过四个工作中可能遇到的场景开始：

场景一

“我这次真要彻底解决这个bug了，要不客户老来烦我，导致我无法专心做项目”

当我听到这句话时，其中的“烦”字刺激到我的神经。由于该bug一直未被根除，线上有很多客户上报这个问题，每次TA都是通过临时方法解决了这些客户的问题。但是后面还是会有客户陆续上报，所以，TA会感觉到“烦”。假如我们换位思考一下，大概情况是这样的：

• 客服同学：这个问题已经有好多客户提了，技术同学每次都只是对有问题的店铺做数据修复，为什么技术同学不能根本解决这个问题呢？
• 某位客户：哎，这个问题我都提个好几回了，现在还是经常会发生，看来真的解决不了了，每次只能像之前那样，遇到一个，反馈一个。

且不谈在整个链路中（从客户->客服->技术->客服->客户）各个环节对这件事情的感受，就某个bug反反复复，实则造成的成本总和（或称“浪费”）是很大的，客服和技术同学需要处理每个客户的反馈。由于线上问题都是临时的，对TA的干扰很大，当正忙着项目的开发时，又要穿插着修复这些问题。

如果从根源分析，是开发过程中质量不过关引入的bug。试想，如果我们的开发质量很高，客户使用过程中很爽，很少遇到bug，他们会专心忙着做生意，哪会有时间“烦”我们？当客户在不断地“烦”我们的时候，肯定说明我们做的不好，需要改进。当多个客户反馈同一个问题时候，这个已经在警示我们需要尽快处理掉。但是，从技术同学角度看，目前项目和手头安排的事情已经饱和，而修复这个bug预计需要3-4天，目前没空来修复。这个已知bug就很可能一直不被修复。

针对上面的case，既然是个普遍问题，且不断有客户反馈。产品和技术同学都需要重视起来，将其优先级提高，放在排期里。之前碰到过一次，某已知bug迟迟没被修复，卡在了产品同学这里，因为TA觉得该功能不是我们的核心功能，且用户量占比小，修复bug的投入产出比不高。但是，客服和技术同学每周要处理不少商家反馈该问题，每次都是数据修复。

有的人会认为，项目发布的一些大功能对客户的价值远大于一些bug或小的功能优化，这个说法正确的前提是：这些大功能对客户的确有价值，而不只是“一堆功能”而已。而这些bug和小优化是客户在使用过程中反馈给我们的，是客户真正需要的东西。虽然它们的价值小，但是持续地、快速地为客户解决这些问题，让客户感知我们的问题解决效率，这个就是“服务水平”的提升，会增加客户的满意度。

场景二

“客户反馈的需求无法被及时响应，需求池积压严重，反馈闭环不够通畅”

我曾经在一本书上看到大致这样的说法：优秀的产品经理会“借客户之力”来让自己的产品做得更好，而普通的产品经理往往会忽略这点，他们会更关注自己设计的功能，而很少考虑客户反馈的需求。通俗地讲，优秀产品经理在设计新功能时，会高度重视客户已经反馈的需求。我们为什么要做这个产品？是为客户创造价值的同时，也给自己创造价值，双赢。所以，做产品关注的核心是客户或用户，真正能给客户创造价值的需求应该被优先实现，如果我们起初不知道哪些功能会创造价值，那可以邀请客户或最靠近客户的内部人员（比如：运营）一起讨论，然后快速迭代一个版本，给内测用户/客户使用，他们会对我们的产品提出很多真正有价值的反馈。

我上面想说明客户反馈的需求的重要性，如果大家对一件事情的重要性能达成一致，然后配合适当的监督或跟进机制，这个事情一般都可能做成。当我们在设计各种新需求时，可以从客户反馈的需求里寻找一些灵感。客户反馈的需求，不管做或不做，都应该给予及时的反馈，否则客户会觉得他们每次提的需求都飘向大海，以后也懒得提了，这显然不是我们期待看到的。建立与客户之间通畅的反馈渠道很重要，如果渠道中某一环节出现问题，客户也应该有其他备选渠道进行反馈。

场景三

“客户是上帝，他们提出的需求，我们都要满足。只有这样，客户才会happy”

这完全是个错误的认识。客户的需求有的是完全不合理的，有的是合理的但是我们在当前的业务架构上实现不了的，有的是不符合我们产品定位的，有的是我们可以近期实现的，有的是价值低会放在以后实现的。在某种情况下，我们还真不能被客户带着走，我们应该teach这些客户，让他们接受我们的理念，引导他们理解我们的产品，比如，我们要做行业标杆，做生态就是一个很鲜明的例子。

之前参加过公司的“全民服务”活动，添加了一些客户的微信，做“一对一”沟通。前不久，有个客户在联系了客服同学后，被告之TA提的需求无法满足。然后TA通过微信找到了我，我咨询了熟悉这块业务的产品和技术同学，最后给她同样的答复：实现不了。但是，TA最后给我的反馈是：TA知道了这个做不了，但是我的服务让TA感觉很舒服。其实，我在沟通过程中，不只是告诉TA“不能实现”这个结论，之前我有向TA了解了更多细节，过程中也在向TA同步我跟进的进展，最终，我给TA总结了下结果。

场景四

“我有一个新需求，需要其他部门同学一起完成，总是感觉比自己团队内部配合差很多”

当产品和技术部门合并为同一个部门时，产品与技术同学关系甚好，对于有些问题，大家并不觉得是个问题，例如：产品同学没能及时交付视觉稿给技术，导致某项工作无法按时完成。由于彼此之间没有任何约束或限制，所以会导致事情进展很低效，甚至会影响到大家的时间观念。另一个可能的极端是：当产品和技术部门独立开后，大家严格按照流程来做事，例如：产品同学没准备好产品PRD文档和UI设计稿，那技术这边就不接这个需求，事情的拖延会归因于产品需求不到位。

无论上面哪一种情况，大家都没有站在“整件事的目标”角度来考虑问题，如果某一环节卡住了，其他环节只是纯粹在那等待，那事情推动起来就非常难了。可取的方式是，在做事之前，相关同学先达成一致目标，如果哪一环节遇到困难或卡住了，大家要相互帮助和提醒。有时事情被耽搁的原因是，团队中没人愿意主动站出来承担跟进工作。一般来说，任何事情都有发起人，如果临时组建的小团队无法“自组织”或每个人不能发挥主观能动性，那么这个发起人是否应该有责任承担起来呢？

跨部门/团队协作，需要每个人承担owner意识。认领的任务要按时完成，否则可能影响到整件事情的完成进度或完成质量。如果有人没有这种意识，TA很可能会拖后腿，让其他人感觉没大局观。跨团队协作是证明自己团队实力的绝佳机会，毕竟我们处在一个需要诸多协作的时代，单枪匹马或单个团队很难做成一件“大事”。如果我们能抱着“服务”的心态与其他团队合作，而不是抱着“我被安排来做这件事情”的心态，情况可能会完全不一样（前者是积极主动的，后者是被动的）。我们为其他团队提供什么样的服务水平，会直接导向其他团队以后为我们提供什么样的服务，将心比心。纵然，有的人或团队服务意识很弱，其他服务意识强的个人或团队应该“拉一把”TA们，用平时工作中的“服务”态度和表现影响TA们，毕竟大家是一个整体，以后肯定有一起合作的机会（噢，这个表述不够准确，如果把公司的事业看着一件事，那么我们一直在共同做这件事）。 

总结

通过上面的闲聊，我们可以获得如下的结论：

1. 从不要埋怨客户“烦人”，那是因为我们做的不够好；
2. 能获得“客户的反馈”是我们的机会，是了解客户真实想法的机会，我们应该重视并充分利用起来；
3. 服务是一种互动，我们需要与客户建立良好的互动关系和通畅的反馈渠道；
4. “客户是上帝”，但是上帝的认知可能是不完善的，所以我们得负起责任引导客户，并不是一味地让其满足；
5. 我们应该以”服务”的心态积极参与跨团队协作中，今天我给你提供优质的服务，明天你很可能获得同样优质的服务。

总之，如果我们在工作中能做到“设身处地”地“用心”服务，一定能把服务做好。我们可以把客户当做自己身边比较重要的人来服务，把新对接的客户当做“小白”，这样在交流过程中，使用的语言会更通俗易懂，解释的会更细致。如果我们对要服务的客户很了解，那可以游刃有余地交流。

---

部分图片来源于网络，版权归原作者所有。如果侵犯到您的权益，请联系我们。

---