互联网产品上线后，应如何对待用户的反馈？

用户反馈是个即苦逼又有技术含量的大活啊，

上线一年半的时间里，获得超过10万的团队使用，其中有一个非常重要的工作就是做好用户反馈与用户支持，将这两年的经验做个总结分享给各位哈

先来看看问题在哪里？

其实，能够进行反馈的渠道是有很多的，Support Email、QQ、自家社区、微信、微博等渠道可供用户们进行反（tu）馈（cao）。

既然有这么多的反馈渠道，为什么用户的反馈还是容易被忽略呢，得不到有效的解决呢？小编特地深入民间，了解到原因可能是以下几点：

1. 用户反馈类型较多，不能及时进行有效的归纳整理

2. 用户提到的反馈，不能立即找到相关负责人解决

3. 反馈渠道较多，运营人员较少，不能在各渠道进行有效的切换，用户反馈被遗漏

在Worktile 我们是这么干的

首先，我们会利用Worktile创建一个关于反馈的项目，将项目下的列表设置成用户对我们的web和移动端提出的反馈，然后，只需要将来自各个渠道的反馈分别添加至相应的列表下。

补充一点，用自己的产品解决问题很重要，因为自己也是产品的重度用户，将自己团队的体验分享个产品部门是很重要的

同时对这些任务添加主要负责人

，比方说：对用户提到的建议我们就会添加产品经理关注，而有关BUG的问题则会添加我们的工程师们~除此之外我们还会定义标签，对各反馈的类别（建议、咨询、BUG），来源（社区、后台、QQ等）进行划分，这样在每月对用户反馈进行总结的时候能够有效的分类汇总，节省沟通成本，并最大程度的更新信息。

每条反馈，我们也会以添加任务详情的方式记录下反馈用户的信息，记录到该项目的反馈文档中，并以周为单位对这些较为活跃的用户进行回访：

通过这种方式，让用户的反馈第一时间共享给负责的同事，并有效的进行跟踪，得到解决。但是关于第三点，确实是一个挺头疼的问题，小编自己就深有感受，作为Worktile的一名小运营，当手头的工作略多的时候，就很难保证在各渠道上进行有效的切换。构建一套流程是多么的重要啊

构建用户反馈系统

我们的方式是使用

+

的工具组合，纷云最大的价值在于——第三方服务集成，我们可以将将各个平台（例如后台、社区、微信）的反馈进行聚集，沉淀。将意见与反馈分门别类，共享给产品的同学，最终将用户的需求呈现在产品中。

当任意一个平台上有新的反馈时，在纷云上都会得到消息提醒，这个时候，我只需要直接点击，就能登陆相应的渠道去跟用户进行沟通，并将所有的信息聚集，沉淀在纷云中，便于月度，季度，年度的总结。

除此之外，我们自己产品当然要更加紧密性福的在一起咯，在

，当在Worktile上对反馈进行了处理，纷云就会得到消息提醒，也就是说，只需要关注纷云就可以对用户反馈有一个实时的把控了

这是一些方式方法的分享，当然也是为Worktile做个小广告，但最重要的是在做用户运营的工作中要做到极致的细心，以及对产品的深刻理解，运营人员是产品与用户之间的纽带，将产品价值极尽可能毫无偏差传达给用户是运营最重要的工作，但用户反馈是一个倾听用户声音最好的渠道，我们可以通过这些反馈来推敲出用户的想法，探索出驱动他有该类想法或需求的真实原因。通过用户反馈找到需求背后的需求才是用户反馈最有价值的地方哈，这是小泽的一些分享，如果帮助到各位了请点个赞吧

1. 不管用户说的对不对，都要以很好的姿态倾听，并给予感谢和确认收到的反馈
2. 根据你的目标用户、目标用户中的核心用户来区分对待不同用户的反馈，重视核心用户、目标用户的反馈，对于非目标用户的反馈，慎重考虑如果听从是否会损害目标用户的利益和产品目标；
3. 挖掘目标用户反馈背后真正的需求；对于有些目标用户的反馈，可以进一步多沟通，更好地了解用户的想法。
4. 再根据产品的目标（长期和阶段性的）去排需求优先级

