技术支持----用户和产研沟通的桥梁

引言： 在这个互联网的大海中，技术支持就像是连接岛屿的桥梁，不仅要传递信息，还得确保信息不变成“捉摸不透的密码”。我们的使命？将用户的反馈和需求转化为能让产品和研发团队“恍然大悟”的洞见，同时还要像变魔术一样，让问题消失！

技术支持的真正角色： 想象一下，技术支持就像是一个拥有超能力的适配器，把用户的“我有问题！”变成研发团队能理解的“我们有解决方案！”。这里的技术支持，不仅是信息的输入和输出专家，更是一个将信息转换成有用洞见的高手。有时我们被叫做“技术客服”，听起来可能不够“高大上”，但别忘了，我们的魔法在于服务，把每个“额，这是什么问题？”变成“啊哈，原来如此！”。

面对客户反馈的高明策略： 当用户反馈出现时，通常有两种情况：“真没问题”或“卧槽，真有问题”。在“真没问题”的场景中，技术支持就像是一个翻译家，把产品的功能和理念重新解释给用户，确保他们不再“懵逼”。而在“卧槽，真有问题”的紧急情况下，我们的任务是先安抚用户，提供临时解决方案，同时迅速通知产品和研发团队，避免用户再次拨打我们的热线进行“友好拜访”。

用户反馈的信息的两种情况：

• “真没问题”。

     产生这类反馈的原因是“横看成岭，侧成峰”，不同的人对产品有不同的理解。客户的理解跟产品设计者想要表达的导向一旦没有完全吻合，这个时候客户就可能会“懵逼”。焦躁的客户这个时候就会通过一些渠道反馈到技术支持。特别是一些“专业用户”，譬如本身就是互联网行业的从业者甚至本身就是产品经理。

遇到这个情况，技术支持人员的任务就是把产品的功能，甚至理念重新“翻译”给用户。其实就算是再“专业的”用户，技术支持同学也不要害怕，因为最了解产品的毕竟是我们，内行看门道，组织以外的人对于内部产品定位和导向未必能够理解的如自己这般透彻。

• 另外一个是“卧槽，真有问题”，

    技术支持针对用的这种反馈，在做了各种排查分析以后，发现这个可能真是产品设计缺陷或者线上Bug。并不是用户操作问题。

这个时候技术支持人员需要立马做以下两件事情

1，对外，安抚用户，同时提供一个临时措施，尽量减少对用户的影响。这一点要形成思维定式，第一反应。否则一旦被产品和研发的思路牵着走，看能用户那边已经无数遍地问候了我们。

明确地告知用户我们已经有人跟进这个事情，有进展了会同步用户。同时告诉用户当前这个情况可以采取哪些临时措施（如果有的话）规避这个影响。如果没有临时解决方案的话，则告知用户我们的研发和产品已经在排错了。

这个地方有两个意图，

• 1，用户是对的，确实有问题，没有乱报问题，用户得到了肯定一般情况下情绪会平复很多 
• 2，我们已经在跟进处理了，让用户知道问题正在进展，会解决掉这个事情。让用户心里有底，情绪不在处于蹦蹦跳跳的状态，安静安心下来，等待结果。

2，把问题反馈给对的产品和研发人员进行处置。

快速准确一般要做到两点：

• 找对人，跟这个产品相关的产品负责人，以及做这个功能的产品研发甚至运维和基础架构。
• 说清事儿，用户的原声以及先对技术化的语言说清楚当前发生了什么，并且告诉已经做了哪些排错。

    很显然，不论是“没问题”还是“有问题”，这些信息都会交汇到技术支持这里。只要用户发起了求助或者反馈，那这个产品本身可能就是有问题的起码是不完美的。“有问题”的，进行跟踪复盘。所以，需要把这些“有问题”和“没问题”的信息都做汇总和分析。并把相应的数据出给运营或者相应的产研团队。

不过有一点其实还是要注意的，“没问题”和“有问题”之间并非完全隔离开。“没问题”可能是指代码和产品需求文档没问题，但是不代表用户觉得这个产品设计的“脑残”，那这个“没问题”就是真问题。毕竟用户最知道自己要什么，他们才是使用者。

    技术支持一定要充分利用用好信息交汇点的这个位置，彻底解决和提高产品使用体验，如果只是单纯地做回复和反馈的操作，可能会浪费了这个黄金位。

