售后技术支持管理指标实践

前言

如《艾瑞咨询》而言 —— "体验经济时代，售后服务或成为企业角逐的新地带"。售后技术支持作为售后服务的重要一环，在企业服务领域，已然成为企业提高产品附加值，实施差异化战略，获得竞争优势的重要途径。市面上关于服务的管理指标非常多，具象到售后技术支持，就寥寥无几。本文主要就售后技术支持的管理指标和大家做简单探讨。

什么是售后技术支持？

售后技术支持是公司为其用户提供的售后服务的一种形式，帮助用户诊断并解决其在使用产品过程中出现的有明显症状的，可能由产品导致的技术问题。虽然不同公司对售后技术支持的职责定义略有差异，但一般而言都是在产品卖出后，对用户提供持续的免费或增值服务。近年来，随着 ToB 市场的迅猛发展，各大厂商从过去的产品功能竞争、价值竞争、技术竞争逐步升级到个性化服务竞争。企业级用户不仅重视应用软件功能的丰富性、运营的稳定性，更对厂商的售后技术支持服务提出了极高的要求，售后服务已然成为了各大公司维护客户关系、吸引客户粘性的重要武器。

就软件行业的售后技术支持岗位而言，因为承接问题的多样性和复杂程度，一般会设置 1-3 个级别。

• 第一级别是初级工程师，一般负责与客户沟通，收集基本信息，并利用内部产品知识库与技术文档解决较为简单、普遍的技术问题。

• 第二级别是高级工程师，一般掌握较为精深的公司产品知识，同时具备 IT 通用技术能力，如数据库，网络，云原生等，可解决较为复杂的技术问题，并具备搭建复杂组网或者测试环境，开发系统 SDK 或者 API 接口等能力。

• 第三级别是资深工程师，一般具备阅读产品核心代码的权限，并具备对技术疑难问题做诊断，分析，并给出高质量解决方案的能力。

公司一般会根据服务客户的体量和本身在售后技术支持领域的投入进行具体级别层次的设置。并将各级别售后技术支持人员的能力进行一定程度的耦合。如中小型企业一般设置为 1-2 级，大型及超大型企业会设置 2-3 级。 

如下为某大型互联网公司售后支持岗位职责描述：

• 提供相关云产品的售后技术支持，确保客户业务正常运行；

• 解决排除用户网络、服务器、存储、数据库等问题及故障；制定相关的技术实施方案，并在实施过程中提供技术支持；

• 负责对售后技术事件进行分析和总结，出具技术方案，并推动相关团队解决；

• 垂直行业和企业级客户技术支持；

• 编写相关产品问题和技术支持分析的报告，整理技术文档；

• 根据售后问题能提出建设性意见，并能影响相关部门及时优化。

一般而言，售后技术支持主要通过常规服务渠道，如 IM（在线）, 电话，邮件，工单等展开。提供 toB 服务的公司可能存在因客户体量的不同，增设专属服务，TAM 服务等，如为大体量客户提供专属微信群或者专属团队的支持。

 

售后技术支持的指标诉求

除了少数公司能将售后服务作为收入和利润来源外，大部分公司的售后技术支持部门往往是作为一个成本中心的存在，其未能直接带来盈利增收。在公司或者产品初期尤为明显，售后服务不像销售部门，有着清晰的销售指标和盈利产出，因此很多时候会有诸多的挑战和质疑，也就需要有更多的服务指标以衡量其价值和表现。

常见的挑战内容可能有：

• 为什么需要这么多人？

• 不同职级人员的技术强弱有什么不同？

• 如何证明这个季度比上个季度做得好？

• 我们公司的售后支持人员的技术水平和业界相比，差距有多大？

为了解答上述的问题，我们需要先定性出售后技术支持的工作内容和关注对象。

售后技术支持人员的主要工作为处理来自客户的问题。因此其主要的相关方就是以下三类人员：以老板为核心的管理人员，以销售为核心的业务人员，以及技术支持人员本身。对于管理人员，关心的问题是投入产出比，团队效能等。对于业务人员，关心的是问题处理速度，问题处理范畴。对于技术支持人员本身，关心的是解决问题后对其带来的价值和收益。

有了工作内容和关注对象后，整个服务指标的底层逻辑就清晰了。我们需要有更高的技术管理，更快的业务支持，更好的人才培养，以确保其一让老板满意，其二让业务部门满意，其三让员工满意，最终实现公司的目标。综上，即为售后技术支持人员的“3W”模型。

 
音视频技术的具体应用

如上文所述，售后技术支持的服务指标围绕技术，业务，人才。其中个人指标最终体现在团队指标上，因此我们的详细拆解指标会围绕技术，业务，团队展开。

