精选文章｜浅谈TS如何提高自主处理占比

TS英文名称为Technical Support，中文名称为技术支持，主要职责是承接客服日常问题和对接外部第三方问题，快速定位问题和解决客户的痛点，从而降低研发人员的业务技术支持时间，提升开发人员的效率，并能够提出自己对产品的建议和看法，提升产品体验和降低问题反馈，从而实现TS价值；目前得物TS团队所支持业务主要涵盖DOP（得物开放平台）、交易、社区、直播、商家后台、供应链、客服等业务域。

那么如何降低研发人员的业务技术支持时间呢？由于TS自主处理问题占比的提升也是和研发人员的业务支持时间成反比的，本文主要通过下面几点对TS如何提升自主处理占比进行一个简单的分享。

萧伯纳曾经说过，世界上只有两种物质：高效率，低效率；世界上只有两种人：高效率的人，低效率的人。

一个高效率的人往往事半功倍，那TS如何在对接问题中做到高效率呢？

好记性不如烂笔头。我们通过构建一个适合自己的知识库，将我们散落的回答和知识进行收集和沉淀，不仅可以方便信息的检索，也可以对知识重新进行整合，从而产生化学反应，通过思考让自己拥有产出新知识的能力，同时也有助于后期新人学习。

如何构建一个属于自己的知识库 

• 建立问题素材库，可以选择自己喜欢的软件或者应用来收集和记录相关问题和知识；比如说飞书云文档，语雀等。

• 对问题进行分类，如咨询类、操作类、报错类等。

• 把知识点进行关联整理，直观的将所学的知识形成联系，从而找到解决问题的途径和方法。

• 对整理的问题进行精炼，并输出自己的理解；对知识融汇贯通，寻求突破，不断积累新的知识。

建立好一个知识库，这样在对接问题处理中的效率也会有明显的提高；我们可以通过自己或者团队小伙伴建立的知识库快速检索到相关信息，从而加快问题的排查和解决；除此之外，通过在知识库里耕耘，认知和思维将会有很大的提升，后期也会收获明显的成长。 

技能学习

工欲善其事，必先利其器。我们得物技术部拥有完善的排查系统和工具，比如：得物360 、Gondor交易后台、SLS日志排查、DMS等；熟练掌握和使用这些排查工具也会让问题的排查速度和效率得到极大提升，事半功倍；同时，TS可以在通过对问题的处理，主动提出有利于问题排查的小工具需求，对之后的问题处理效率也会有很大的帮助。

为什么在对接中需要问题沟通模版呢？

在此以开放平台举例，由于没有一线客服，也没有相应的工单系统，线上对接问题大致散落在各个微信群、钉钉、飞书以及IM系统中，问题反馈也是由对话进行展开，通常是开发者直接提问，而问题描述却缺少上下文和必要信息，很难一次就理解开发者的问题，在问题解决流程中，也需要多次对话才能拿到要排查的信息或是搞清楚问题意图。 

毋庸置疑，这样的沟通方式会带来极大的沟通成本，那如何尽量让开发者在一次问题沟通中就能够提供出全部易于排查的所有必要信息是值得我们TS思考的；针对这种情况，TS这边推出了开放平台问题反馈模版，针对不同类型的问题提供了相应的问题反馈模版，模版中包含了关于问题的描述和便于排查信息的一些数据；这样开发者便可在进行提问时根据模版提供一些必要的关键信息，从而避免无效沟通，降低沟通成本，进一步提升工作效率；问题模版如下所示：

改善沟通是执行力流程中的关键。在推行问题沟通模版后，TS和开发者在线上问题对接中的沟通效率也有了明显的提升；通过模版中的详细信息，极大加快了问题排查速度，也使问题对接流程更趋于规范化。

对效率提升的另一个方法是对反馈渠道的强管控，例如可以通过企业微信的群管理对强触达类消息做到强提醒。

由于开放平台业务的特殊性，我们是通过个人微信进行对接的，群里包含了运营，产品，第三方对接人员等等，涉及人员较杂，无法有效地对对接群进行一个管控；经过讨论，目前我们已经把对接群转移到企业微信上面，作为群主，便可实现对反馈渠道的一个强管控，比如说可以通过发布群公告、通过置顶的方式做到一个强提醒，这样在遇到一些紧急问题的时候，就可以及时通知到开发者，快速地进行一个信息的传递和同步。 

此方式是针对开放平台的特殊性所做出的提升效率的行动，但万变不离其宗，TS也可以在自己所负责的领域采取针对性的方式对对接群进行管控，以实现效率提升的目的。

例如：开放平台自主发布文章编辑器、接口测试工具等。

