本文是笔者在处理惩罚反馈时总结的履历，大概和你在做的有一些纷歧样。不外，用心去看待用户，当真看待每一条反馈，我相信必定都是一样的。

互联网的用户支持和传统 *** 的重要区别在于：对比于 *** 被动地响应用户的问题，用户支持更多的会主动出击，发明并办理问题。

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

我想你大概已经寄望到了，它是一个闭环的流程。

一、需求收集 1、用户反馈

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

用户反馈邮箱

产物反馈靠山

用户群（ *** 群/微信群等）

新媒体（公家号、微博等）

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

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

用户会通过这些渠道把利用进程中碰着的环境反馈过来，反馈凡是分为以下几类：

产物 bug

吐槽

成果发起

其他（好比，以前听到多位用户来探询 CEO 有木有女盆友的…）

（1）产物 Bug

假如用户描写的很清楚，我凡是会本身动手看看能不能捕获到这个 bug（嗯，「人肉」测试下），然后报给团队；假如描写的不是很清楚，就凭据技能猿们问我们的套路来向用户收集信息：平台、版本、页面、操纵……

话说厥后有一天，我知道有一种东西，是可以在呈现 bug 时，直接精准到导致堕落的那一行代码，基础不需要问用户杂七杂八…我认可那一刻，我其实心田深处真的是很想问候下，当年那些不尊重我们时间的猿们…愿你们有一天也要直面用户的肝火，然后一连个百十天。

（2）吐槽

许多原因导致用户吐槽，交互设计、页面设计、操纵流通度、业务流程等，但凡是都是用户感想很是沮丧时，才会引起吐槽。所以，在和吐槽用户的谈判进程中，多含一些同理心吧。

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

（3）成果发起

成果发起分为两大类：新增成果、成果优化。这部门是反馈的重点，下文逐步说。

2、反馈收集

在举办需求收集的时候，可以从以下几个方面思量：

（1）用户画像

相识下反馈用户的根基信息，性别、职业、年数层、收入等，这凡是与我们所运营的产物相关，相识下是否是方针用户提出的需求。

（2）用户场景

用户提出这个需求的原因是什么，在什么样的环境下，想完成什么工作，做了哪些操纵，功效如何？这些信息很是有助于团队成员领略需求。

（3）产物信息

相识用户利用的是哪个客户端（web、iOS、android、WP等），利用的版本号。很大概反馈的需求在新版本中已包办理了，但用户没有进级，所以并不知晓。

（4）用户接洽 ***

记录下用户的接洽 *** ，这条很有用，一方面用于统计阐明，一方面为了完成反馈的闭环。凡是，用户通过哪个渠道反馈的，就记录下该用户在这个渠道下的接洽 *** ，如 *** 号、邮箱、评论链接、 *** 等。

3、反馈处理惩罚

（1）已知需求

许多时候，用户的反馈是团队已知悉的，对付已知悉的需求，凡是我会汇报用户团队对这个需求的思量，以及或许的开拓打算（必然记得给团队留点时间，不要向用户透露详细时间，除非这件事是板上钉钉，毫不会改变的，而这种环境是少少的）。时间答允的环境下，还可以和用户一起聊一聊对付办理方案的观点。

（2）新需求

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

（3）利用问题

假如是成果利用的问题，就可以之一时间帮用户办理掉，汇报下正确的利用要领即可。

二、需求打点 1、需求记录

用户反馈在颠末筛选整理后，有许多发起会被放到需求池。凡是发起是和产物迭代接洽在一起的，旧的去了，新的又会来。所以，就需要对需求池举办打点。

（1）归类