团队

团队维度本质上是衡量人的维度。因此一般可以从人员数量，人员质量，人员效能等三个一级指标展开。

• 人员数量

人员数量一般是管理人员及 HR 人员极为关注的指标。我们通过会关注到二级指标维度，如团队平均人数，月员工离职率，月员工新进率等。需要重点说明的是，从售后技术支持角度看，对于人员需要进一步区分职级及工种，以便能进一步测算成本及团队效能。除此之外，售后技术支持领域一般也会按照技术属性区分不同工种，如 Android 支持人员，Web 支持人员，IOS 支持人员等。在团队内部需要对不同人员和能力的人员有较为清晰的划分，以便后续能够衡量团队在某项支持业务上的支持力度。

• 人员质量

人员质量表示的是团队“能做”多少活，干活的能力怎么样。对应重点关注的指标分别是工作容量和工作能力。首先是工作容量，不是说团队人越多越好，而是能干活的人越多越好。如果全是应届生，团队干活能力也就一般。一般情况下，以入职 1 年左右或者团队执行层的某个职级的人员为基准，如以入职 1 年的同学或者团队人员级别的中位数作为基准，有些同学比他强，可以取系数 1.2，比他弱，可以取系数 0.8。以此算法，可以衡量出团队所有人员的客观标准人天之和。该值能一定程度上度量团队可以做多少活。其次是工作能力，工作能力是用来衡量团队的技术能力水平线，侧面可以反映团队的结构合理性。其值是客户标准人天与客观人天之比。如一个售后技术支持团队，一共用 2 个 P4（系数为 1.2），4 个 P3（系数为 1），4个 P2（系数为 0.8），则该团队的工作能力 = (1.2*2 + 4*1 + 4*0.8) /(2+4+4) = 0.96, 该值证明该团队工作能力较强，一般团队能力在0.9已经算作比较强的能力。这里需要注意的是，工作能力很大程度上受成本制约，如果团队都是超过基准线 1 的人，虽然能力可能非常强，但是与此同时，团队成本也非常高。

• 人员效能

人员效能表示团队想不想干活，干活快不快。对应重点关注的指标分别是业务投入度和工作人效。首先是业务投入度，其是指技术支持同学投入到售后技术支持类型的工作的情况占比，数值越大，表示投入度越高。在实际的工作过程中，售后技术支持同学的工作可能有线上支持，培训赋能，工具开发，以及处理客户投诉，服务复盘等。以及偶尔要负责一些非技术支持相关的工作，如新人培养等。一般需要根据部门实际的业务侧重去衡量对应时间的投入有效性。假设我们约定团队内工作的投入有效性如下：线上支持（投入有效率100%，即实际人天 1，有效人天 1），培训赋能（投入有效率 100%），服务复盘（投入有效率 50%，实际人天 1，有效人天 0.5），工具开发（投入有效率 100%），工具 bug 修复（投入有效率 50%）。再假设一个 P4 的售后技术支持人员一天的的工作时间是 8 小时，其中 3 小时投入线上支持，另外培训赋能，服务复盘，工具开发，工具 bug 修复各投入 1 个小时，还有 1 个小时投入非技术支持相关的工作。则这个员工的实际工作人天是 7/8 = 0.875, 有效工作人天是是（3+1+1+ 2*0.5)/8 = 0.75。即仅以这个人员而言，业务投入率 = 实际工作人天/ 工作容量 = 0.875/ 1*1.2 = 72.9%

团队工作干的快不快，很大程度上可以由工作人效指标来衡量。这里的快，不是我们一般意义上，业务层面的快，如多久处理完一个客户问题。而指的是当前基线能力下，会有多少任务返工以及因工作未做好导致的复盘，回溯投入。如上文场景中的工作人效 = 有效标准人天/实际标准人天 = 0.75 / 0.875 = 85.71%。

一般团队的工作人效中位数是 0.8。工作人效的低下，原因一般就是在返工过多以及复盘回溯过多。虽然这类事件很难完全避免，最起码我们要在指标设计上，充分关注到这类数据的异动情况。并从意识和流程上保持敏感性。

技术

技术维度本质上是衡量创新的维度。因此一般可以从智能化，创新度，基础性，影响度等一级指标展开。

 