有时候，用户的反馈不一定通过正式的“意见反馈”渠道提出，也不一定在表达上明确说明是自己对使用产品的意见和反馈，这需要产品经理和运营人员关注目标用户可以表达的渠道，去关注他们对产品的声音。

产品上线后，用户一般会通过各种渠道来发出自己对产品的声音，这些反馈对于初创公司来说非常重要，如果能建立起良好的获取反馈的渠道，用户会十分踊跃地告诉你什么地方做得好，什么地方做的不好。

为什么要收集用户反馈？

收集用户反馈大致可分为两个目的：了解用户和了解产品。

1. 了解用户

通过用户反馈的收集可以对了解到我们产品的用户究竟是怎样一群人，是否跟我们之前的目标用户有所出入，他们的如何使用我们的产品，他们对我们产品的期望是什么，他们在产品的使用过程中碰到了那些问题，有哪些“痛点”。

2. 了解产品

我们的产品有哪些bug，我们的产品哪些地方做的还不够好，为什么不够好，是因为功能还是体验或是其他，用户针对这些体验的不好的地方给我们提了哪些建议，怎么利用这些建议来让我们的产品做的更好。

从哪里收集用户反馈？

用户反馈的来源大致有如下渠道：

1. 产品后台

2. 产品论坛

3. 社交网络（QQ群，微博，贴吧等）

4. 第三方下载市场（豌豆荚，360手机助手，百度手机助手，应用宝，淘助手等）

如何对待收集来的反馈？

个人认为对待收集来的反馈要经过四个步骤：分类——提取——转化——实现

1. 分类

收集到用户反馈基本上可以分为三类：

• Bug 如xxx功能无法使用，xxx功能没反应，xxx功能失败…
  
• 吐槽 如xxx太烂了，xxx你不能这么无耻，烦！xxx赔偿我xxx损失…
  
• 建议 如希望出个xxx功能，建议增加xxx功能，可以参考一下xxx的xxx功能…
  

2. 提取

• Bug
  

分辨出哪些是需要马上修改的，哪些是值得关注的，一般需要进行优先级的划分，分清轻重缓急。

• 吐槽
  

分析用户吐槽背后的原因，思考有什么方法能减少负面反馈，总结出来如何避免同样的错误。例如产品的某个功能让用户不爽导致用户在论坛上破口大骂，除了找到让用户不爽的原因之外，你还需要思考用户为什么要来论坛发泄，你通过什么样的设计能让用户在应用内发泄不满，从而避免负面影响的扩散。

• 建议
  

如何通过深入挖掘把建议转化成需求？从哪能找到更多高质量的反馈，有什么好的途径？在对用户反馈分析的时候，我们探寻的并非“是什么”而是“为什么”，只有当我们明白用户为什么想要它时，我们才能意识到他们究竟想要的是什么。

3. 转化

主要分为用户和产品两个方面。

• 用户方面
  

通过分析这些反馈，用户同设想中是一样的吗？你建立起用户的心理模型了吗？你了解用户的期望是什么了吗？你找到用户的痛点了吗？

• 产品方面
  

你是否熟悉了产品的每一个细节？你是否知道产品有哪些bug，哪些体验不好的地方，你是否找到了解决方案？你是否对产品的发展方向有了清晰的把握？

4. 实现

把从用户反馈中提取到的需求实现，对现存的问题进行改进，迭代，创造一些少数用户真正喜欢的东西，如果你能使得100个用户爱上你的产品，你就有机会培养出一个庞大的用户群。

用户反馈很重要，但却不能迷失其中，要学会挖掘反馈背后的原因。用户是贪婪的，如果你听从并推出了功能a，那么用户接着会向你要求功能bcde，直至把产品撑死。一千个用户就会有一千个哈姆雷特，当你面对成千上万个哈姆雷特的时候你要学会区分“what they need”和“what they want”的区别。

在面对用户的谩骂的时候学会坚持，因为说不好的永远比说好的多，而沉默的永远是大多数，如果在谩骂声中屈服，伤害的不仅是用户而且还是产品。

无论用户对产品是赞扬或者谩骂，产品团队都得以平常心对待。毕竟还值得欣慰的是，这证明产品还有许多人在意和关注。真正需要绝望的是那些无人关注，没人骂没人理的产品。