开放平台官网的文档也是沟通开发者的重要方式；由于之前开放平台要发布文档的时候都需要H5进行发版，因此无法实现及时地更新文档，解决问题的效率也会大打折扣；针对此种情形，从开放平台本身出发，提升核心硬实力，新增了可以支持自主发布和随时编辑文档发布的功能，这样当TS在问题对接中发现最近有某个或者某一类问题咨询频率较高，就可以及时通过此文章编辑器进行更新，从而减少此类问题的咨询量，告别低效率。

在此举个例子，在通过和开发者对接中发现了开放平台API文档中的接口名称与接口详情描述不一致的问题，是可以通过文档优化解决此问题的，因此我对开放平台的100多个接口都进行了修改，从根源入手，杜绝此类问题的咨询；另外，也同时也对接口文档的入参中添加了时间戳必传的提醒，这样也可以避免无效排查，降低一定的咨询量。

与此同时，开放平台也增加了接口测试工具，就比如之前咨询占比比较大的验签问题，我们可以建议开发者先通过我们的测试工具自主排查验签问题，测试工具里面会有一些代码的Demo可以帮助开发者进行问题排查，这样也提升了一个解决问题的效率。

数据本身是无用的，除非我们从中可以获取到有价值的洞察。

假如数据是钢，分析便是铸造的工具，而我们想要制造出一件好兵器，二者就缺一不可。

倘若其中存在一个短板，我们就可能因为一件烂兵器而死在战场上。

在做复盘之前，我们可以对收集的线上反馈问题的数据进行分析和拆解，从而可以清晰地看到什么类型的问题占比最大，最近几周或者几个月是否有上升或下降的趋势，问题所涉及业务域的占比趋势，问题总量是否有所变化等；

就比如在得物开放平台，我们对开放平台的线上问题拆分出了大致15个问题类型，比如说有规则讲解，接口报错，优化体验，流量申请，签名问题等。

如下图所示： 

在对DOP问题类型进行拆分后，经过分析便可发现一些值得我们思考的东西，比如说什么类型的问题占比最高，占比高的原因。

举个例子，下面这张图是我整理的6月至7月的DOP线上问题类型的趋势图:

从数据图中可以看出，占比最大的则是规则讲解类的问题，但同时此问题类型的占比在最近几周下降的趋势也很明显，那如何降低这类问题的占比也是一名TS需要思考的。

首先，我们可以先将规则讲解类型的问题进行汇总，对问题描述归类，发现其实大多都是一些咨询类问题，比如说入驻咨询，开发者类型的选择，如何进行授权，API调用接口报错以及业务讲解的问题等；因此我们发现可针对性地对此类问题发布一些FAQ文档，比如目前在开放平台文档中心里发布的常见问题FAQ，包括入驻问题、授权问题、API调用、通用报错、消息订阅、业务解答、异常码、商品编码等；这样运营或者产品便可在技术对接前指引开放者先自行参阅文档，之后再与我们进行对接，这样也能在一定程度上降低规则讲解类的占比。

后续我们也对此做了问题数据分析来判断是否该问题类型占比的下降与我们最近的改进建议有关，例如在发布文档之后，经过数据分析观察，DOP开放平台近几月的规则讲解类型的同比趋势是呈一个下降的趋势的，已从80%降到了32%，这也证实了我们对此类问题采取的措施是得到了正向的反馈的。

下图是近几个月DOP开放平台线上问题“规则讲解”类型占比趋势分析：

其实大同小异，无论是在DOP，还是在交易，商家后台业务域，对问题类型进行拆分都会让我们可以更加直观地观察到存在的问题，开发者最关心什么问题，从而针对性地解决问题。

同时，通过发布和优化文档，既可以在面对咨询时做到快速支持，又可以增加自己对业务的理解，从而降低此类问题咨询量。 

得物开放平台所涉及的业务域较多，除了问题类型细分之外，对DOP开放平台线上问题所涉及的业务域的拆分也会让我们获取很多有用的数据，通过数据可以思考，问题涉及业务域的问题占比是否出现波动，是否有某个业务域问题持续占比最高，为何占比会高等；

举个开放平台的场景，我们这边大致对问题分为了14个业务域，比如订单正逆向、出价和库存、商家后台、商品、供应链、跨境、第三方、平台相关问题等。

下面这张图是6月至7月DOP线上问题所涉及业务域的分布占比情况：

从图表分析，平台相关问题的占比最高，在中间也达到了约52%的高占比，因此我们对该阶段的一些行动和所做的变动都进行了研究。

发现在此时间点，开放平台对个人特权卖家开放进行了推广，因此个人特权卖家在此阶段的入驻量呈一个剧增的趋势，个人特权卖家咨询量也呈直线上升，在此我们统一将个人特权卖家的咨询问题归类到了平台相关问题里，平台相关问题主要包括平台业务、平台限制、平台规则、平台入驻、审核咨询（开发者、应用、权限包、ip白名单等）、授权问题、流量问题、签名问题等。

