高 NPS 背后的专业服务体系是如何炼成的？

神策数据

于 2017-08-07 18:22:45 发布

阅读量749

点赞数

本文链接：https://blog.csdn.net/sensorsdata/article/details/99297438

版权

对于任何一家提供企业服务的商业公司来说，“服务”会是整个公司战略的重中之重，很多时候，优先级甚至还应该在产品研发之上。因为企业级服务的本质是为客户创造价值，低劣的产品与服务只能造成“狗熊掰玉米”般客户流失。NPS（净推荐值）一直是神策数据评判客户满意度的关键指标。

神策数据作为一个成立两年多、从零开始、为数百家付费客户提供过优质服务的团队，在服务方面碰到过很多问题，也总结了很多经验教训。在这个基础上，我们总结了自己的方法论，据此形成了自己的技术服务体系，在这里，从几个不同的方面与大家分享一下。

同时，这篇文章也是对我们这样一个企业服务行业新兵的成长过程的简短的记录，可以看到一个对企业服务市场懵懵懂懂的初入者，是如何在实际创业过程中，认识到服务的重要性，并与信任我们的客户一起，摸索并逐步完善我们的整个服务体系。当然，我们的服务整体上也还在不停地迭代与完善中，在这个过程中，来源于客户的反馈与需求，将一直是推动我们前进的源动力。

1工单和微信群

对于做企业服务、SaaS 服务的企业、厂商来讲，“工单”应该会是一个非常熟悉的概念。

简单来讲，工单是这么运作的，客户有问题需要由提供服务的厂商解决，则客户在厂商提供的工单系统上创建一条工单，厂商的服务团队则会按照一定的优先级依次处理所有客户提交的工单，在处理过程中，如果需要跟客户沟通确认某些问题，则需要通过工单系统本身，或者邮件等的方式进行来回沟通。

工单系统的好处，首先是每一条工单的处理都有相应的记录，可以保证没有遗漏；其次，对每一个记录都能做到有据可查，有了数据，后续就有了进行分析和优化的基础；除此之外，在厂商内部不同角色的人跟进时，也可以很方便地看到每一条工单的上下文，减少内部的沟通与信息传达。而主要的坏处，一个则是有可能会出现响应不及时的情况，另一个主要的问题，则是让客户觉得“冰冷”，没有“人情味”。

而对于神策数据的团队来说，由于创始团队本身是研发出身，在创业之初对于企业服务领域也毫无经验，而由于一些种子客户大部分都是投资人介绍或者老同事、老同学的关系，前期阶段也在微信群里面进行相应的技术与需求沟通，所以，在当时，针对这些种子客户的售后服务，我们也很自然地选择了继续使用微信群的方式。随着客户规模的持续增大，阴差阳错之下，我们的这种服务方式也自然而然地延续下来了。

在两年多的实践下来之后，微信群的沟通方式，也暴露了以下问题，例如，微信群里面的聊天记录不好整理，后续的统计、分析需要更多的人工处理工作，客户无法看到所提需求的后台处理进度与当前状态，而且，有时候客户也会担心所提的问题或需求有没有遗漏。但是，有一个优点，让我们一直坚持微信群作为主要的客户需求和问题处理方案，就是通过微信群，给客户的感受是有真实的“人”在处理这个问题，有任何问题，双方都可以坦诚地直接沟通。而不像工单系统那样，感觉是由冰冷的机器在进行处理，打交道的不是人而是系统。

自然，相比工单系统，微信群的服务方式，也给整个团队带来了更大的要求与压力，对于一线服务人员的专业性与服务意识需求更大。有时候，团队也在考虑，是不是我们应该换用工单，这样整个团队的压力会小很多，但是，秉承着“为客户带来价值”的理念，我们最终还是决定目前并且可见的将来都要坚持这种能给客户最好体验的服务方式，并以此来促进整个服务体系和质量的升级优化。

当然，工单系统因为它自身的优点，我们也会引入作为微信群这种服务方式的一个有效补充。例如，在非工作时间，客户的需求与问题可以通过工单系统进行提交与管理；在神策数据的服务团队内部，也可以通过工单系统来管理与跟进问题，并且对客户的反馈进行总结、分析，从而最终改进我们的产品。

采用什么服务方式本身并不重要，重要的是能否及时解决问题，为客户带来价值。秉承这个前提，剩下的就是结合实际的场景，选择最合适的服务方式，并以此来不停地完善与改进内部与之配套的服务体系。

2角色分工

