处理用户反馈时，我总结的几点经验.docVIP

　　处理用户反馈时，我总结的几点经验 本文是笔者在处理反馈时总结的经验，可能和你在做的有一些不一样。不过，用心去对待用户，认真对待每一条反馈，我相信肯定都是一样的。 互联网的用户支持和传统客服的重要区别在于：相比于客服被动地响应用户的问题，用户支持更多的会主动出击，发现并解决问题。 以前做这部分工作的时候，是借助于一款协作软件去开展的，这里不提名字了。我最初是觉着这样的事情做起来没什么意思，直到慢慢的摸索出这样一套流程来，算是这部分工作最直接的收获了。 我想你可能已经留意到了，它是一个闭环的流程。 一、需求收集 1、用户反馈 要给用户留下可以联系你的渠道，一般说来有以下这些： 用户反馈邮箱 产品反馈后台 用户群（ 群/微信群等） 新媒体（公众号、微博等） 第三方社区（知乎、豆瓣、贴吧等） 其他（应用市场、公关稿、办公室的一声吼…） 用户会通过这些渠道把使用过程中遇到的情况反馈过来，反馈通常分为以下几类： 产品 bug 吐槽 功能建议 其他（比如，以前听到多位用户来打听 CEO 有木有女盆友的…） （1）产品 Bug 如果用户描述的很清楚，我通常会自己动手看看能不能捕捉到这个 bug（嗯，「人肉」测试下），然后报给团队；如果描述的不是很清楚，就按照技术猿们问我们的套路来向用户收集信息：平台、版本、页面、操作…… 话说后来有一天，我知道有一种工具，是可以在出现 bug 时，直接精准到导致出错的那一行代码，根本不需要问用户杂七杂八…我承认那一刻，我其实内心深处真的是很想问候下，当年那些不尊重我们时间的猿们…愿你们有一天也要直面用户的怒火，然后持续个百十天。 （2）吐槽 很多原因导致用户吐槽，交互设计、页面设计、操作流畅度、业务流程等，但通常都是用户感到非常沮丧时，才会引起吐槽。所以，在和吐槽用户的交涉过程中，多含一些同理心吧。 当然，吐槽真的很容易让人产生负面情绪，有段时间看吐槽多了，负能量爆棚，就天天想要逃避用户…但是，不得不承认，很多的吐槽都是有价值的，争取引导用户说出来，找到问题。如果实在累了，就去特么的，休息几天调整调整心态吧。 （3）功能建议 功能建议分为两大类：新增功能、功能优化。这部分是反馈的重点，下文慢慢说。 2、反馈收集 在进行需求收集的时候，可以从以下几个方面考虑： （1）用户画像 了解下反馈用户的基本信息，性别、职业、年龄层、收入等，这通常与我们所运营的产品相关，了解下是否是目标用户提出的需求。 （2）用户场景 用户提出这个需求的原因是什么，在什么样的情况下，想完成什么事情，做了哪些操作，结果如何？这些信息非常有助于团队成员理解需求。 （3）产品信息 了解用户使用的是哪个客户端（web、iOS、android、WP等），使用的版本号。很可能反馈的需求在新版本中已经解决了，但用户没有升级，所以并不知晓。 （4）用户联系方式 记录下用户的联系方式，这条很有用，一方面用于统计分析，一方面为了完成反馈的闭环。通常，用户通过哪个渠道反馈的，就记录下该用户在这个渠道下的联系方式，如号、邮箱、评论链接、等。 3、反馈处理 （1）已知需求 很多时候，用户的反馈是团队已知悉的，对于已知悉的需求，通常我会告诉用户团队对这个需求的考虑，以及大概的开发计划（一定记得给团队留点时间，不要向用户透露具体时间，除非这件事是板上钉钉，绝不会改变的，而这种情况是极少的）。时间允许的情况下，还可以和用户一起聊一聊对于解决方案的看法。 （2）新需求 对于新的需求，作好记录的同时，也不忘告诉用户，你的反馈已经收到啦。 （3）使用问题 如果是功能使用的问题，就可以第一时间帮用户解决掉，告诉下正确的使用方法即可。 二、需求管理 1、需求记录 用户反馈在经过筛选整理后，有很多建议会被放到需求池。通常建议是和产品迭代联系在一起的，旧的去了，新的又会来。所以，就需要对需求池进行管理。 （1）归类 如果用户的反馈在之前已经有类似的反馈，只需要将相同的建议统一在一处即可，不需要单独开新的需求；而对于同一功能模块下的需求，也可以归集在一处，按照不同模块来简单分类；而具备上下游关系的多个需求，可以进行关系的梳理，待上游的问题解决后，下游的需求可能自然就对应的解决了。 （2）次数 对于相同的需求，记录有多少用户反馈过，从反馈总次数的维度了解用户比较关心的几个问题。这里要注意，并不是反馈的次数多，这个需求就一定是重要到非做不可的。一个需求能不能做，还需要考虑公司对产品的战略规划、占用的开发资源以及开发难度等问题。对于需求的考虑需要单独讨论，这通常也是产品经理考虑的问题，这里先不展开了。 （3）频次 顾名思义，频次就是在一定时间内，同一个需求反馈的次数。这个是从紧急度的维度去看一个需求。通常，会在新版本上线后，重点留意这个维度。如果新版本上线后一段时间，有多个用户反馈了同一