|
编者按：本文来自产品经理社区 PMCAFF 的投稿。内容来自他们「PMCAFF 问答精选」栏目，由他们社区里的真实用户创作产生，PMCAFF 工作人员精选高质量的问答编辑成文。
产品经理圈一直流行着用户为王，体验至上的 “真理”，辣么对于用户的反馈需不需要第一时间进行呢？下面是来自奋斗在一线的产品汪们的良心回复，说不定会颠覆某些同学的把软文当教材，拿段子手当导师的三观哦。
@ 海躺 ：
一般性，没必要太当回事。而是要根据用户说的问题类型去分析：
1、BUG 类，反馈收到，并感谢，送礼等。
2、产品改进类，感谢，看不看随意
3、idea 类，一般性没啥价值
4、战略布局类，一般性不用看
虽然说是以用户为主心，说的是一个群体，也不是第一个人。往往用户给你反馈 2，3，4 其实靠谱的内容非常之少，基本上可以忽略无视。
为何这么说呢？
1、人家给提改进，idea，战略布局？他知道你们公司的情况嘛？
2、人家提了，真是合适你们团队去执行嘛？
3、人家提的，真的是最合适的嘛？
一般性用户很难给你很好的建议，idea,和战略布局，看了保持感谢就行了。如果真的好就放到需求列表里。
@ 萧明明 ：
如果反馈的问题的确是个问题就第一时间进行，反馈得很认真也进行。要是那些吐槽类的问题或者随便一句话的问题就不。嗯，用户是不是上帝。
@ 林维艰 ：
按我们目前指定的规则来说分 2 步走：
1、必须先反馈
2、分析后再给
补充：
1、反馈即告知用户收到、并记录下来，发送给高级产品经理或产品线人员，可以将此信息给用户看
2、分析这个用户的需求属于什么类型：理念、抱怨、功能 归类
产品经理先分析用户属于什么类型，系统使用者、决策者、管理员等，然后再对收到的需求进行分析，决策者属于关键任务，不管理念、抱怨还是功能类的，都建议接受。
使用者基本有抱怨和功能两类，抱怨多处于对系统用户体验上的改进，产品经理可以直接定义改进意见，功能类可以带来收益，要与研发分析后再确定实现方式
@ 凯撒 follwer ：
本小咖也做了一段时间的运营工作，经常用户把问题反馈到我这，我再和技术人员进行沟通。所以，对于用户反馈及不及时的问题，参考这个项目的需求文档上的记录，再具体的看。
首先当你判断该功能需不需要的时候，说明这个功能本身并非核心功能，它只是一个能让产品活得更好的一个点，这个点无非两个终极目的：盈利和用户引流，如下流程可以借鉴：
1. 判断该功能可行性，结合当前研发资源、盈利点分析、用户引流的情况做出一个取舍。（这一点如果你不是 PM，对程序是非常擅长，不要自己决定，先反馈给你的 boss，再客户。第一时间客户 “您的要求我们已经收到了，我会尽快给您一个答复；如果反馈的内容很多，请邮件沟通，不要 QQ，电话，等社交平台去聊，无意义。）
2. 如果该功能有尝试的意义，若研发资源紧，则排期靠后；
3. 如果研发资源允许，估算赢利或用户引流情况作为该功能指标，并在该功能各个重要流程做一些问卷调查或者用户行为记录；
4.上线后通过收集运营反馈迭代该功能。
@ 大白大白 ：
可以根据产品的发展阶段区分对待：
产品处于刚刚上线时候，一方面需要急切获取用户对产品使用情况，另一方面需要持续培养自己的忠实用户，所在在这个阶段应该快速用户给产品的各种反馈，不管是好的还是坏的，都应该认真处理。毕竟是自己产品的用户。
如果产品处于有一定的活跃用户，目标不再是获取新用户的时候，这会忠实用户的意见反馈可能会更重要，所以，这个阶段应该保持和忠实用户的联系，听取他们对产品的意见，认真考虑。
@ 夏阳 ：
我反馈了你没有：你到底收没收到我的反馈啊，你们产品经理有病啊，亏我还把你们当回事反馈，你们公司要完了！然后我会在任何场合黑你们，因为你们没尊重我。
我反馈了你我，并告诉我已确认问题：那太好了，真把我当自己人，以后发现问题我还告诉你们。出去还会维护你们夸你们，你们这帮傻缺，没有我这种用户你们怎么成长？
我反馈了你我 “尊敬的用户，您的反馈我们已收到！”：对不起，你大爷我再也不会给你们反馈了！
@ 大白 ：
对于用户反馈而言，个人认为必须第一时间做出回应。同时，不要给出千篇一律的，要以个人的名义针对性的向用户作出一对一的。
如若用户的回馈内容表达了他的很多不满，这时我们更加需要及时的并解决，不能给用户造成逃避责任的印象。及时为出现的问题表示道歉，然后通过向用户提供帮助来控制局面恶化并解决问题。
总的来说，要给顾客留下一个积极主动的印象。
@vivigoose ：
我认为：
一般用户的反馈可以做一个优先级的分类，属于 bug 级别的 48 小时之内应予以优化并告知和答谢用户，并给用户一点小奖励表示感谢。
而用户想要什么什么东西，当前没有的，可以参考一下迭代计划中是否有列入，或者分析调查一下这个反馈的反应度是不是大众反馈，如果当前用户百分之 80%（或者处于一个既定的区值间），那么可以考虑用户的反馈，并在 72 小时内及时告知其反馈的结果是什么；即便用户的反馈不予当下采纳，也可以委婉的告知用户，您的反馈已经被我们收纳，感谢您对我们的大力支持。并可以给予一定的奖励。
对于用户而言，无论新老用户，其反馈都是一定要及时答复（时间在 1-3 天不等—因为要留出时间给人员进行修复，或者处理），用户的反馈是否能收到直接影响到他们的体验和情感，也影响他们会不会继续忠实于这个产品 / 公司 / 等 。
@ 小楼听雨 ：
看产品形态：
1. 紧急类的 bug,如用户无法登陆、无法注册等均需要及时，可以增强用户的粘性以及参与感
2. 非紧急类，如建议类则不需要及时，这样可以减少客服部门的额外支出
@Wells ：
新人来答下：
1.立刻自己去验证下，看看是否存在问题。
2.然后给用户回复，问清楚具体使用环境，并给出解决方案。
对于用户量庞大的最好是定期回复
@ 王润宇 ：
我的做法是这样的：
1.bug 类：立即反馈 “已经收到”，马上排入流程查证，查证后立即反馈，发奖。定期在论坛给出处理列表及状态。
2.改进类：自己觉得足够正确的且可以马上执行的（比如哪个按钮太小了不好点，弄大点），立即反馈，待斟酌的，先记录，并反馈收到。定期在论坛给出处理列表及状态。
3.战略型建议及开放性建议，引导为 PVP 的社区活动，让玩家形成讨论，一来洗掉水货（大部分是），二来有助于问题讨论深，三来增加社区运营元素
总之，本着服务精神，收到反馈应该立即吱声表达收到了，小问题快速回复，大问题进列表跟进，天大的问题供用户自己讨论，就酱紫
@ 多杰 ：
从用户角度讲，需要回复，这代表产品过商家对我的尊重、认可，也是自己价值的一种体现。从产品或商家的角度看，如果你不够大，如果你想多接触真实客户，也是需要及时回复的，对于回复的内容和方法，可以自行定义。我有过真实经历，前段时间做一个全国推的项目，我们利用微信群，实现了 5 分钟回复用户问题，不管能否马上解决问题，最起码的用户印象分，是拿到了。这在后来的沟通中，也得到了验证。后续的需求跟进，产品推广，也会顺利很多。当然如果公司够大，用户够多，及时回复就有难度了，就的换下方法了
@ 贝勒东 ：
1、要的，尤其是产品刚上线必须下沉到一线去，每条必复。
2、除上述大家的表述外，有时候还会参考下用户的资质，不排除有些用户有其他目的。
3、后面用户量上来后，可以优化下回复的时间、内容、形式等等
@ 槟比 ：
对于用户反馈，分几类：用户吐槽、重大 bug，随大流。
对于纯吐槽的，我们可以回复，但是不一定要立即修改，根据版本计划和轻重缓急进行安排。
重大 bug 不仅要理解回复，若对用户利益造成影响必须予以解决方案和补偿措施。
随大流的意见，不一定正确，需要产品经理自行定夺。
@qianchunyuan ：
需要及时回复，关系到反馈问题用户的体验。
但回复不代表需要解决用户反馈的问题，首先是体现了应答，表示问题收到了，我们在跟进处理。
而如何回复是要具体看所反馈的问题，因为每个人对产品的理解和诉求会不一样，也许只需要你做些解释问题就解决了；也许是给产品加分的建议，那就需要你和用户深入沟通可能挖掘出更有价值的东东。
@ 朱彤 ：
看人：忠实用户、种子用户，如果第一时间回复，能够保持其关注你的产品并积极反馈的热情；
看事：十分靠谱 / 紧急的反馈，第一时间回复会大大强化产品和服务在用户心中的认知；
看资源：对一定规模的产品来讲，时刻关注用户反馈意味着不小的人力投入，并且信息的筛选效率很难提高；
除此之外，不需要。
@ 盐多多 ：
用户反馈只是作为产品迭代方向的一个影响因素，整体方向及节奏还需要产品人员综合考虑，用户并不会从整体考虑，更多的时候是吐槽，即使提供有用的反馈也是片面的和充满杂质的，需要产品人员分析出用户真正的意思，简单来说就是区分需求和伪需求，因此，除非产品经理已经搞明白用户想说的意思，否则请不要回复。
@birdy ：
1. bug 类，或非常紧急的，如无法支付等，要尽快沟通回答
2. 无关紧要或需求类的，看出现在什么地方。如果是公开的问题列表，要针对性的定期回复。如果是单向的，邮件或其他方式，视用户等级和客服人员任务情况而定吧
@wx_ZMz2HoIM ：
一般不是乱喷的用户建议第一时间反馈，因为这样：
1）可以让用户觉得受重视，他的意见有反馈下次还会再提的。
2）产品不断迭代就要多听听用户的心理，在反馈用户和用户交流的过程中会得到相应的启发。 题图来自《产品经理是条狗》MV。 本文来自读者投稿，不代表 36氪 立场 |
|
|
