被遗忘的技术支持岗位

文/明道云创始人任向晖

我发现一个现象。在我们行业，谈论营销获客、销售增长、产品思维等话题的文章很多，但是谈论技术支持（Technical Support）话题的文章几乎没有。似乎我们行业根本没有这个职能一样。在企业内部，技术支持部门受到的重视和得到的投入也往往大幅低于其他部门。

但实际上，技术支持岗位和工作可能是企业软件行业独具特色的事情，它比其他行业的同等环节要重要得多。

软件业的支持和服务既是商业的重要组成部分，也有它鲜明的行业特点。总结来看，客户的技术支持环节面临诸多挑战：

软件产品和服务需要专业性较高的支持服务人员；
差异化的软硬件环境带来的复杂性提升；
客户对支持服务需求的多层次需求，有的简单，有的相当深入；
服务商对支持服务难以统一定价，甚至很难定价销售，而技术支持的成本会随着客户增加越来越高；
技术支持往往需要和产品研发团队有密切的协作；
对于年费订阅制的服务，技术支持服务的失败几乎将必定导致客户流失。

尽管有软件企业建立了客户成功（Customer Success）部门，但它的具体运营活动依然是在技术支持的范畴，除了新用户特定的On Boarding实施过程。建立客户成功部门的一部分目的是在将技术支持成本中心转化为能够促进客户续约和增购的收益中心。然而，我们只需要在支持与服务活动流程中贯彻一些原则和运营技巧，单纯意义上的技术支持服务也能够对增购和续约产生直接的作用。

我们将技术支持工作影响客户满意度的因素总结为以下几个方面：

（1）服务时间范畴：每周提供多少小时的服务

（2）响应时间：当客户提出问题后，多长时间能够得到第一次响应

（3）沟通内容质量：能否及时准确解决客户的问题，能否提供超出预期的内容

（4）服务态度：礼貌和温度感

为了提升以上每一个因素的质量，意味着更高的服务成本。而服务商常常低估产品服务销售后所需要的支持投入。当入不敷出的时候，服务商的支持能力将被限制，从而降低服务品质，导致潜在的恶性循环出现。

为了解决好这组矛盾，以下是我们对合作伙伴支持与服务工作的主要建议：

分层分级提供技术支持服务

和大多数B2B行业一样，软件行业的客户要求和他们的规模成正比。越大的客户对服务的要求越高，当然他们的支付能力也更强。因此，技术支持服务必须利用好这个规律对服务本身进行分级。一个小型支持团队如果要用同样标准支持1000家客户是很困难的，但如果只是支持10家大型客户就有可能做到高水平的贴身服务。

基于Average意识的技术支持服务设计也只会是Average的水平。高水平其实来自于分级。这既是服务商控制投入成本的主要办法，也是集中资源向高价值客户提供高水平服务的必要条件。

在分层设计中，服务商可以针对所有客户提供一个L1的服务标准。这个标准针对上文提到的满意度影响因素——服务时间范畴，响应时间进行限制。而且，在这个服务水平上，团队中无需包含技术专家，只需要有经过训练的专业客服即可。当L1标准所针对的用户提出无法问答的问题时，服务者通过一个原则来决定是否升级到下一个标准，或者转交技术专家来提供服务。这个原则就是——问题是否来自于产品和服务本身的缺陷或者暂时无法满足的功能。

理解分层分级提供服务的逻辑并不难，但是服务商常常陷入一个复杂度陷阱。这就是无法区分清楚在不同的客户处境下，应该用什么样的处理办法。如果全面提级所有的客户支持，将导致自己的成本堆积；如果全面拒绝或者都要求客户购买付费的服务包，将可能导致客户满意度灾难。这里的关键原则就是要支持团队过滤出这两种特殊情况。

技术支持工具的完善

软件行业的技术支持专业工具包括：

（1）文档