个人认为，处理用户反馈可以分为以下几个步骤：收集——整理——转化——实现。

而这个过程中，关键要素不过是人和事：1.“反馈是什么”；2.“谁来判断&处理这些反馈”。

理想的效果应该是：能够快速地搜集到不同渠道的反馈，并且将反馈进行整理、分类，然后根据反馈的不同情况由不同的人来进行处理。

然而现实往往没有这么理想。这里面收集整理的工作量大不说，由于还牵涉到产品、测试、开发这些部门，要把整个流程 run 起来也有很多阻力，这种情况下借助一些工具能协助我们把流程建起来，并且由工具处理一部分人力的工作。

以收集应用市场反馈为例：

我们来看个一个App产品在研发管理中，管理应用市场反馈的实际场景，以及这个场景是如何在 ONES Project 上实现的：

1.想要得到客户在应用市场反馈

2.及时将反馈处理成Bug或是新功能建议

3.能根据不同情况分派处理人并跟踪处理情况

4.重点关注1星评价内容

5.要第一时间看到评价评分的趋势舆情

6.细化到各个版本的评分质量

我们用 WPS Office iOS 版本为例（这些评论数据都基于 AppStore 公开信息抓取，涉及人员为模拟用户名）

1.首先我们通过爬虫 API 指定爬取 AppStore 里面 WPS Office iOS 版本的评论数据。（划重点：不需要人工搜集）

2.然后我们定义一套我们关心的评论数据属性，比如评分，评论内容，评分版本等。（这样可以极大地方便后续的整理工作，把希望找出来的属性通过筛选器一筛就是了。）

3.我们定义有几个角色的同事会关心这个评论，比如产品经理，测试工程师，客服运营，项目经理。

4.通过自定义工作流引擎，建立一个重点关注 BUG 修复情况的反馈流程。这个解决了不同部门之间的协作问题。（流程可以根据你团队的实际情况去配置）

5.我们认为这些角色有不同的权限，比如只有测试工程师才有权限确认一个客户的反馈是 Bug。

6.项目经理会关注不同版本的评分分布情况，并需要报表来展现。

7.产品经理还需要重点关注一星评论，到底是什么原因导致有极端不满意的客户。（把1星的评论筛选出来）

8.把各个报表卡片、一星评价卡片、重点关注的几个数字Pin在仪表盘主页上。

在这个过程中，ONES Project 不仅能够实现自动抓取评论，还能自动整理评论，并且通过自定义的工作流实现评论的自动流转，重要的评论可以流转到产品、测试、研发的手上，随时筛选重点评论，并且生成版本评分的报表，对评分情况实现实时监测。

以及，ONES Project 支持私有部署。

以上是应用市场的例子，其他渠道的反馈同理也能实现，有问题欢迎讨论~

利益相关： ONES Project-敏捷开发最佳实践 | ONES

1 倾听并且迅速表示“已经收到反馈”

2 分析这些问题，有新需求、bug、不符合产品定位的预期

3 bug排轻重缓急，集中处理迅速上线，如果可以，在上线的时候告诉提出问题的用户已经解决了，这是个特别好的让用户感受到关心的机会。棘手的是：上线后本身要做迭代的需求还需要改bug，这一点要与开发进度、上线策略（时间、推广人群）配合好，不易

4 上面提到“不符合产品定位的预期”这样的反馈不应该抛弃掉，有点时候能发现好东西

快速迭代是让用户对产品产生好感的方式，大多数都是沉默的，大声的骂声未必是从最核心的用户那里发出来的，很多人骂骂就走，千万千万不能放大这样的声音，跟老大和运营沟通也很重要，运营是首当其冲感受到反馈的部门。

最重要：心里有数，对产品改版的目标坚持，时时检测正在做的事情是否为目标服务！顺道捡点金子反馈~

1：虽然用户的声音并不是特别的准确，但还是要去听，以改正那些我们认为相对符合预期的需求而完全忽略用户感受的地方。

2：对用户进行分众，在产品初期，预期产品的用户切入角色是什么，那么相对来说就要倾听这部份用户的声音不管多少，去应证产品设计阶段我们的预想的切入点是否正确，当用户反馈的需求和我们预期的角色有较大出入时，如何调整产品或者在运营阶段如何改进用户角色将起到重要的作用

