当说用户反馈的时候我们在说什么

　　本篇文章基于腾讯＂吐个槽＂，对用户反馈关键点、收集流程、评估及分级进行了深入探讨，分析了用户反馈平台当前面临的问题给出相关优化建议，并对未来用户反馈平台的发展方向进行了展望。
　　一、当我们说用户反馈的时候，我们在说什么？
　　【提问】用户反馈是什么？我们为什么要收集反馈？
　　【回答】用户反馈能够帮我们的产品变得更好呀！我们快搭个平台吧！
　　等等！什么是＂更好＂的产品？我们的产品又是怎么＂变好＂的？还有5W1H啊同学！这些基本的问题不解决，直接做反馈平台可能有点小浪费啊亲。
　　1.1 用户反馈的关键点
　　既然是收集用户反馈，那么这个事还要从用户说起。对于用户来说，提交反馈绝对是个＂多余＂的工作量。但是，我们只要在产品上开了提交反馈的口（一般都会开的吧），就多多少少能收到一些用户提交的反馈，捧上天的也有，按到地上摩擦的也有。那么是什么让用户＂放弃＂了＂直接流失＂这个选项，而来提反馈呢？我们从积极和消极两个方面来看：
　　【积极用户】：这个产品太好了，我的主要诉求已经满足，如果能够再改改，或者在增加一些外围的功能就更好了！
　　【消极用户】：这个……哎这个产品是个什么鬼！老板还必须让用这个，赶快让他们改改！（或者其他一些让用户必须选择这款产品的因素，比如：独此一份再无竞品、有大量历史资料不方便迁移等等。）
　　那么，对于以上两种用户来说，＂好＂的标准是完全不同的——
　　对于已经比较满意的用户，可能会愿意花费更多的时间和精力协助团队改善产品，相应的也比较能忍耐一些临时方案和延误的时间点；因此，对于这样的用户，其反馈为产品提供的一般是中长期的发展参考。比如，还有哪些场景没有覆盖？以往收集到的需求是否有所变化？等等。
　　对于那些不满意的用户，尽快解决最紧急的问题才是关键。同时，这样的用户通常也会有意无意地主动调低自己的期望值，一些更加高远的需求可以暂时放弃。这样的用户一般会帮助团队找到一些未被发现严重问题以及相应的复现Case。
　　通过这样的分析不难看出，如果此时我们把大量资源用来满足积极用户的那些＂锦上添花＂的功能，那么另一边的消极用户就要骂街了。这就是对于两种用户的＂好＂的不同标准。
　　此外，关于用户反馈和需求，在产品圈子还流传着这么一句：＂不要完全听用户的，对于用户的直接诉求，需要进一步深挖其本质。＂这个状况，在一定程度上就是因为，愿意提出反馈的用户，都会提出一些跟自己切身利益相关的诉求，但这种切身的诉求未必能够推广到更多的用户身上。而对于那些还有其它选择的用户，可能就真的流失了。我们可以把这些流失的用户，归为第三类＂沉默用户＂（与前面的积极拥护和消极用户并列）。要收集这些用户的＂反馈＂，就需要通过对用户的行为数据进行分析。
　　1.2 用户反馈的基本流程
　　基于以上几点，关于用户反馈以及如何切实地让自己的产品越来越＂好＂，我们可以发现的5个关键点：
　　需要倾听用户的声音——需要收集到用户的意见和建议，或其它相关数据；
　　需要深入挖掘用户的诉求——需要有相应的数据和分析能力支撑；
　　需要考虑用户诉求的紧急程度——需要给反馈设置紧急程度，评估处理的优先级；
　　需要让优化切实落地——需要持续跟进反馈的后续进展，进行工程实施；
　　需要提高处理效率——需要系统化、自动化地处理反馈；
　　结合这5方面，整体的反馈与落地的流程如下图：
　　1.3 腾讯＂吐个槽＂平台带来了什么
　　上面说了一些关于用户反馈的通用性内容，现在要邀请我们的主角出场了。接下来我们来分析一下腾讯的＂吐个槽＂平台。腾讯公司面临的是大体量的用户群体、复杂而明细的内部产品线，并且公司内部员工众多。在这样的情况下，＂吐个槽＂这款产品就需要具备足够的能力适应公司组织、产品及用户群体的特性，同时还要兼顾此平台的外部客户多重多样的请款。
　　【常规收集和定向收集】：在开始向用户收集反馈之前，我们可以先登录腾讯＂吐个槽＂的管理端，并设置相应的问题分类，方便后续的分类和汇总。
　　【评估影响】：在评估的过程中，可以直接通过＂反馈列表＂中的过滤功能，查找是否出现了大量的相关的问题；如果需要使用更加专业的软件进行数据分析，也可以通过＂吐个槽＂平台导出用户的相关反馈数据。确定需要处理之后，可以在＂反馈列表＂中批量回复相关用户的反馈；同时为了跟进进度，可以将相关的用户反馈标记为＂待处理＂状态。
　　【同步用户】：当用户提出的反馈有了最新的处理进度，或者得到妥善处理之后，我们需要通知用户。通过＂问题列表＂可以对之前的用户反馈进行批量回复。用户可以通过自己的微信接收最新的反馈情况。
　　下面我们分别深入探讨一下用户反馈流程中的几个关键环节。
　　二、用户反馈的收集
　　收集是关键的第一步。同时，又可以分为几种收集方式。
　　2.1 定向收集
　　2.1.1 定向收集的＂已知条件＂
　　从公司或团队的角度，这是比较常见的场景。当我们因为不了解用户而满心焦虑的时候，自然会想到要向用户收集反馈。这个时候，我们会有很清晰的研究意向、目标和限制条件——
　　要针对哪个产品或模块收集反馈？
　　要询问哪方面的问题？是产品的特性、交互、体验？还是用户的基本信息、使用场景、选品理由？这些会具体落地为调查问卷中的问题列表。
　　要通过什么渠道收集？调查问卷？用户访谈？选择线上还是线下？要不要通过一些利益点推动用户反馈？
　　要投入多少成本？向哪些用户收集，收集规模有多大？怎么界定＂任务完成＂？如果有添加用来促进反馈的利益点，怎么防止那些不真实的反馈？
　　……
　　我们可以根据这些＂已知条件＂，对整个收集过程进行前置的设计，以确保整个过程可控。
　　2.1.2 使用＂吐个槽＂实现定向收集
　　在 ＂吐个槽＂的产品方向上并不是为了解决这类定向收集的问题而生的，更何况还有腾讯自家的＂腾讯问卷＂，专门用来解决这个问题。但是，如果＂吐个槽＂能够参与这类定向反馈收集的过程，能够很好的解决＂开放性＂问题的收集、汇总和实施落地过程。
　　在一般的用户调查问卷中，都会提出1~2种开放性的问题。例如：＂您对我们的产品还有什么建议和意见？＂＂您觉得我们的产品还有哪些待解决的问题？＂在这样的问题中，用户的反馈是通过文字描述的，通常无法预先知道内容的大概方向。比较适合使用论坛的方式展开讨论，逐步细化并且明确实质性的问题在哪。
　　要实现这样的功能，在公司内部可以采取技术层面的打通，让＂吐个槽＂直接读取产品相关的开放性问题，并导入到对应的产品反馈项目下。如果是第三方的产品在使用＂吐个槽＂平台，就需要吐个槽再提供一个批量导入问题的功能，就可以通过手工的方式，实现与各种问卷平台的打通了。
　　2.2 常规收集
　　从用户的角度，这是比较常见的场景了。前面我们提到了两类会主动反馈的用户——积极用户和消极用户。这两种用户都有足够的动机，主动寻找反馈入口并提交内容，来帮助产品进行优化。
　　说到常规收集，就需要结合＂主产品＂的形态统一设计，让它成为＂主产品＂的一部分。比如我们的＂吐个槽＂，就提供了嵌入到其它产品平台的接入方式。
　　因此，在设计的时候需要考虑一些与交互和融合相关的因素——
　　2.2.1 交互方式分类
　　这方面需要尽量考虑与＂主产品＂的结合，尽量与目标用户的使用习惯贴近，同时尽量不打断用户的正常使用流程。按照不同的交互形态，可以分为以下几种：
　　论坛式：这个就是＂吐个槽＂的基本形态了。用户主动提交自己的问题、对产品的吐槽、优化意见等等，形成交流主题。其他用户能够方便的查看别人提交的问题，也能通过反馈平台与产品团队和其他用户进行交流。
　　对话式：App端的反馈比较喜欢采用这种方式，而且这种交互形态经常会加入自动回复与人工客服的切换机制——当用户的问题比较常规时，可以通过机器人自主解决问题，减少人力成本；而当用户的问题比较刁钻时，又可以通过主动触发的方式切换到人工服务，以保证用户体验。
　　工单式：偏向技术服务的平台更容易采用这种形式，比如著名的域名平台GoDaddy。当用户提交反馈之后，反馈会自动变成一条流程工单在工作人员之间流转，因此会有明确的负责人跟进并推进问题的处理，并且以工单为单位记录所有的处理过程。这样，用户就可以随时查看自己的问题处理到什么程度了。
　　留言式：这是一种更常见的交互形态，只给用户提供了几个输入框，可以填写主题、描述、分类、联系方式等内容。当用户提交了问题之后，就要等着工作人员主动联系了。这样的反馈难免让用户觉得＂石沉大海＂，一般要等到问题开始处理之后，才会有人主动联系用户。
　　2.2.2 交互流程体验
　　这方面的设计，与一般的产品交互区别就不大了。也要考虑用户使用过程中的体验如何。比如，入口的深度设计得是否方便找到？是否能在产品出现异常的情况下自动介入进行引导？等等。
　　另一种设计得比较好的处理方式，是在用户遇到问题的时候，先将常见的问题和解决办法供用户参考。比如下面就是＂吐个槽＂平台提供的汇总常见问题的列表。针对每个常见问题，用户都可选择是否对自己有帮助，之后平台根据这些反馈情况，再对这些常见问题进行优化和排序，以便更快地解决一些高频发生的问题。这种设计方案，不仅提供了操作上的便利性，也帮团队减少了处理重复问题的资源浪费，同时在情感上也给用户一定的安慰，因为可以看到不少其他用户也遇到了类似的问题。
　　2.2.3 关于反馈的＂反馈＂
　　这一点在设计反馈机制的时候也是相当重要的。好的处理流程，需要时刻保持处理进度向用户透明。这种信息反馈，能够让用户感到自己受到了足够的重视。如果在前面的几种交互形态中比较，留言式反馈收集应当算是最差的了。除非有工作人员主动联系用户，否则几乎感受不到有什么最新的进展。对话式的反馈收集应当是体验上最好的，能得到即时的反馈。
　　2.2.4 使用＂吐个槽＂实现常规收集
　　只要按照＂吐个槽＂官方接入文档进行配置，就可以在自己的产品中使用＂吐个槽＂平台收集用户反馈了。比如下面这两张图，展示的就是接入了＂吐个槽＂平台之后，呈现在产品上的入口，以及用户提交反馈的入口。（官方文档地址：https://tucao.qq.com/dashboard/dev/index）
　　在用户提交反馈之前，根据历史的用户反馈，或者参考同类型的产品，我们可以大概给用户的反馈分分类，既可以引导用户快速定位到与自己的问题类似的相关问题，也可以帮助产品团队预先对反馈进行分类整理。功能入口在【管理后台】-【设置】-【反馈分类】。＂吐个槽＂平台提供了支持三级问题配置的分类功能。例如，我们可以这样使用这三级配置：
　　一级分类，用来设置问题相关的产品、或功能模块；
　　二级分类，用来设置一些更加细节的场景。比如，用户遇到了功能失灵、以外退出等，或者只是在特定的场景下觉得使用不便、存在体验问题。在这里不建议直接具体到BUG、交互体验等分类方式，毕竟用户很难从自己的角度将问题放到这些分类里边，应当尽量采用贴近用户＂语境＂的描述方式。
　　三级分类，就可以对二级中的场景进一步细化，比如＂只在特定手机上出现＂、＂只在特定浏览器上出现＂、或者＂朋友也出现同样的问题＂等等。
　　通过这样配置问题分类，我们就可以引导用户提供更多有助于帮助解决问题的信息，同时也可以更容易帮助用户在常见问题中选出那些可以直接帮助解决问题的内容。
　　2.3 广义收集
　　前面我们已经说过了，大量用户在面对不满意的产品时会选择＂流失＂，根本不会提供反馈，也就是前面说的＂沉默用户＂。但是这样的用户，多多少少还是跟产品有些＂交集＂的。比如，这样的用户至少使用过产品的某些部分，在产品上留下了一些痕迹。或者，通过其它更＂低成本＂的方式进行了反馈，比如发了条微博骂了一下。对于这样的反馈收集，就与前两种收集方式有所区别了。
　　我们重点关注两种渠道的反馈收集——
　　2.3.1 数据分析中的反馈收集
　　在数据分析中，行为分析是大家热衷的焦点之一。对于一般的用户行为分析，从长远来讲，我们的主要目的还是希望通过找到一些规律，来预测用户未来的行为。比如我们找到了用户的某种特性与用户流失之间的关系，就可以通过监控这种特性的变化，及时挽留用户。
　　除此之外，用户行为方面的数据分析也可以帮助我们解决一些眼前的问题。比如现在的一些第三方数据分析平台（比如Google Analytics），就提供了行为路径的汇总统计和可视化的工具。当我们着眼于用户最终的转化行为时，行为路径分析可以帮助我们呈现由不同路径而来、并最终完成转化的用户量和其它指标。如果这些路径与我们的预期不一致，而且有相当数量的用户走了常规路径之外的路径，就足以发现产品设计中的问题。（如下图）
　　2.3.2 第三方平台的反馈收集
　　当我们说到收集用户反馈的时候，这类的第三方平台也是经常登场的。不过从这种第三方平台收集到的反馈，内容的质量就不敢保证了，可能文不对题、内容宽泛而缺少核心主旨、言语污秽等等。
　　这样的平台大致可以分为几类：
　　问答平台：对于习惯提问的用户，当遇到问题时，可能首先想到的就是问答平台了。在这些平台上，用户的反馈会以提问和回答的方式出现。比如问某个产品的具体操作方式，探讨某个产品的功能迭代和发展方向等等。
　　社交平台：社交平台应该是最让用户心情放松的平台了。一方面这些平台聚集了各路亲朋好友，另一方面平台自身也会不断评估用户的喜好，向用户推荐符合喜好的内容。因此，在这种放松的状态下，用户更容易留下自己的一些真实想法。从这些平台上收集反馈也是个不错的选择。
　　应用市场平台：除了在产品内部，这是第二主要的反馈来源了。尤其是像App Store这种相对封闭而集中的市场，更便于产品团队收集与自己相关的用户反馈信息。相比之下，数量众多的安卓市场就没那么乐观了，当然也还是有据可循的。另外也可以通过下面要提到的应用分析平台辅助解决。
　　应用分析平台：大名鼎鼎的App Annie就是这个分类下的翘楚，并列的还有七麦数据（原ASO100）等等。这些平台对各大应用市场的数据进行了收集整理。相对于前面那种直接获取反馈的方式，从这些平台获取经过整理的数据会更加高效。当然，这些平台也会把一部分服务划定为收费服务。具体值不值得，就要看用户反馈对于产品的价值了。
　　三、反馈的评估与分级
　　前面已经介绍了一大堆关于收集反馈的内容了。那么收集完了就完了么？当然不是。下面真正＂硬核＂的部分才刚刚开始。
　　3.1 评估影响
　　对于收集来的用户反馈，第一步、也是最最重要的一步，就是评估影响。（按理说，在收集之后最直接的下一步应当是归类整理。但是只要对产品足够了解，这一步不管是铺人力做还是上算法做，都不会遇到太大的＂认知门槛＂。所以这里暂时忽略。）同时，这个环节还需要大量的数据支持。
　　3.1.1 为什么要评估影响？
　　我们都知道，影响越＂大＂的反馈必然越重要，需要优先处理。也就是说反馈的影响程度决定了反馈的重要性。那么怎么定义这个＂影响大＂呢？通俗的理解，影响范围越大越重要、越深远越重要、后果越严重越重要。
　　影响范围下面会重点列出四个方面，先不细说。
　　影响深远指的是会不会影响产品的迭代和发展方向？会不会影响产品现有的功能结构和技术架构？会不会影响产品的整体风格等等。如果对这些重要的方面有所影响，就需要格外重视。
　　而后果指的就是那些公司或团队关心的指标，尤其是KPI相关的指标。比如盈利是否减少、市场占有率是否下降、品牌形象是否受损等等。
　　3.1.2 怎么评估影响范围？
　　在具体操作中，我们可以从四个方面评估影响范围，分别是用户、场景、产品和团队。
　　用户中的范围：这个比较好理解，就是说多少用户面临类似的问题。当然功利地讲，不同用户对于产品的价值也是不同的。比如对于新产品，如果核心种子用户受到了影响，就会比其他尝试型用户重要得多。
　　场景中的范围：这个比较有意思，把控起来也需要一些经验。有些反馈在特定的时间、特定的产品版本中才是问题，脱离了这些场景就不再是问题了。比如，双十一期间由于订单量极大，才会出现服务器响应缓慢之类的问题，但过了双十一就不再是问题了。再比如，产品的特定版本存在问题，如果说服用户更新到最新版本，就没问题了。对于这类问题，可轻可重，要根据所处的时间点和其它因素综合判断。
　　产品中的范围：也就是影响到了产品的哪些部分。用户的反馈是针对某个具体的功能提出的？还是针对某一个模块提出的？再或者是遍布整条产品线，乃至整个产品组合的问题？当然，这其中还要考虑，出问题的模块在整个产品形态中的重要程度。比如对于电商平台，图片服务和支付服务如果出现问题，将会成为整个产品线的灾难。
　　团队中的范围：这部分已经有点工程的味道了，就是说有多少相关团队需要共同合作来解决这个问题。在分工明细的大公司里尤其常见。这种工作决定了需要投入多少成本来解决一个用户反馈中的问题。后边的工程落地部分会详细说。
　　3.1.3 使用＂吐个槽＂评估影响范围
　　＂吐个槽＂平台中有两项功能能够帮助我们完成影响范围的评估——反馈筛选和导出。
　　反馈筛选功能位于【管理后台】-【管理】-【反馈列表】页面的右上角。可用的筛选条件包括：反馈分类、反馈时间和反馈关键词。比如，我们可以筛选出：最近一周认为我们的新功能＂不好用＂的反馈。通过这样的方式，我们就能评估出关于一个问题，到底有多少用户收到了影响。
　　当然，这只是简单的筛选反馈的例子，在＂吐个槽＂平台中的实际用户反馈可能比这个复杂的多，相应的也需要更专业的工具进行分析。这时，我们就需要通过＂吐个槽＂平台的导出功能，获取到原始数据，在进行下一步分析。
　　导出功能同样位于【管理后台】-【管理】-【反馈列表】页面的右上角，与＂设置显示字段＂功能并列。点击后，可以获得用CSV格式保存的用户反馈详细内容，并且不受＂设置显示字段＂的限制，可以获得全部字段。
　　3.2 分级与细化
　　3.2.1 通用的分级标准
　　经过以上评估，我们就知道用户的一条反馈到底重不重要了。但这还是一种定性的描述方式，不够精准，需要量化。比较简单可行的办法，就是进行分级。
　　5级的分级是最常用的。分得再少就缺少了一些中间状态，有些问题不知道怎么归类；但分得再多又太过琐碎，各级之间区分度不明显，不好操作。简单的5级就可以分为：严重、比较严重、一般、比较轻微、轻微。再结合前面说的影响评估做较差，我们就可以制定出具体的划分标准了。
　　比如下面的例子：
　　整体而言，分级是为了最优化地分配团队的有限资源。集中资源修复那些影响巨大的问题。这在工程落地的阶段表现的最为突出。
　　3.2.2 ＂吐个槽＂平台的反馈分级
　　我们在这一部分说了对于用户反馈的几种评估和细化方法。对于＂吐个槽＂平台，我们已经很明显的感受到其＂论坛式＂的用户交流风格了。因此，在对于内容的分级方面，＂吐个槽＂同样使用了与论坛类似的分级方式，让用户更容易理解。
　　首先，我们可以金融【管理后台】-【管理】-【反馈列表】页面。在这个页面选中一个或者多个用户反馈之后，在页面上方就会出现一排专门用来处理用户反馈的功能按钮。在这里，我们着重介绍三个＂论坛风＂的按钮——＂置顶＂、＂标记为精华＂和＂标记为水军＂。
　　其实不需要过多理解， 从字面上大家就能轻松明白它们的含义。＂置顶＂产生的结果，主要是用户反馈的帖子会成为列表中的第一项。团队成员每次打开列表，都会格外关注那些置顶的反馈，体现了反馈内容的重要性。＂标记为精华＂则更侧重于内容质量好，这里不仅是用户反馈的内容质量好，还可以是团队回复用户的内容质量好，对其他用户有帮助参考意义。＂标记为水军＂当然正好相反，指的是反馈帖子的内容不好。
　　四、反馈的落地优化
　　这部分就是前面一直在说的工程部分了。这也是大家做产品的同学最常见的场景——需求、评审、研发、测试、上线的过程。与工程相关的常规工作，我们就不再多说了，重点说一些跟反馈有关的东西。
　　4.1 ＂吐个槽＂的处理流程与工程初探
　　作为一个用户反馈平台，其实＂吐个槽＂是考虑到了团队之间的沟通与功能落地的。其工作流程应当大致如下——
　　当用户提交了反馈，负责运营的同学首先需要把控内容的质量，对它标记精华、操作置顶或者标记水军；
　　之后，如果是需要后续处理的反馈，选中之后可以点击＂待处理＂按钮，表示需要后续工作；
　　再之后，当用户反馈的问题处理完时，可以批量选中相关的问题，并统一回复给用户。如果反馈本身不需要额外处理，也可以使用同样的方法，直接批量恢复用户。
　　在这个过程中，一条被标记了＂待处理＂并且＂置顶＂的反馈，将会始终提醒着相关的负责人关注其进度。目前感觉还欠缺的一点是，目前只有一个待处理的状态，并没有根据互联网产品实际的迭代节奏，对这个状态再进行细分，给用户更明确的反馈。比如像这样：
　　待处理；
　　处理中；
　　处理完成。
　　这些状态，第一是给用户看的，让用户知道自己的反馈的最新进展；其次是给团队成员看的，了解这个问题已经在处理中了还是无人问津的状态；再次，留下了这个概念之后，后续可以从这个点出发，让＂吐个槽＂平台与其他平台更好的融合，共同支撑迭代的落地和监控。
　　4.2 反馈平台普遍面临的工程问题
　　＂吐个槽＂平台在用户反馈层面为运营和客服同学给予了支撑，接下来就到了产品团队层面的需求梳理阶段。既然到了需求阶段，自然要有明确的待解决问题、目标、方案和价值评估。好在这些问题我们已经在前面做了大量铺垫——
　　各种方式的反馈收集，为工程实践提供了需求池的内容来源；
　　了解用户的行为路径，提供了用户视角的最佳实践和测试Case的沉淀；
　　影响评估，为工程实践提供了优先级评估、工作量评估、人员分配、技术方案和架构调整等多方面的参考。
　　但是任何团队的资源都是有限的。在有限的资源面前，我们还会面临其它一些具体的问题：
　　用户的反馈，如何＂搬运＂到团队协作和项目管理中？
　　如何让团队有效地围绕反馈进行协作？
　　紧急情况，如何排除人工低效的影响因素？
　　4.2.1 ＂搬运＂与系统打通
　　针对＂搬运＂，前面关于用户反馈的5个关键点中，我们提到了系统化、自动化的问题。简单凝炼成两个字，就叫＂打通＂。在这方面，贴近技术的工单式用户反馈平台是具备天然优势的。用户的反馈直接与任务和团队协作系统打通。这种实现方式在客服团队比较常见，可惜的是，客服团队到具体执行团队之间的链路上，容易出现大量的人工操作，降低了效率。
　　这种系统打通，表面上看不会提供多少可见的短期价值，但是对于团队整体的紧密配合有很大的帮助；同时又能堵住大家都很忙、＂人力莫名流失＂的漏洞。这种机器能轻松搞定的事情，还是应当交给机器来做。
　　4.2.2 反馈的自动化反馈
　　（注：吐个槽目前已经实现每日/每周/每月的微信推送简报，以及企业微信群周报机器人功能。）
　　要让团队有效的围绕反馈进行协作，重要的一步就是信息同步。信息有断档，大家的认知就无法统一，自然效率低下。
　　前面提到过反馈的反馈，也就是让用户知道自己提的问题处理到什么进度了。可想而知，这个工作如果要用人工来做，特别是在大公司，很可能变成是一项跨团队的巨大工程——产研团队、客服团队、BD团队甚至还有更多。在这种人力损耗面前，系统化的价值就大大凸显出来了。
　　另一方面，团队也需要更高效的获取到用户反馈的相关信息。当用户提出一个问题时，除了直接相关的问题描述、分类等信息，还需要获得这位用户最近的行为轨迹、偏好预测等非敏感信息，以及与这位用户类似的其他用户的非敏感信息。这都有助于执行团队在充分了解状况的前提下，高效地解决问题。
　　4.2.3 紧急情况
　　这种可能是老板们比较头疼的状况。在一些紧急情况下，即便麾下千军万马，却有力不从心的感觉。这里边的问题，还是效率的问题。
　　第一，要说的是工具效率的问题。比如在用户面前直接大显身手的客服团队，就需要为其设计强大的支撑工具。当用户一个电话打进来，与用户相关的信息都要及时传递给接待的客服同学；同时还要有配套的操作工具来帮用户实际地解决问题。最差情况，就算当时无法立即解决用户的问题，也要为客服同学提供一个简单好用的记录工具，这同样是用户反馈的收集过程。
　　第二，要说的是人的效率的问题。比如需要人工进行系统修复的过程，从理解系统抛出来的那些复杂的报警信息，到找到出问题的点，再到最终修复问题，这个流程相当长。再加上如果是大团队，效率可想而知。怎么办？几套常见情况的应急预案是＂必备良药＂。人的行为惯性相对于深思熟虑要高效得多。提前准备预案并经常演练，是实现人的高效的好办法。
　　第三，那么还有没有更好的办法呢？我们下个部分再说。
　　五、发展的大方向
　　5.1 用户反馈平台的通用发展方向
　　前面我们已经将用户反馈从各个角度进行的拆分：
　　从感情态度上，区分积极与消极用户的基本诉求；
　　从收集方式上，区分了定向、常规和广义收集；
　　从重要程度上，给了5级分级方法；
　　从自动化上，评价了人工和自动的应对方案及提高效率的方法；
　　但在前一部分的末尾我们留了个小问题——对于紧急情况，我们有没有更好的办法呢？当然有！就是让紧急情况别发生！也就是从＂处理＂走向＂预防＂的方向。这就像著名的＂质量免费＂观念一样。
　　我们前面提到了，可以通过用户行为分析，来沉淀用户视角下的测试Case。我们收集的大量用户行为Case，其使用场景可不仅仅是对新功能进行自动化测试。根据这些基础数据，我们理应比用户更早的＂反馈＂问题；等到用户找上门来，我们就应当能拿得出像样的解决方案了；或者直接在用户准备提交问题的时候给出解决引导；或者再往前，直接进行产品优化，将问题扼杀在摇篮里。
　　当然实现这个目的并非易事，我们总结一下本文中提到过的＂三座大山＂：
　　信息同步：即尽可能的，在那些与处理用户反馈相关的团队之间实现信息同步，而不是让产品或者运营团队孤军奋战；
　　价值取向：这会体现在各种标准的制定上。还记的前面那张《用户反馈评估表》吗？那些标准应当在你的团队里达成一致意见。
　　观念转变：这是前面最后这部分提到的。就是好的产品质量是免费的，我们是在为糟糕的产品质量投入大量成本，而不是在为改进产品的过程投入成本。这可能会要求团队成员付出一些看似＂额外＂的努力，但这些努力会带来客观的回报…
　　当然，预防不代表对用户反馈＂赶尽杀绝＂，与用户的直接沟通，依然是获得一手资料的最佳途径。
　　5.2 针对＂吐个槽＂平台的发展方向建议
　　前面已经提到了一些关于＂吐个槽＂平台的建议，我们在这里汇总一下，作为未来发展方向的总体建议：
　　在数据来源上，目前＂吐个槽＂平台主要是从实际用户的角度，提交文字描述、配图附件等相关内容。未来，为了丰富更多维度的数据来源，需要在数据源上更丰富，比如：实现从其他系统读取数据，或者支持手动导入数据。
　　在管理后台中，为运营同学增加更多可供标记的内容。前面主要提到了关于处理状态的丰富，其实在这个点上还可以扩展出其他类型的达标标签，比如体验优化项目相关的、负责人相关的、最终问题定位相关的等等。
　　有需要工程落地的反馈存在，这就要求在反馈平台上体现一些＂工程特性＂。＂吐个槽＂平台加入了＂待处理＂状态是一个绝佳的开始。后续在这个方向上，还可以补充＂分配到管理员＂等围绕任务和工程的特性。
　　用户反馈平台的理想状态，就是能最大限度的降低那些普通又频发的问题的处理成本，比如少投入人力、多应用自动化和智能方案。而基于＂吐个槽＂平台目前的功能结构，可以考虑的是通过用户反馈数量自动提取＂常见问题＂，变成半人工半自动的实现方案。这样人工只需要关注那些判定错误的反馈就可以了。
　　— END —
　　相关阅读
　　腾讯吐个槽产品测评大赛报名启动，iPhone XR等你来拿！
　　念念不忘，必有回响｜腾讯吐个槽产品测评大赛结果公布