处理反馈是一个闭环的流程

互联网用户支持与传统客户服务的重要区别在于，用户支持将主动发现和解决问题，而不是客户服务被动响应用户问题。以前做这部分工作的时候，是借助一个合作软件进行的，这里就不提名字了。一开始，我觉得这样的事情做起来毫无意义，直到我慢慢地找到了这样一个过程，这是这部分工作中最直接的收获。我想你可能已经注意到这是一个闭环过程。一、需求收集1、用户反馈给用户留下联系您的渠道。一般来说，有以下几点：用户反馈电子邮件产品反馈背景用户群（QQ群/微信群等）、新媒体（官方账号、微博等）、第三方社区（知乎、豆瓣、贴吧等）（应用市场、公关稿、办公室咆哮），用户将通过这些渠道反馈使用过程中遇到的情况，反馈通常分为以下几类:建议其他产品bug吐槽功能(比如之前听到很多用户打听CEO有女盆友……)(1)如果用户描述清楚产品bug，我通常会自己看看能不能捕捉到这个bug(嗯，「人肉」测试)，然后向团队报告；如果描述不是很清楚，根据技术猿问我们的常规，向用户收集信息：平台、版本、页面、操作。有一天，我知道有一个工具可以直接准确地导致错误，不需要问用户。我承认在那一刻，我真的很想问候那些不尊重我们时间的人。愿你有一天面对用户的愤怒，然后持续100天。(2)用户吐槽的原因有很多，比如交互设计、页面设计、操作流畅度、业务流程等。，但通常是当用户感到非常沮丧时，才会引起吐槽。(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、这里还没有完成归档/完成需求的处理，需要归档需求。将相应的解决方案、更新版本和发布时间记录在已解决的需求下，因为在以后分析用户行为或产品数据时，如果数据异常，可能需要从归档需求中找到依据。例如，在回顾数据时，我们发现上个月的功能利用率显著提高，然后猜测这与上个月发布的新版本有关。在需求池中，我们发现该功能的优化建议是在上一个版本中实现的，这可以帮助我们找到一些异常的基础。以上是我处理反馈时总结的经验，可能和你在做的不一样。然而，我相信用心对待用户和每一个反馈一定是一样的。