针对此问题，我们随即发布了个人特权特权卖家的FAQ，专门为个人特权卖家解答相关问题，与此也在官网发布了个人特权卖家入驻指南；同时，也和产品一同发布了业务调用讲解的文档，比如现货业务、极速现货、跨境等，通过接口进行库存管理，订单拉取，抑或是发货的描述。

通过以上行动，目前个人特权卖家的问题咨询量已降低80%，业务域平台相关问题的占比也在呈递减的趋势。 

除此之外，其实数据分析还包含了开发者入驻量环比、授权商家数、接口调用频次等，我们可以通过不同的数据类型分析出更有价值的东西，可以分析出某类问题趋势是否和外界因素有关，是否为共性问题等；而我们通过数据分析对DOP提出的改进和建议点的相关需求也会汇总至DOP需求池来推动问题的解决进度，同理，此方法也适用于其他业务域。

总之，不能解决问题的数据是无用的数据。

我们应善于用数据说话，来阐述事实，而我们统计的数据也并不仅仅可以反映出问题现象，更要揭露出问题本身存在的不足和背后的潜在问题，从而对其合理规划，采取有效的措施，解决问题，提升自主处理问题的能力。

复盘就是把之前做过的事情或者出现的问题，重新带着一个审视的视角对此进行回顾、分析、思考、反思；主动思考问题来源，为什么会出现此类问题，如何解决，并从中提取和总结出有价值的经验和方法论，从而提升办事效率。

复盘是工作中必不可少的一环。对于TS，通过复盘，可以对近期线上反馈问题，通过数据分析、体验优化等方式，在研发和产品之间做到一个高效沟通者的角色，提出相关建议和需求并对此推动跟进。

为什么要做复盘呢？因为在DOP，TS是处于开发者、研发，产品之间的一个桥梁，在对数据分析之后，最终要输出到产品和研发层面，形成一些需求和改进点，然后对此进行推动、跟进，并落地，这个在整个复盘过程中还是极为重要的，这也是一名TS自我价值提升的一部分。

复盘流程：

回顾上次复盘的待办事项和跟进情况->对接问题数据结果和分析展示->数据分析和重点问题思考->TS需求/对产研的建议->复盘总结、落实、跟进、整理进需求池、形成会议纪要，定时跟进。

目前DOP会在每两周举行一次复盘，大概的复盘流程就是，先回顾一下上次复盘的待办事项和跟进情况，比如哪些需求已经上线了、哪些还没有做、是否已提需求等，然后是对问题数据的分析和展示，其次是对数据分析中产生的重要问题，大家会一起对问题进行讨论和思考，形成相应的解决方案；接着是TS提需求以及对产研的建议，最后是对复盘进行总结、落实、跟进、并把复盘会上讨论出来要去做的需求整理至DOP需求池，同时形成会议纪要，定时进行跟进；这便是整个DOP复盘的一个大致流程。 

其次，我个人认为做好一次复盘，需要我们在复盘上的每一个讨论点都要有所结论，并要确定相应的跟进人，所有的代办都要有deadline；对于短时间内无法解决和实现的问题，也要确定出临时的解决方案；比如线上只有个例反馈的问题如何解决，优先级不高的问题如何解决，线上爆发的大面积问题如何解决等等，这些都需要在复盘上拿到一个结论和解决方案。 

这边举例说明一下，针对DOP开放平台开发者反馈的调用超限短信通知手机号修改的问题，由于目前反馈量占比较低、优先级不高，经过在复盘会上和研发、产品的讨论，针对个例目前的临时方案是通过邮件做审核，然后由研发处理修改；倘若后续反馈量增加，再由开发在开放平台管理后台增加修改入口功能；言而总之，复盘就是: 

1. 对目标的回顾;

2. 对当前结果的评估，评估时只讲述事件，不分析原因，只描述事实，不阐述观点；

3. 结果展示后，对问题进行一个分析;

4. 进行总结和跟进。

以效率提升作出发点，以数据分析作切入点，以复盘作着力点，实现从问题反馈到改进优化的一个闭环，是TS提升自主处理占比的关键法宝。

简而言之，TS作为开发者，产品，研发之间沟通的桥梁，要提升自主处理占比，不仅需要熟悉业务域业务、熟练掌握和使用各项排查工具，跟进业务域体验优化，做好本职工作；其次，TS还可以通过对问题进行数据分析，并提炼出来改进点，对业务域相关问题主动进行输出，进一步减少业务域出现的问题点；另外，TS在对问题进行复盘分析后，可以形成需求文档，并赋力参与相关业务域的优化和产品设计，从而实现自我提升。

除此之外，TS还应深刻理解业务域的业务和规划，能够站在用户和开发者的视角来思考产品的业务逻辑，不仅要提前了解和熟悉业务迭代的一些需求，也要了解业务域相关稳定性内容，并能及时发现稳定性相关问题并跟进，向前一步。