本篇文章基于腾讯“吐个槽”，对用户反馈关键点、收集流程、评估及分级进行了深入探讨，分析了用户反馈平台当前面临的问题给出相关优化建议，并对未来用户反馈平台的发展方向进行了展望。
一、当我们说用户反馈的时候，我们在说什么？
–【管理】-【反馈列表】页面。在这个页面选中一个或者多个用户反馈之后，在页面上方就会出现一排专门用来处理用户反馈的功能按钮。在这里，我们着重介绍三个“论坛风”的按钮——“置顶”、“标记为精华”和“标记为水军”。
其实不需要过多理解， 从字面上大家就能轻松明白它们的含义。“置顶”产生的结果，主要是用户反馈的帖子会成为列表中的第一项。团队成员每次打开列表，都会格外关注那些置顶的反馈，体现了反馈内容的重要性。“标记为精华”则更侧重于内容质量好，这里不仅是用户反馈的内容质量好，还可以是团队回复用户的内容质量好，对其他用户有帮助参考意义。“标记为水军”当然正好相反，指的是反馈帖子的内容不好。
四、反馈的落地优化
这部分就是前面一直在说的工程部分了。这也是大家做产品的同学最常见的场景——需求、评审、研发、测试、上线的过程。与工程相关的常规工作，我们就不再多说了，重点说一些跟反馈有关的东西。
4.1 “吐个槽”的处理流程与工程初探
作为一个用户反馈平台，其实“吐个槽”是考虑到了团队之间的沟通与功能落地的。其工作流程应当大致如下——
- 当用户提交了反馈，负责运营的同学首先需要把控内容的质量，对它标记精华、操作置顶或者标记水军；
- 之后，如果是需要后续处理的反馈，选中之后可以点击“待处理”按钮，表示需要后续工作；
- 再之后，当用户反馈的问题处理完时，可以批量选中相关的问题，并统一回复给用户。如果反馈本身不需要额外处理，也可以使用同样的方法，直接批量恢复用户。
在这个过程中，一条被标记了“待处理”并且“置顶”的反馈，将会始终提醒着相关的负责人关注其进度。目前感觉还欠缺的一点是，目前只有一个待处理的状态，并没有根据互联 产品实际的迭代节奏，对这个状态再进行细分，给用户更明确的反馈。比如像这样：
待处理； 处理中； 处理完成。 这些状态，第一是给用户看的，让用户知道自己的反馈的最新进展；其次是给团队成员看的，了解这个问题已经在处理中了还是无人问津的状态；再次，留下了这个概念之后，后续可以从这个点出发，让“吐个槽”平台与其他平台更好的融合，共同支撑迭代的落地和监控。
4.2 反馈平台普遍面临的工程问题
“吐个槽”平台在用户反馈层面为运营和客服同学给予了支撑，接下来就到了产品团队层面的需求梳理阶段。既然到了需求阶段，自然要有明确的待解决问题、目标、方案和价值评估。好在这些问题我们已经在前面做了大量铺垫——
了解用户的行为路径，提供了用户视角的最佳实践和测试Case的沉淀； 影响评估，为工程实践提供了优先级评估、工作量评估、人员分配、技术方案和架构调整等多方面的参考。 但是任何团队的资源都是有限的。在有限的资源面前，我们还会面临其它一些具体的问题：
用户的反馈，如何“搬运”到团队协作和项目管理中？ 如何让团队有效地围绕反馈进行协作？ 紧急情况，如何排除人工低效的影响因素？ 4.2.1 “搬运”与系统打通
针对“搬运”，前面关于用户反馈的5个关键点中，我们提到了系统化、自动化的问题。简单凝炼成两个字，就叫“打通”。在这方面，贴近技术的工单式用户反馈平台是具备天然优势的。用户的反馈直接与任务和团队协作系统打通。这种实现方式在客服团队比较常见，可惜的是，客服团队到具体执行团队之间的链路上，容易出现大量的人工操作，降低了效率。
这种系统打通，表面上看不会提供多少可见的短期价值，但是对于团队整体的紧密配合有很大的帮助；同时又能堵住大家都很忙、“人力莫名流失”的漏洞。这种机器能轻松搞定的事情，还是应当交给机器来做。
4.2.2 反馈的自动化反馈
（注：吐个槽目前已经实现每日/每周/每月的微信推送简 ，以及企业微信群周 机器人功能。）
要让团队有效的围绕反馈进行协作，重要的一步就是信息同步。信息有断档，大家的认知就无法统一，自然效率低下。
前面提到过反馈的反馈，也就是让用户知道自己提的问题处理到什么进度了。可想而知，这个工作如果要用人工来做，特别是在大公司，很可能变成是一项跨团队的巨大工程——产研团队、客服团队、BD团队甚至还有更多。在这种人力损耗面前，系统化的价值就大大凸显出来了。
另一方面，团队也需要更高效的获取到用户反馈的相关信息。当用户提出一个问题时，除了直接相关的问题描述、分类等信息，还需要获得这位用户最近的行为轨迹、偏好预测等非敏感信息，以及与这位用户类似的其他用户的非敏感信息。这都有助于执行团队在充分了解状况的前提下，高效地解决问题。
4.2.3 紧急情况
这种可能是老板们比较头疼的状况。在一些紧急情况下，即便麾下千军万马，却有力不从心的感觉。这里边的问题，还是效率的问题。
第一，要说的是工具效率的问题。比如在用户面前直接大显身手的客服团队，就需要为其设计强大的支撑工具。当用户一个电话打进来，与用户相关的信息都要及时传递给接待的客服同学；同时还要有配套的操作工具来帮用户实际地解决问题。最差情况，就算当时无法立即解决用户的问题，也要为客服同学提供一个简单好用的记录工具，这同样是用户反馈的收集过程。
第二，要说的是人的效率的问题。比如需要人工进行系统修复的过程，从理解系统抛出来的那些复杂的 警信息，到找到出问题的点，再到最终修复问题，这个流程相当长。再加上如果是大团队，效率可想而知。怎么办？几套常见情况的应急预案是“必备良药”。人的行为惯性相对于深思熟虑要高效得多。提前准备预案并经常演练，是实现人的高效的好办法。
第三，那么还有没有更好的办法呢？我们下个部分再说。
五、发展的大方向
5.1 用户反馈平台的通用发展方向
前面我们已经将用户反馈从各个角度进行的拆分：
从感情态度上，区分积极与消极用户的基本诉求； 从收集方式上，区分了定向、常规和广义收集； 从重要程度上，给了5级分级方法； 从自动化上，评价了人工和自动的应对方案及提高效率的方法； 但在前一部分的末尾我们留了个小问题——对于紧急情况，我们有没有更好的办法呢？当然有！就是让紧急情况别发生！也就是从“处理”走向“预防”的方向。这就像著名的“质量免费”观念一样。
我们前面提到了，可以通过用户行为分析，来沉淀用户视角下的测试Case。我们收集的大量用户行为Case，其使用场景可不仅仅是对新功能进行自动化测试。根据这些基础数据，我们理应比用户更早的“反馈”问题；等到用户找上门来，我们就应当能拿得出像样的解决方案了；或者直接在用户准备提交问题的时候给出解决引导；或者再往前，直接进行产品优化，将问题扼杀在摇篮里。
- 信息同步：即尽可能的，在那些与处理用户反馈相关的团队之间实现信息同步，而不是让产品或者运营团队孤军奋战；
- 价值取向：这会体现在各种标准的制定上。还记的前面那张《用户反馈评估表》吗？那些标准应当在你的团队里达成一致意见。
- 观念转变：这是前面最后这部分提到的。就是好的产品质量是免费的，我们是在为糟糕的产品质量投入大量成本，而不是在为改进产品的过程投入成本。这可能会要求团队成员付出一些看似“额外”的努力，但这些努力会带来客观的回 。。
当然，预防不代表对用户反馈“赶尽杀绝”，与用户的直接沟通，依然是获得一手资料的最佳途径。
5.2 针对“吐个槽”平台的发展方向建议
前面已经提到了一些关于“吐个槽”平台的建议，我们在这里汇总一下，作为未来发展方向的总体建议：
在管理后台中，为运营同学增加更多可供标记的内容。前面主要提到了关于处理状态的丰富，其实在这个点上还可以扩展出其他类型的达标标签，比如体验优化项目相关的、负责人相关的、最终问题定位相关的等等。 有需要工程落地的反馈存在，这就要求在反馈平台上体现一些“工程特性”。“吐个槽”平台加入了“待处理”状态是一个绝佳的开始。后续在这个方向上，还可以补充“分配到管理员”等围绕任务和工程的特性。 用户反馈平台的理想状态，就是能最大限度的降低那些普通又频发的问题的处理成本，比如少投入人力、多应用自动化和智能方案。而基于“吐个槽”平台目前的功能结构，可以考虑的是通过用户反馈数量自动提取“常见问题”，变成半人工半自动的实现方案。这样人工只需要关注那些判定错误的反馈就可以了。 — END —
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！