技术支持是产品研发和用户之间沟通的桥梁，是最高效的适配器。既能把用户信息地道的声音传递到产品和研发 ，又能对这些信息进行运营，从而更科学高效地彻底解决用户问题，反映出产品质量！

技术支持岗位连接客户（内部的和外部的）和产品研发，是一个信息的交汇点（此处请原谅我的略微突兀的hightligt）。即输出又输入信息，输入输出之间的转换是这个团队的立足点。

有些公司的岗位名称也叫“技术客服”。我个人其实更加偏向于技术客服这个名称，这个名字更贴切一些。不过同学认为“客服”不够技术，不够高端，额，这个思想其实万万要抛弃，一旦认为这个岗位要“技术”和“高大上”，可能在以后的工作当中会出现动作变形和不到位的情况。服务好用户（不论是内部用户还是外部用户）都是这个岗位的天然职责，把职责做到极致才是最重要的，名称可能不太重要。

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

• “真没问题”。

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

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

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

    技术支持针对用的这种反馈，在做了各种排查分析以后，发现这个可能真是产品设计缺陷或者线上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。