• 智能化

  目前售后技术支持领域对智能化的要求越来越高，因为其直接意味着支持人力的缩减。一般需要关注的指标有智能拦截率和工具拦截率。首先是智能拦截率，在售后技术支持领域，特别是工单服务场景中，对智能的要求已越来越高，主要表现为提交工单时，根据算法自动推荐的解决方案已越来越多，且越来越成熟。智能化作为增效的一个主要手段，已越来越被重视，因此智能拦截率也被重点关注起来。智能拦截率的设置对服务工具有一定的要求，一般需要服务工具具备一定的智能化能力，能够根据客户的提问的内容，针对性的推荐解决方案。解决方案的成熟度，AI 识别的准确性是智能拦截率的前提。其次是工具拦截率，在售后技术支持领域，经验丰富的支持同学会将日常碰到的技术问题的类型和解决方案进行抽象，将通用性排查思路固定并开发成对应的检查工具，以缩短内部技术支持人员相关问题的排查时间。相比较智能拦截而言，工具拦截更偏向于过程分析，对问题的排查提供思路和建议。随着智能化越来越被重视，工具拦截率也越来越被提及。需要注意的是工具拦截一般有比较强的针对性，如数据库慢 SQL 查询等，只能针对慢 SQL 类问题进行排查，因此一般有一个工具拦截系数作为锚定，以识别该类工具是针对何种场景的。工具拦截率是针对具体场景的问题的拦截情况的说明。

• 创新度

  创新度主要指在售后技术支持过程中，发明创造的具有开创性，专有性的知识成果，包括但不限于专利，书籍，文章等。一般需要出具具体的证明，结果展示具有延后性。除此外，一般公司内也会组织相关创新大赛，由各团队推举或申报本年度有重大创新的项目或工程。不管是外部发表还是内部申报，创新的达成条件都较为困难，最终满足创新度的内容也较少。因此创新度可以直接用结果数量和对应结果的荣誉高低来衡量。任何一次创新都是值得鼓舞的！

• 基础性

  在售后技术支持过程中，需要输出的基础性内容非常多。包括但不限于问题 FAQ，服务 SOP，最佳案例，最佳实践，建设性需求等。一般取相关输出内容的个数及分值加权汇总作为基础性的指标得分。 

  通常在团队内部绩效制定中，对团队人员有明确的基础内容输出要求。输出内容较多时，还会根据大家输出的内容设置不同的级别，每个级别定义不同的分值。比如可以根据案例的适应性和完善性，设置 S，A，B，C 等不同级别。一篇 S 级别的案例甚至能够顶 20 甚至 50 篇 C 级案例，以便鼓励大家输出高质量的案例。 除此外，在售后技术支持过程中，我们经常会提到”根据售后问题归纳总结出建设性意见，并能影响相关部门及时优化“要求。这就算是建设性需求了。该内容的衡量和评价比较困难。最原始的肯定是需求数及落地需求数。其中落地需求数一定程度上能反映该需求的价值性。其次在此基础上，可以对需求本身做一些量化设计，比如按照「KANO 模型」定义需求的分类，我们将基本需求，期望需求，兴奋需求，无差异需求，反向需求设置成不同的分值。以此来对该项内容的贡献做评价。再比如按照用户影响度，将影响全部用户，60-100% 用户，30%-60%，以及 30% 以下的客户设置不同的分值。

  基础性的内容非常多，一个高数据化的评价和衡量体系能够帮助团队更好地积累组织资产。与此同时，对组织的协同要求也比较高。如专门设置专家小组，对团队成员提交的案例和文章做评级。如对 FAQ 及文档查阅平台设置阅读次数和引用次数的埋点，以便有效衡量对应内容的引用因子。如专门建设完善的客户数据平台，能够快速地查看需求可能涉及到的客户数。

• 影响度

  在售后技术支持过程中，通过大量关联客户的打磨，可能会产生针对某行业或者某场景的方法论或者关键服务方案。之后再通过商业合作等项目，给予外部企业专业赋能等手段，获得盈利或者美誉的过程。这就是影响度。一般而言，影响度是公司已经有商业化服务产品后产生的指标。通过服务的方式，获取除产品产品之外的增值营收。如客户驻场服务，专家诊断服务，客户自建系统调优服务等。在未搭建服务增值营收前，实施有类似服务的客户的次数及感谢信等作为衡量指标也不失为一个好方法。

业务

业务维度本质上是衡量贡献的维度。对业务部门以及技术支持人员本身的绩效衡量而言都是重要指标。一般也可以从数量，质量和效率展开。

 

• 服务数量

  售后技术支持主要职责是解决客户的问题，因此服务数量主要围绕客户展开。常见的指标有：服务客户数，服务客户问题数，服务客户渠道，各渠道服务问题数等。以及围绕客户类型，问题类型展开的多维度的数据拆解。在这里需要注意一点，尽量避免直接汇总多个渠道的数据为一个总数据，该方式容易造成「辛普森悖论」，导致汇总数据的相关变化指标迥异于每个单组变化。取而代之是需要斟酌不同分组的权重，以一定的系数去消除以分组资料基数差异所造成的影响，同时必须了解该不同分组是否存在其他潜在要因而综合考虑。

