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

本文是笔者在处理反馈时总结的经验，可能和你在做的有一些不一样。不过，用心去对待用户，认真对待每一条反馈，我相信肯定都是一样的。

互联网的用户支持和传统客服的重要区别在于：相比于客服被动地响应用户的问题，用户支持更多的会主动出击，发现并解决问题。

以前做这部分工作的时候，是借助于一款协作软件去开展的，这里不提名字了。我最初是觉着这样的事情做起来没什么意思，直到慢慢的摸索出这样一套流程来，算是这部分工作最直接的收获了。

我想你可能已经留意到了，它是一个闭环的流程。

一、需求收集

1、用户反馈

要给用户留下可以联系你的渠道，一般说来有以下这些：

• 用户反馈邮箱

• 产品反馈后台

• 用户群（QQ 群/微信群等）

• 新媒体（公众号、微博等）

• 第三方社区（知乎、豆瓣、贴吧等）

• 其他（应用市场、公关稿、办公室的一声吼…）

用户会通过这些渠道把使用过程中遇到的情况反馈过来，反馈通常分为以下几类：

• 产品 bug

• 吐槽

• 功能建议

• 其他（比如，以前听到多位用户来打听 CEO 有木有女盆友的…）

（1）产品 Bug

如果用户描述的很清楚，我通常会自己动手看看能不能捕捉到这个 bug（嗯，「人肉」测试下），然后报给团队；如果描述的不是很清楚，就按照技术猿们问我们的套路来向用户收集信息：平台、版本、页面、操作……

话说后来有一天，我知道有一种工具，是可以在出现 bug 时，直接精准到导致出错的那一行代码，根本不需要问用户杂七杂八…我承认那一刻，我其实内心深处真的是很想问候下，当年那些不尊重我们时间的猿们…愿你们有一天也要直面用户的怒火，然后持续个百十天。

（2）吐槽

很多原因导致用户吐槽，交互设计、页面设计、操作流畅度、业务流程等，但通常都是用户感到非常沮丧时，才会引起吐槽。所以，在和吐槽用户的交涉过程中，多含一些同理心吧。

当然，吐槽真的很容易让人产生负面情绪，有段时间看吐槽多了，负能量爆棚，就天天想要逃避用户…但是，不得不承认，很多的吐槽都是有价值的，争取引导用户说出来，找到问题。如果实在累了，就去特么的，休息几天调整调整心态吧。

（3）功能建议

功能建议分为两大类：新增功能、功能优化。这部分是反馈的重点，下文慢慢说。

2、反馈收集

在进行需求收集的时候，可以从以下几个方面考虑：

（1）用户画像

了解下反馈用户的基本信息，性别、职业、年龄层、收入等，这通常与我们所运营的产品相关，了解下是否是目标用户提出的需求。

（2）用户场景

用户提出这个需求的原因是什么，在什么样的情况下，想完成什么事情，做了哪些操作，结果如何？这些信息非常有助于团队成员理解需求。

（3）产品信息

了解用户使用的是哪个客户端（web、iOS、android、WP等），使用的版本号。很可能反馈的需求在新版本中已经解决了，但用户没有升级，所以并不知晓。

（4）用户联系方式

记录下用户的联系方式，这条很有用，一方面用于统计分析，一方面为了完成反馈的闭环。通常，用户通过哪个渠道反馈的，就记录下该用户在这个渠道下的联系方式，如QQ号、邮箱、评论链接、电话等。

3、反馈处理

（1）已知需求

很多时候，用户的反馈是团队已知悉的，对于已知悉的需求，通常我会告诉用户团队对这个需求的考虑，以及大概的开发计划（一定记得给团队留点时间，不要向用户透露具体时间，除非这件事是板上钉钉，绝不会改变的，而这种情况是极少的）。时间允许的情况下，还可以和用户一起聊一聊对于解决方案的看法。

（2）新需求

对于新的需求，作好记录的同时，也不忘告诉用户，你的反馈已经收到啦。

（3）使用问题

如果是功能使用的问题，就可以第一时间帮用户解决掉，告诉下正确的使用方法即可。

二、需求管理

1、需求记录