3：针对产品的迭代，并不是所有产品都是靠用户的声音来迭代，而是产品必须满足大部份人的需求，用户的声音有大有小，采样的不同也可能造成很大的差异，更多的是去听，而初期的产品更多的是以数据来迭代，通过数据的分析来满足大部份的需求，同时可以兼顾部份的人需求。

1从用户反馈中提炼需求，挖掘需求。往往用户的一手反馈并不是真实需求，可以采用5W工具和用户访谈挖掘核心需求。同时兼顾用户体验以及产品定位，结合数据分析查验需求真伪，具体到某个环节，合理定量定性，罗列出需求列表。

2结合用户群体和产品定位，根据卡诺模型将需求划分为正向需求、期望需求、无差异需求、无差异需求和反向需求。优先考虑正向需求和期望需求进行产品选代。

3持续关注选代产品上线后的各项数据，观察效果，和用户反馈，优化需求列表，准备下一次产品迭代。

对于嗓门大的用户要做好沟通工作 但是最重要的是看用户的行为 大部分用户是否使用 怎么使用 这个决定了产品上线是否成功 及后续的改进方向

不论是互联网产品还是其他类型的产品，用户反馈收集都会遇到以下集中情况：

1、反馈渠道五花八门，常见的反馈渠道有：qq、微信、微博等，渠道多顾暇不及，有不少会遗漏

2、用户反馈量大，很难get到问题的关键点，工作量大

3、反馈处理后，没有合适的通知机制，用户接受信息滞后，用户对产品的感知差。

对于产品团队来说，用户反馈要跟进，产品体验要优化，但问题也确实是让人头痛，但在 吐个槽用户反馈互动社区，可以轻松解决这些问题。

——————————————————————————————————————————

1、收集——选择一个靠谱的反馈渠道

吐个槽帮助产品团队快速搭建一个专属的用户反馈渠道，解决了团队自主研发创建的难题，接入就能使用，且对所有用户免费开放，支持微信公众号、QQ公众号、APP、H5、web产品接入。

现在接入的产品如：腾讯视频、腾讯课堂app等

2、分类处理，聚焦重点问题

吐个槽能对用户反馈进行分类设置，支持产品经理根据产品实际情况进行预先分类设置，设置不同的标签引导用户进行反馈，让用户更好反馈问题，后期导出也能快速聚焦问题所在。

3、重点展示热门问题，快速解决问题

产品经理将产品高频出现的问题进行常见问题设置，让用户既能在第一时间找到问题的答案，这样也让整个反馈更有效，减少被同一问题刷屏的概率，产品新功能上线、产品改版等常见问题点都可以一一展示，产品经理事半功倍。

4、用户信息收集，追踪定位问题

在吐个槽，产品经理可根据产品的实际情况选择对不同的用户信息进行收集，微信、QQ、邮箱、电话号码都可以，这样一来用户获取产品回复更方便，而产品经理也能更好地对问题进行追踪定位。

5、微信实时通知用户，用户感知更强

吐个槽微信提醒功能有效帮助产品经理触达用户，普通用户无需关注公众号，第一时间就能收到产品经理的回复提醒。产品与用户沟通便捷、快速，用户对产品的感知更强烈。

6、双后台管理，PC、mobile随时随地掌控用户反馈

吐个槽不仅能在PC端对产品进行管理，还支持产品经理在移动端管理用户反馈，只需配置移动端权限，绑定微信即可在手机上处理用户反馈信息，可谓实时掌控用户的反馈动态。

——————————————————————————————————————————

不得不说，作为一个新型的用户反馈平台，吐个槽的确是产品团队的福音，解决了不少用户的痛点，虽还有些功能不完善，相信会越做越好。

除非非常棒，用户可能会赞；如果一般，能满足使用，用户多数沉默；直到实在影响正常使用了，用户会站出来大骂，如果不是被冤枉的，那就赶紧改吧~~~还要全心全意为用户提供骂的途径，尽量把用户的骂声只收在自己的耳朵里~

首选用户反馈听还是不听呢？听的话怎么听，听什么，听多少？

听：听用户的反馈，但是不听用户给你的解决方案。