• 服务质量

  服务质量表示的是做得好不好。相关的数据指标就非常多了。

  24 小时解决率，又称 FDR，作为售后渠道衡量服务质量的重要指标，其值能一定程度上反映售后技术支持的服务水准。一般情况下，取问题被解决的时间点-问题创建的时间点之差小于 24 小时的问题量作为分子，取创建时间为指定时间的问题量作为分母。如某个问题是 8 月 20 号 20 点创建的，在 8 月 21 号 19 点被解决，则该问题属于 24 小时内被解决的问题。这里有两点需要注意，其一是解决时间一般不是直接的关单时间，多数服务工具系统中取的是“待客户确认”的时间点。其二是 24 小时解决率一般以新建时间作为统计时间轴。另外需要注意，解决率指标中，24 小时的值可以根据业务需要进行调整，可衍生为 4 小时解决率，12 小时解决率，7 天解决率等。

  一次性解决率，又称 FCR，一般使用在电话外呼场景中，其是指客户的服务需求在第一次客户服务中完全解决的占比率。该值的衡量对服务工具有较强的依赖。当客户认为某个问题的首次解决方案未达到预期时，客户可以设置对该的问题『重开』。与此同时，技术支持人员在原问题跟进基础上重新对该问题进行二次解决。

  评价率，指定时间周期内，有评价的问题量占全部问题量的比例。

  好评率，指定时间周期内，评价为好评的问题量/有评价的问题量。这里需要重点注意是好评率的分母取得是有评价的问题量，而不是全部问题量，该种计算方式可以保证好评率的真实性。但是与此同时，在参评率极低的情况下，好评率波动会非常大。

  差评率，指定时间周期内，评价为差评的问题量/有评价的问题量。这里需要重点注意两点，其一是差评率的分母取得是有评价的问题量，而不是全部问题量，该种计算方式可以保证差评率的真实性。但是与此同时，在参评率极低的情况下，差评率波动会非常大。其二是售后问题被打差评，可能来自于产品和服务两方面的原因。在统计个人差评率的时候，一般需要将产品原因导致的差评剔除。

  独立闭环率指独立解决的问题量占全部问题量的比例。独立解决一般指售后技术支持人员通过个人的定位，排查和判断最终解决的问题量占全部问题量的比例。如01章节所言，售后技术支持领域，一般有一线，二线，三线等不同级别支持的区分。因此需要有独立闭环率指标去衡量服务渠道人员的技术能力。广义上的独立闭环率取值为 1 - 升级给开发的问题量/问题总量。因产品本身存在 bug，故障等非服务人员可以解决的问题，因此狭义上的独立闭环率需要剔除产品本身 bug&故障产生的问题。

• 服务效率

  服务效率表示的是做得快不快。相关的指标也较多，重点的几个解释如下：

  首先是服务人效，其区别于团队维度的工作人效，在售后技术支持领域，特别是工单支持系统中使用较多。一般情况下，通过服务人效，可简单直观的衡量工单服务效率。其值为单位天维度，能够处理的工单或者问题数。

  其次是平均解决时长，又称 DTS，其作为售后问题处理效率的重要指标，其值能较大程度上反映出客户对问题解决的等待时间。需要注意的是平均解决时长受长尾问题单子的影响，因此很多时候需要取 50 分位数，80 分位数的值作为最终的展示值。

  最后是转手率，在售后技术支持领域，存在较多场景，需要将问题从 A 人员转手到 B 人员的情况。如 A 人员到点下班，需要将问题交接给B人员继续支持。因为转手过多意味着问题处理耗时更长，且转手过程会引入涉及人员的对于历史信息的阅读成本，属于无效的损耗， 因此增加转手系数对转手情况进行监督。以便及时调整人员分工和工作时长安排。

结语

以上就是本文想要和大家分享的售后技术支持相关的管理指标了。不同指标的落地细节和针对性都有所不同，需要大家在实际工作过程中进行具体设计和甄选打磨了。除此外，实际在售后技术支持过程的指标还有很多，比如质检维度的置信度，人员能力的衡量度等。希望后面有时间对这块内容和大家做更深的探讨。

如果大家暂未体会到售后技术支持岗位的好处，也未曾体验过，那就不妨去试试，去坚持看看。也欢迎大家与我们共同探讨。