技术支持的隐藏宝藏： 技术支持团队不仅仅是问题解决者，更是一个潜在信息的宝藏。我们需要挖掘那些用户“懒得提”的问题，因为这些隐藏的问题可能是提升用户体验和产品质量的关键。技术支持团队需要成为多面手，通过各种渠道收集用户的反馈，从而提供更有价值的洞见。

                      

      如果是用户量很大的互联网公司，用户反馈的量大概率也会比较大。这个时候可能还要做用户运营的工作。不但要解决掉已经提出的问题，尽量还要挖掘出来用户“懒得提的问题”（用户失望就久了，一旦出现替代品很可能就跟我们说byebye了），从而不断提高用户的体验。

       挖掘出来的问题，可能会有各种情况，譬如操作比较麻烦，这些如果解决掉可以提高用户的人效问题，提高工作效率。有些是产品的bug问题，这类的问题让研发及时优化掉，可以提高用户体验和人效。

    技术支持如果想更好地发挥或者利用好这个卡位，需要尽量多地收集用户的声音。开辟各种渠道来帮助用户解决问题。渠道运营地越好，会有越多的用户反馈。用户的反馈就意味着信息量越来越大，信息量越来越大意味着可操作的空间也越来越大，产生的价值也会越来越大。

   技术支持的关键行动： 技术支持的核心在于快速而准确地找到问题的根源。要做到这一点，我们需要两样武器：一是找到负责该产品的正确人员；二是清晰准确地传达用户的问题。无论是“没问题”还是“有问题”，我们都需要像侦探一样，把所有线索汇总起来，为产品和运营团队提供宝贵的反馈。

   技术支持团队还是一个防波堤和缓冲地带。

可以避免研发直接解决用户的问题，打乱自己的工作节奏。因为75%的问题是不需要研发介入就能解决的。技术支持既能快速给用户反馈又能让研发安心做自己应该做的事情。其实从成本上来说，一个研发的成本要远远高于技术支持，如果研发处理了75%的没问题的问题，那么从成本是来说不划算，而且这个研发也可能感觉没有成就感，会暴躁，有离职的风险。

技术支持是一个公司产品质量的透视镜。

因为每天接触的反馈信息各式各样，大部分是“负面信息”，把这些信息做好整理分析，把产品问题充分暴露出来，通过这些暴露出来的信息推动产品持续改进。

 技术支持这个岗位一般不要求成员有代码能力。但是现在是一个信息化时代，如果成员有代码能力可以尝试自己做一些工具提高自己团队的人效和缩短反应时间。这样整个团队的战斗力会更加强大。做成一个合成营这种形式会更好。

请记住一个血淋淋的事实“跨部门沟通真的很难”！不能只依赖研发来帮助做工具，技术支持提的需求一般会被认定为“技术需求”，给的优先级一般很低。研发自己的工作就很繁忙，很难顾得上给技术支持开发各种工具或者跑各种数据。还是要让自己的团队多一些战斗力和技能，而且自己的需求在自己的团队完成，结果不容易变形，更加能够反映自己团队的真实业务需求，谁能比自己更加了解自己的需求呢。

结尾： 总结一下，技术支持不只是解决问题的英雄，还是沟通的大师和信息的挖掘机。我们的工作远远超出了日常任务，通过充分利用这个独特的位置，我们可以为公司提供无价的洞见，推动产品不断进步。

如果您觉得上面的内容能够对您有一点点帮助，也请在下方进行讨论沟通或者私信我都可以，当然更希望劳驾一下您的金手指去转发一下，去帮助更多的小伙伴，多谢！

后面要聊的内容大概如下
1，这个团队对团队成员的从业背景的要求。很强的开发能力？各种技术troubleshooting很牛逼？嘴皮子能力？ DONE, 请移步 ​​​​​​技术支持同学，莫凭自己的实力让用户抓狂_altruismhaha的博客-CSDN博客用户是衣食父母，用户满意才是真的满意。先高效满足用户的需求，再考虑别的，即使你神通广大，但请满足用户为先！https://blog.csdn.net/altruismhaha/article/details/94473187
2，工作内容
3，团队KPI的思考
4，应该是一个合成战斗单元  DONE 请移步 技术支持团队应该是一个斜杠的团队_altruismhaha的博客-CSDN博客技术支持团队应该是个多才多艺的团队，除了提高团队生产力战斗力以外，还能够产生你意想不到的价值！团队成员很开心，有干劲有奔头，领导也喜欢。https://blog.csdn.net/altruismhaha/article/details/90707202
5，面向对象
6，提高效率项目实践--- 工单自动化，done 请移步 技术支持升级----工单自动化处理_altruismhaha的博客-CSDN博客

上面的内容像个欠条一直没有更新。最近打算还债了。给自己立一个flag。