整：把用户反馈的信息进行整理分类，按照数量进行排序，找到集中的问题。

研：通过用户调研的手段（定性/定量等调研方法），挖掘问题的本质。

定：明确了需求之后，再去看竞品或者其他行业如何解决，找到灵感，最后思考解决方案。

验：上线后，跟踪数据，做数据对比，再次通过用户反馈和调研，验证自己的解决方案是否有效。

最后循环往复，快速迭代。

人的心理活动是非常复杂微妙的系统，最后的反应只是一个结果，中间转了多少次弯你根本没法知道，甚至真话假话你根本没法知道，用户自己有时候也没法知道。

很多时候做需求调研或者用户使用反馈，接收到的信息是一方面，更重要的是对于调研人员的选取、接收信息的筛选、信息真实性的辨别以及对于反馈的处理等，这些更加考验调研人或产品经理的功底。

前期调研和后期反馈其实是两个遥相呼应的阶段，在产品没有做之前，了解需求，根据需求形成产品，产品上线后去调研使用反馈，大体上可以看做一个闭环。

最理想的情况是需求输入—产品研发—使用反馈—产品迭代。看着简单的四个环节，运行起来却并不简单，尤其在B端或者产业领域。因为B端产品一大特点就是决策者和使用者的差异。

从决策者那里获取到的需求输入，如果贯穿到产品研发中，往往不能契合，因为决策者不是最终用户，而且决策者和使用者的角色差异以及对于产品的期待价值都是不一样的，这里的人员选取如果混淆或者把握不好，往往会让自己的产品走上歧途。

我经历过也见过很多产品，在前期调研的时候需求方说怎样怎样就可以解决我的问题，于是包括我自己在内的很多产品经理都按照用户说的需求去实现，可能觉得这下肯定没错。

但现实往往不会如想象那般美好，产品做出来后，用不用是一方面，是否合适又是另一方面。曾在一个听别人介绍自身产品的场合下，对方说现在的产品其实都是之前和需求方调研好的，但做出来还是反馈了这么多问题。

对方的领导说其实这也和产品经理的能力有关，好的产品经理做出来不能说没有问题，但可能不会有这么多。言外之意就是产品经理对于调研方式的选择以及信息的筛选会影响对需求理解的深度以及贯穿全链条的顺畅度。

前面我们说过角色不同带来的差异，那么即使是同一个用户，其前期所说和后期所做之间也会有偏差，如同本文开头所提到的，人的心理活动是非常复杂微妙的系统。

当你没有一个具体的方案而是希望通过调研去找答案的时候，单纯的调研和了解不一定会给到你百分百的支持。因为对方反馈出来的信息，需要筛选和辨别，是否能完全抽提出有效信息，需要时间需要精力更需要功力。

沟通是一门艺术，虽然对用户的调研和回访是一件本该坦诚沟通的事，但很多时候并不会所听即所得。为了照顾气氛打破沉默，为了一些原因回避真实情况，甚至就是为了避免尴尬而变换说法，这些都是没法预知但却经常发生的事。

之前写过一篇《 做B端产品：比捋顺业务更难的是捋顺人》，其实很多时候是管理的问题，却要求产品经理做一个产品来解决，本质是管理问题而不是工具问题，所以这个产品也做不好，也无法理解做这个产品的真实需求。

在产品早期的时候去问不用这个产品的人为什么不用很可能是一个无效的方法，真正有效的方法是问那些用了产品的人，这些人心里是有一定认可度的，且在使用的过程中遇到了问题。

对于没有用过产品的用户去做调研，对方可能出于礼貌或者为了避免尴尬而搪塞敷衍一下，但所说的内容未必是真实情况，如果把这些敷衍当成了真正的改进点，会浪费很多时间和资源。

最近遇到的一个问题就很好的印证了这个情况，进行用户反馈调研时，用户所提供的信息和我们了解到的有很大偏差，猛然看到这个结果还以为是走错了方向，但二次确认和多方面证实，才知道反馈不真实。

因此遇到这种情况时，一开始就要找真实使用过的人群，使用过的反馈才更贴近真实，很多时候，客户或者用户是愿意诚心诚意和你一起解决问题的，前提是找对了方向，用对了方法，这样才会更加顺畅一些。