软件公司可以使用Gitbook(https://www.gitbook.com), Docusarus (https://docusaurus.io) 等免费工具构建产品知识库。其中包含分类清晰的产品使用帮助、概念定义、How-to指南、讲解视频等多元性的技术支持材料。

这是技术支持工作的基石。没有一个准确和不断丰富的知识库，任何人都无法提供高质量的服务。‍‍‍‍

从分工的角度，产品文档的写作往往是从产品部门开始的。它极容易脱离实际用户的感受，对用户的实际使用障碍缺乏预见性，导致文档无法对用户提供实效的帮助。因此，我建议企业软件的用户支持文档应当由支持部门来主导创建。他们可以从产品设计文档得到基础内容，但通过实际客户支持工作的进行，不断优化和增补内容，让文档成为支持工作的主力军。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

（2）不断积累的FAQ

在产品文档中也可以包含FAQ专区。在客服工单系统中也包含了历史上已经提供了问答的记录，其中可以标识出常见问答。这个内容将帮助团队提供相对标准化的高质量服务。

目前，专业的客服平台都能够提供模糊搜索和推荐匹配的能力。所以，客户也可以利用这个特性来实现一定程度的自服务。

（3）客服工单系统

要让客户满意，就必须有响应的闭环。客户提出的所有Issue都需要建立工单跟踪，确保最终解决了客户的问题。客服专员在任何时间都很清楚有哪些客户需求没有被处理完毕。工单也是传递到内部沟通或者提级处理时的沟通工具，它应该记录和客户交互的全部过程。

（4）内部协作工具

为了解决复杂的技术问题，客服团队经常需要和内部成员沟通，这可能包括产品、研发和销售团队的成员。出于合理的隔离需求，内部沟通的内容需要和客户的沟通内容之间有防火墙。

除了这些必要的工具以外，支持团队可能还需要通过远程连接工具（Team Viewer, 向日葵等），在客户授权的前提下，访问客户系统的能力。

协作体系的完善

（1）利用上文所提到的内部协作工具，打通内部成员的协作机制。这要求产品和研发团队能够公开内部分工表。让技术支持成员能够迅速定位相关问题的产品研发负责人。这个分工表相对稳定，容易记忆。由技术支持人员来直接做出选择，比内部再增加一次流转要高效很多。

（2）内部的通告体系。涉及到产品新版本发布，产品文档变更，产品的运维计划等所有可能影响客户使用的事件发生前，支持团队应该得到周全和及时的信息。以避免客户知道，服务商内部却不清楚的尴尬情况。

（3）定期的跨团队反馈。技术支持成员会从事一线的客户问题处理，因此他们对产品运营过程中存在的质量问题分布、客户需求的分布和变化比任何人都清楚。服务商应该善于利用这个资源来让技术支持团队定期Brief给产研团队。

贯彻Account Base理念，促进业务增长

技术支持工作如何连接客户销售和经营？这是一个困扰行业的长期课题。虽然销售岗位承担了此项责任，但是客户的实际使用过程中，往往更多的是和技术支持团队在打交道。销售人员可能并不清楚客户目前的使用深度、使用障碍、使用计划等决定了未来业务价值的信息。

解决这个问题的核心思路是建立Account Base理念。基本方法就是在CRM应用的Account（客户）这个层面共享或者同步来自销售端和服务端的数据信息，建立一个跨越销售和服务过程的客户超级台账。比如，沃尔玛是明道云的客户。在这个客户记录下，有联系人、报价、订单等基础的CRM数据。我们可以将技术支持工作中的所有记录同样关联到这个Account下。如果支持团队使用独立的支持工具，则要求将该工单对应的Account的所有交易信息也同步过去。

这样，销售人员会看清楚这个Account的所有工单对话内容（可能来自多个联系人和诸多终端用户），而支持人员也很清楚这个客户的当前价值和交易历史。

在这个信息透明度的基础上，对技术支持团队进行如下信息的培训，并要求他们在恰当的时机快速和对应的销售人员进行沟通。在明道云的体系下，就是一个快捷的@而已。

客户提出高版本才有的特性需求
客户提出新版本即将推出的特性需求
客户提及新的投入、立项
客户使用人数、用量即将超标
客户的使用涉及到供应链和生态企业的联动

除了这些正面的促进销售机会的信息，负面的也很重要。因为客服过程中的负面信息可以有效地提醒防范客户流失。

因为我们的原因，客户产生了严重的抱怨
客户产生了减少使用的计划
客户产生了迁移到竞争产品的需求

小结：

技术支持环节的投入能否起到以一当十的作用我缺乏量化的证据。但是可以肯定的说，高水平的技术支持能力绝对是大客户所依赖的。有议价权的客户甚至会要求5分钟之内的首次响应时间标准，正说明了他们对这个服务品质的要求。

而从服务成本上看，训练合格的技术支持人员的实际人效是很高。在大多数企业软件门类，一位Support专员甚至可以同时支持100家以上的客户需求。他们也是客户满意度的哨兵，准确和详实地观察着客户的实际使用状况。CEO想要了解现有客户的满意度，最佳的沟通对象就是一线支持人员。但我感觉我们行业总体上低估了这个职能的重要性，老板们通常都向外看，关注营销，关注销售，向内也只会关注产品研发的进程，总是忘掉了那个在角落里的技术支持部。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