用户反馈在经过筛选整理后，有很多建议会被放到需求池。通常建议是和产品迭代联系在一起的，旧的去了，新的又会来。所以，就需要对需求池进行管理。

（1）归类

如果用户的反馈在之前已经有类似的反馈，只需要将相同的建议统一在一处即可，不需要单独开新的需求；而对于同一功能模块下的需求，也可以归集在一处，按照不同模块来简单分类；而具备上下游关系的多个需求，可以进行关系的梳理，待上游的问题解决后，下游的需求可能自然就对应的解决了。

（2）次数

对于相同的需求，记录有多少用户反馈过，从反馈总次数的维度了解用户比较关心的几个问题。这里要注意，并不是反馈的次数多，这个需求就一定是重要到非做不可的。一个需求能不能做，还需要考虑公司对产品的战略规划、占用的开发资源以及开发难度等问题。对于需求的考虑需要单独讨论，这通常也是产品经理考虑的问题，这里先不展开了。

（3）频次

顾名思义，频次就是在一定时间内，同一个需求反馈的次数。这个是从紧急度的维度去看一个需求。通常，会在新版本上线后，重点留意这个维度。如果新版本上线后一段时间，有多个用户反馈了同一个问题，那可能新版本出现问题了，就要及时通知团队，但是立即修复发新版，还是回滚到之前的版本，就要看团队的考虑了。

2、进度跟踪

（1）对用户

其实和用户交流就像和一个正常的朋友打交道一样，交朋友很重要的一点就是，让对方知道你是靠谱的。那怎么让用户感受到你是靠谱的呢？我的建议是：做产品的专家。

在用户张嘴的时候，就能判断出大概是什么问题，解决方案有哪些，最合适该用户的方案是什么；如果现在没有解决方案，那么这个问题在不在团队的考虑范围内，如果不在，原因是什么；如果在考虑了，目前在什么阶段了，大概的解决时间和解决方案是什么。最后用户容易接受的方式告诉用户原因。不用担心这样的举动会导致用户流失，说实话用户未必就不能接受，和套话、空话相比，说实话给用户的体验可能更好。并且有些用户的流失真的不可避免，因为确实不在服务范围内。

也许你的用户有来自各个领域的领袖人物，但是确保在自家产品上，你是领袖。专业的知识总是令人信服的，也是最容易树立威望的。

（2）对团队

进度跟踪一方面要参与到团队内部的需求决策过程中来，在产品决策的时候，要确保团队对用户的意思理解正确，对于不确定的解决方案，还可以找几个用户实际了解下方案的偏好。

进度跟踪的另一方面，是要及时了解团队对需求处理的实际情况，比如，开发计划有没有被调整，开发进度有没有延期，设计方案和用户期望有多大的差距…根据实际情况更新需求池信息，可以让我们在面对用户的时候，减少错误信息的传递。

三、需求实现

1、产品更新

（1）通知反馈用户

产品更新后，第一时间通过反馈收集环节记录的用户联系方式去通知反馈对应需求的用户，这样做的好处是：

• 让这些反馈的用户能第一时间收到消息，获得良好的反馈体验；

• 了解这部分用户对新功能的看法，带来新的反馈；

对于N久之前反馈的用户，以一种友好的方式尝试召回。

（2）发布更新消息

主动反馈的用户占比是不高的，大部分都是沉默用户。因此，在产品更新后，要将针对新版本/新功能的更新内容，通过建立起来的各个渠道发布出去，让其他未直接反馈的用户了解到更新信息。

2、归档/完成

需求的处理到这里并没有结束，还需要对需求做个归档。在已解决的需求下记录对应的解决方案、更新版本、发布的时间，因为后期分析用户行为或产品数据时，如果遇到数据异常，可能需要从归档的需求里面找依据。

比如，回顾数据时，发现上个月的某个功能使用率明显提升，然后猜测是和上个月发布了新版本有关，在需求池发现，这个功能的优化建议在上个版本实现了，这样就可以帮助我们找到了一些异常发生的依据了。

以上是本人在处理反馈时总结的经验，可能和你在做的有一些不一样。不过，用心去对待用户，认真对待每一条反馈，我相信肯定都是一样的。