技术支持服务体系建设

作者黄凯，曾就职于阿里云，从事对外电商能力输出平台Linkedmall的研发工作。

背景

曾在某公司做过某项目的技术支持负责人，对技术支持服务体系的建设偶有心得。打算分享一下。
我们是个ToBToC的电商项目，最初随着项目的上线，合作的B类客户越来越多，项目组没有专门的技术支持人员，都是开发同学，导致每个客户对接群里都是一堆开发同学。
后果是客户提的问题出现了很多问题，一是客户不知道给谁提问题，只能选择一个有印象的同学提问；二是客户提的问题经常不能得到及时答复，加剧客户情绪；三是研发同学给客户的答案，完全站在研发同学的角度作答，无法让客户看懂问题。
对于研发同学来说一方面有繁重的研发任务，不愿意投入过多的时间在客户答疑上，如果及时回答客户问题，可能导致项目不能按时交付。如果不及时回答客户问题，会让客户对整个项目有不好的体验。 另外一方面时不时的钉钉群的消息严重影响研发同学的开发时候的心流状态，降低开发效率，同时也容易出现代码写错的可能。
对于HR来说，让研发同学当技术支持是很不划算的，专职技术支持对技术的要求没有那么高，相应的成本也没那么高，过多的研发投入到技术支持，会造成成本浪费。

问题分析

问题的本质

客户对高质量快速响应的技术支持服务能力与该项目无法提供的矛盾。

参与方分析

● 客户
○ 核心利益诉求：遇到的问题少。如果遇到问题，能得到快速，正确的响应。
● 技术服务团队
○ 核心利益诉求：低成本的高质量的提供技术服务。尽可能让客户自助解决问题。
● 研发
○ 核心利益诉求：尽可能降低技术支持投入的时间和重复工作
● 产品
○ 核心利益诉求: 获取产品的各个功能能否满足客户的需求及满足程度。
● 运营
○ 核心利益诉求: 能一起完成产品的交付和协助产品持续运行。
● HR
○ 核心利益诉求：用最少的钱能组建出完成业务全流程的高质量团队。

问题的解决

目标

● 让客户能体验到高质量，快响应的技术支持。
● 让研发能从技术支持中解放出来。
● 控制整体成本，尽可能少的投入。
● 为业务提供用户侧的心声和数据。

方案

技术支持服务是一个业务问题。业务问题的解决方案，就是通过建设不同的业务流程，解决不同的业务问题。然后将负责不同业务流程的人设定成不同角色。最后在通过信息系统优化业务流程，并实现降本增效。所以为了解决上面的问题，我们设计了三个主要的业务流程以及建设了对应配套的信息系统。

流程建设

基于各个参与方的核心利益诉求，我们设计了三大业务流程来满足各方。三个流程不是相互孤立的，而是相互配合相互影响。其中多级客户服务流程是核心是基础，是其他流程的输入。质量效率流程是降本增效，减轻技术支持人员和研发人员工作量的核心流程。 业务反馈流程在大的团队内和其他角色配合，优化产品，反哺产品，从更宏观的维护去提升客户体验。

多级客户服务流程体系

该体系根据问题严重程度日常流程和紧急流程。
● 日常流
客户有问题的时候，可以在开放平台，查看文档，下载sdk，下载demo，诊断等。也可以在客户的专属钉钉群里面，对机器人提问，机器人通过知识库和诊断系统尝试给客户答案，如果没有答案或者答案不满意，客户可以一键将问题转成工单，L1技术支持会解决大部分客户问题，如果L1解决不了，会转给L2领域开发人员解决，只有极个别的问题才会流入到L3领域专家。

● 紧急流程

客户提紧急工单后，该工单优先级会提质最高，技术支持人员会即刻查看，然后根据客户的影响面和严重程度评判是否按照紧急工单响应。如果是的话，区分一下是客户问题引起的，还是我们自身问题引起的。如果是我们自身系统问题引起的，就拉紧急问题处理群，按照线上问题处理流程进行处理。

技术支持运营，质量，效率流程