在 2015 年 4 月团队成立之初，整个团队只有研发一个职位，全力以赴于产品的研发。再后来，为了开拓市场，我们也找到了第一个销售职位，而随着逐渐开始有正式的客户，在 2015 年 12 月我们也招到了第一个运维同学。在随后相当长一段时间内，我们销售团队开始扩大规模，分析师、市场等其他角色也随着就位，但是，依然只有这一个运维同学负责所有的客户环境的部署、升级与运维，同时负责在过百的微信群中与客户沟通，解答客户问题。而这个运维同学请假的时候，则会暂停部署与升级工作，由三位后端研发工程师轮流承担运维与微信群值班工作。

这样的情况一直到 2016 年国庆之后，随着客户规模的进一步增长，产品功能的逐渐增加与完善，每一个客户使用也越来越深入，这样的服务方式逐渐无法跟上客户的需求，因此，我们也当机立断地开始扩充整个技术服务团队，并且在招人的同时，逐渐完善了各个职位的分工与整体的服务流程。

目前，技术团队除了研发工程师与设计师之外，其余职位都需要直接面对客户，为客户提供高质量的服务，这些职位主要包括：

售前工程师：售前工程师主要负责引导与识别客户需求，向客户阐述我们的技术方案与架构设计，协助客户完成早期的需求验证以及相应的文案工作。
运维工程师：运维工程师主要要负责如下工作，包括：客户新环境的安装与部署；客户环境的升级，如硬件升级时的配合，单机版升级到集群版，1.7 版本升级到 1.8 版本等；客户环境的其它整体运维工作。
技术支持工程师：协助客户的工程师完成 SDK 的集成与数据接入，解决客户在使用产品和进行二次开发时的任何技术问题。

3服务流程

除了上述技术服务职位以外，我们还设立了咨询顾问、分析师、客户成功等其为客户提供无微不至的服务的职位。在为客户提供技术服务时，由于专业分工的区别，技术团队内部不同职位，以及非技术团队的其他职位，也会按照如下流程进行分工合作：

数据咨询顾问负责前期商务上的沟通，在确定合作后转交客户成功负责。
客户成功会作为项目经理，主动推进神策分析在客户处的落地，协助客户用好产品，发挥数据在产品和业务上的最大价值。
在推进项目落地时，会由分析师协助客户的需求方梳理需求，从而确定需要采集哪些数据，完成相应的事件和属性设计。与此同时，技术支持工程师则会协助客户的工程师完成数据接入工作。
在数据接入完成后，分析师与技术支持工程师会结合我们现有的工具与框架协助客户进行数据的正确性校验。
在数据接入完成后，客户成功与分析师会上门组织一次交付培训，结合客户实际的使用场景介绍产品的使用，并且基于我们的行业知识协助客户完成指标体系的建立。
培训之后客户进入正常的使用阶段，在这个阶段任何产品使用与技术上的问题，由技术支持工程师负责解决。其中，涉及到统计口径或者指标定义等方面的问题，会由分析师协助；涉及到系统稳定性方面的问题，会由运维工程师协助；涉及到商务层面的问题，会由咨询顾问与客户成功协助。
客户在使用过程中对产品的需求、反馈和建议，会有技术支持工程师统一收集、整理，反馈给研发团队。并且如果有新版本产品，客户成功会负责询问客户是否需要进行升级。
使用过程中的运维方面的需求，例如产品升级、硬件升级、数据迁移、扩容等，会由客户成功统筹安排管理，由运维工程师负责相应的操作。
在客户的整个使用生命周期中，客户成功会一直关注客户的使用与反馈，定时上门进行回访。而对于部分客户，在征求客户同意的情况下，分析师会主动提出驻场，与客户一起工作，一起探讨在这样一个实际的使用场景下，如何结合产品更进一步发挥数据的价值，并形成最终的案例。

对于不同的客户，上述的标准服务流程会有调整，一切以解决客户问题，让客户用好产品，发挥好数据价值为核心。

4平台与工具

作为一个不到百人的创业团队，我们在为客户服务的过程中总结积累了很多经验和需求，并据此大量采用了自研与购买的第三方工具与平台，以提高问题处理的速度与人效比，这些工具与平台包括：

自研了一套独立的运维管理系统，在客户授权的情况下，可以记录与维护客户的平台环境信息，接收、管理、统计与分析应用报警，并且可以与客户自有的监控平台打通。
开发了一套硬件监测工具，用于监测客户提供的软硬件环境是否满足安装需求，并提出相应的修改建议。
开发了众多的运维工具，例如数据清理、数据迁移、项目扩容、节点扩容等，并且将部分可以开放的工具提供给客户。
使用了一套第三方工单系统，用于内部对客户问题的流转记录，并且会定期对这些客户反馈进行汇总和统计。
正在开发一套运维“挂号”系统，能够让客户自主地选择安装、迁移、升级等运维操作的时间，并分配对应的运维工程师进行操作，从而避免客户成功人工安排带来的人力浪费，同时也给客户更友好的体验。