不要单纯听到什么就去做什么，身处喧嚣之中，独立思考和深入分析很重要也很必要，做产品如此，处世亦如此。

做了很多年运营后，对于用户反馈的认知经过了以下几个阶段的变化：

• 第1阶段：见自己，依靠个人能力解决问题；
• 第2阶段：见天地，建立制度流程解决问题；
• 第3阶段：见众生，理清利益生态解决问题；

第1阶段的表现是什么？

1. 通过个人对于用户反馈的代入认同，驱动问题的解决。
2. 这个阶段要做的很出色，需要个人保持尽责、倾听、跟进、耐心。
3. 优点是，在产品用户量级或反馈量级较少时，可以与用户有良好的互动和相互认同。
4. 缺点是，当产品用户量开始增长，在处理反馈的效率和数量上落后于产品的发展。

我是客服出身，当我最初转向运营后，就处在第1阶段。这个阶段里碰到每一个用户反馈过来的问题，都会仔细去看去感受。然后基于同理心尽心尽责的跟进到底。通过创建Excel表，记录着跟进情况，当每解决一个问题时，都会感觉很有成就感。

但是过了一段时间发现，这样自己很累，能解决的问题有限。因为在腾讯，随便一个产品，用户量级都很可怕。那么我就开始寻求更好的办法，所以开始过渡到第2阶段。

第2阶段的表现是什么？

1. 通过反馈渠道的拓展，内部各部门协作处理流程，科学的规划来批量解决问题。
2. 这个阶段要做的出色，需要对于流程不断的完善和监督，确保每个环节运转无阻。
3. 优点是，可以更科学更高效的批量解决用户反馈。
4. 缺点是，执行时间长了后容易流于形式，脱离用户实际，流程运作取决于部门利益。

在第2阶段，我开始使用一些项目管理工具，开始健全各个渠道的反馈机制、收集处理流程。也开始通过数据分析从更高角度去看待用户的反馈。这个时候注重部门内部对于用户反馈的协作处理，同时也更注重数据分析得出的问题轻重缓急。

虽然这个阶段解决一个问题就能让很多用户受益，但是，这种方式开始远离用户，开始变得滞后，问题的解决开始局限于部门利益。此外，反馈问题的用户永远都是少数，那么大多数的用户真实情况如何，你并不能完全确定。

怎么样才能避免头疼医头以及脱离用户实际利益呢？所以我开始向第3阶段过渡。

第3阶段的表现是什么？

1. 通过反馈本身理清用户关键利益点，并由点到线带面的将关联的产品功能、规则修剪。
2. 这个阶段要做的出色，需要对当前产品用户生态的内在逻辑和关键外在规则非常熟悉。
3. 优点是，非常容易完善出产品调性、生态，会让用户有惊喜，发自内心的赞同。
4. 缺点是，容易与产品立项初衷不一致，方向上没站稳，容易做成小众产品。

在第3阶段，我开始又回到反馈本身，开始关注反馈背后的利益、情绪，以及某个点前后纵深的行为链。

这里可能比较难以理解，举2个例子：

一个是我之前做《大明龙权》，一款2Dpk的RPG游戏，当初游戏设定了很多玩法，比如但是到后面用户实际并没有按照策划最初的规划去玩，而是自己形成了一套自己的获取收益以及打架的玩法。当我摸清楚这里面的内在逻辑和利益后，按照现有的生态去对版本里的功能和规则进行强化和修剪。

一个是我最近做《暴鸡电竞》，一个电竞游戏陪玩的产品，在产品初期时，我观察到打手以强者为尊，自己能打什么范围的段位，拿多少钱，难打的单怎么组队完成是有内在的价值观的。而对于下单用户来讲，找什么样的打手，打什么位置，带不带朋友，是关键局还是普通排位都会对打手造成不同的实力的期望。

那么最后就是围绕这些内在的东西，构建了双端用户体系，版本上则体现在打手分级及车队上。

这2个例子，一个在产品末期，只是满足了小众核心的用户；一个则在产品初期就定下了基调，后进的用户也更容易理解这套生态。

1.主要看他们产生的数据反馈，其次再听其笔头口头反馈，前者更重要。

2.一次只修改三个最重要的bug，然后快速迭代