● 运营包括：
○ 排班： 安排技术同学支持的时刻表。安排领域开发人员的支持时刻表。
○ 技术支持人员工作负载：反馈出技术支持人员的工作饱和度，如果人员长期饱和，可能考虑额外加人投入。
● 质量包括：
○ 培训：对于新入职的技术支持同学，会进行基本的技术支持配置，其中包括工具的使用，流程的熟悉，客户答疑话术的规范和标准等。
○ 每日工单抽检打分评价：为了保障给客户提供高质量的答疑支持，每日早会技术支持管理人员会复盘昨日的工单，包括工单答疑质量的评价，答疑的不足点及改进措施。同时对工单答疑质量打分。
○ 技术支持质量周报，月报：工单质量周报月报包含大量相关指标，比如响应时效，工单答疑质量，客户有效投诉率，工单渗透率，重复相似性工单渗透率等。
● 效率提升包括：
○ 知识库录入：知识库录入一般在两个时间节点，一个是需求开发完，要上线时候，研发人员按照自己的理解录入一些可能会被客户提问的问题。另外一个时间节点，是在客户答疑之后，技术支持人员和研发人员都会根据客户的问题，判断是不是需要录入知识库。同时我们设定考核目标，要求技术支持人员每周录入的知识库条目数量。
○ 诊断脚本录入： 有些问题不是知识性的，如排查某个订单一直没有完结的原因。这就需要研发或技术支持人员通过录入脚本来降低重复问题的排查。其录入时间和考核目标和知识库录入是一致的，参考即可。
○ 开放平台：开发平台是让客户少提问题的关键，尽可能让客户自助解决问题。我们通过开放平台完成文档，API，SDK，在线调试，在线诊断的输出。

业务反哺流程

● 需求上报： 将客户遇到的实际需求一键反馈到业务洞察系统，让产品知道客户的实际需求，更好的给客户服务。
● 风险上报：将系统存在的风险一键反馈到业务洞察系统，方便业务负责人员能感知到业务风险，做好风险的控制和管理。
● 疑似技术缺陷上报：将系统中疑似技术缺陷一键上报，便于评估开发人员的代码质量和测试人员测试质量后续会有测试人员跟踪。为研发质量的评判提供数据支持。
● 产品易用性上报： 将客户使用经常会使用出错，或者比较容易产生困惑的点，反馈到业务洞察系统，方便产品同学对当前产品作改进。

系统建设

信息系统的建设为业务提供了降本增效的作用。在技术支持场景下面也不例外。我们为上述流程的流转建立相应 的技术系统，满足降本增效的目的。

智能机器人

由于我们的客户都在钉钉群内，所以我们直接购买钉钉内置的智能客服机器人，该机器人背后集成知识库，用于回答客户常见知识问题，基本能用。
另外随着最近生成式大模型的爆发，可以构建更加强大的机器人来支持技术支持，效果估计会比钉钉带的要好。

基于钉钉群工单系统

由于我们的客户到会建立专属钉钉群，并且客户的问题也是在钉钉群里提出的，那么我们希望结合钉钉现有的能力，打造一款符合我们业务实际情况的工单系统。整个工单系统分为两个大部分，一个是钉钉已经提供的群工单功能，另外一个是满足我们需求的定制化部分，打通了洞察系统，实现了工单问题一键转风险，一键转需求，高优客户工单长时间未响应提醒等功能，也打通了技术支持效能平台，将工单中蕴含的技术支持指标数据同步到能效平台。

诊断系统

诊断系统主要提供两大类服务。一类是一些信息查询，另外一类是问题诊断。针对信息查询，我们调用各个域提供的查询接口查询。诊断问题诊断，我们需要技术支持同学提前录入脚本，当排查问题的时候，通过脚本执行定位问题。相关具体设计方案本文不详细讲述。

技术支持能效平台

技术支持能效平台对于支持问题答案质量打分，同时提供各种指标数据。相关具体设计方案本文不详细讲述。

开放平台

开放平台是实现用户自助技术支持的基础。我们开放平台提供产品文档，解决方案文档，API文档，SDK，Demo，在线调试，问题诊断等功能。相关具体设计方案本文不详细讲述。

团队建设

在充分考虑实际业务流程等情况下，整体组织架构如下。其中每个小团队人员数量会根据实际客户数量，平均问题数量，工具便利性等作调整。

方案执行效果

该系统经过了四年建设和维护，起到了非常巨大的作用。由于业务数据敏感，这儿不提供实际指标数据。

总结

本文希望能通过上述分享，方便相关人员在自己的团队内建设一套完善的技术服务体系。我了解到很多研发团队没有把技术支持服务单独出来，随着业务的发展研发同学承担的技术服务的工作越来越多，希望你能通过形成独立的技术支持团队，降低研发同学的压力。