一、“吐个槽”与普通产品反馈形式对比
1.1普通产品反馈体系形式
从用户到产品的单方面的反馈通道,只能满足用户提出产品问题和建议的基本要求。
用户反馈体系作为产品整个生态体系中的重要一环,用于接收用户的产品反馈便于产品更好地更新迭代并服务于用户,却往往被产品部门所忽视,仅仅用一个简单的入口便承担起整个用户反馈体系的作用。
普通的用户反馈体系,虽然满足了用户基本的反馈需求,但是割裂产品与用户之间的连接,用户无法收到产品回复,无法得知自己所反馈的问题的处理进度,这一定程度上会影响用户的反馈热情、
1.2腾讯吐个槽产品反馈体系形式
以社区论坛为载体的将用户与产品紧密联系在一起的双向沟通渠道,同时也是产品用户运营的重要手段。
腾讯吐个槽用户反馈体系在满足用户反馈需求的同时,将用户与产品运营团队牢牢地联系在一起,产品运营团队对反馈问题的重视和及时回复不仅能够保证用户及时收到问题的处理反馈,而且给予用户产品“主人翁”地位,提供其对产品的认同感。同时论坛的形式也为用户提供了一个可以互相交流沟通的场所,对运营团队来说又不费吹灰之力建立起一个面向所有用户的“社群”,其中里面的社群运营又有一定的门道。
“腾讯吐个槽”产品在满足用户基本产品反馈需求的同时,其社区论坛又是产品用户运营的另一块场地,通过产品运营团队对用户反馈建议的重视程度提升用户参与产品更新迭代的参与感,给予粉丝尊重,建立情感链接。
雷军的小米社区,便是在用户反馈这一方面做到了极致,极其重视每一位用户的反馈意见,同时提升他们的产品参与感,因此在针对“用户反馈”的处理和运营,产品运营部门必须极其重视和正确运营。
二、“吐个槽”产品“用户反馈”看法和处理方法
2.1 用户反馈类型
(1)产品出现问题影响用户体验,不得不通过用户反馈体系来提交问题,且期待产品部门尽快解决此问题。优先级最高
(2)对产品功能方面的建议,希望产品能够开发出满足其某些需求的功能。这些反馈的问题背后可能代表着一个产品部门未曾涉足或不够重视的产品主要功能,但同时也需要产品运营人员去分辨和提炼这些反馈建议背后的真实需求。
(3)产品出现的问题已经被重复提交且并不严重影响其使用,但是对于此款产品的热爱导致其反馈行为。此类用户可以深度运营,对之后的产品可能会有极大的作用。
(4)无效的用户反馈以及与用户反馈无关的类型
2.2 快速及时的用户反馈处理
用户总是基于一定的目的提出反馈,有的是因为产品问题影响其用户体验急需解决,有的是抱有一定的期待因为在使用过程中觉得可以加入某些产品功能可以让产品变得更好。对于这些用户反馈,产品运营团队必须做到快速及时的跟进处理,保证其问题第一时间得到处理或回复,告知其反馈问题的处理进度。这样会让用户在产品迭代的过程中有一种参与感,久而久之对于产品也会有深深的认同感。
2.3运营人员人格化,和反馈用户做CP
对用户反馈冰冷重复的回答往往会让用户感到不快,永远不要让用户觉得在和冰冷的机器人对话而是和一个真实有感情的人在对话,要和这些反馈用户做CP,给他们留下一个好的印象。因此,在回复各类用户反馈时,要用真实活泼的语言去回复用户。比如,用户在提出一个产品BUG后回复“亲,你提交的BUG我们的程序猿GG已经知道了,他正在马不停蹄地处理您的问题呢!”而不是“您提交的问题我们已知悉,感谢您的反馈”;在成功解决BUG后及时回复用户“亲,您提交的问题程序猿GG已经解决了呢,对您造成的困扰表示十分抱歉,我们的产品正是因为有您才会变得更好!”。
将人的真情实感代入到对用户反馈的回复处理,不仅可以获取用户的好感,同时也可以在无形之中增加用户对产品的认同感,与用户做CP,拉近和用户的关系,用户才愿意将其最真实的对产品的想法告诉给你而不是仅仅在表面上敷衍你。
2.4有效用户反馈的深度运营
产品运营团队可以根据用户的反馈频率与有效程度对反馈用户做一个用户分层,将高频率有效反馈用户进行深度运营,此类用户对产品有更大更特殊的贡献,需要做深度的运营使其保持与产品之间的联系,持续对产品做贡献。
2.4.1 提升粉丝用户参与度
将对产品有特殊贡献的用户聚集在一个社群中进行深度运营,邀请其成为之后版本更新迭代或新功能的测试用户,在进行用户调研时对此类用户也可以进行深度的用户访谈,并优先邀请其参与线上活动。
2.4.2 给予粉丝特权
邀请该社群内的粉丝用户参与线下见面会,同时在节日寄送特殊礼品以表示对其的感谢。
对于使用“吐个槽”平台的B端产品,可以在产品端给予这部分粉丝用户以用户特权,如用户标识或者积分奖励。
三、用户反馈类产品产品运营解读和思考方向
3.1用户反馈平台的产品核心
(1)产品在提供用户一个快捷的渠道反馈问题的同时要尽量帮助用户能够描述清楚自己的问题和需求。
(2)产品运营团队能够快速有效率地跟进并处理用户反馈,从产品反馈中获取产品出现的问题以及用户对产品的看法。
3.2 如何减少用户反馈行为成本(描述清楚问题以及描述前解决其问题)并成功反馈
3.2.1 反馈前——通过常见问题栏以及全局滚动通知(新增功能)告知用户解决方案
用户反馈的问题大多是产品经常遇到的问题以及重复提交的问题,为避免运营人员整日忙于回复用户,根据每日或每周的产品反馈汇总总结出几个常见问题并在反馈页面中的常见问题中公示(重大问题可通过全局滚动通知)。在用户反馈前便告知用户让用户知道产品运营团队已经知悉此问题并不需要自己重复提交,从而在管理后台端解放运营人员。
3.2.2 反馈时:输入前——减小用户选择反馈问题分类的行为和思考成本
用户进行反馈的目的只有一个,便是成功提交自己在使用过程中遇到的问题以及对产品的建议和想法。但是用户在反馈时却需要对自己提交的问题进行选择分类,首先此功能增加了用户反馈时的行为成本和思考成本,一旦用户在问题分类中无法找到正确的分类便会造成胡乱选一种或者直接不填问题分类的结果,最坏结果可能会导致用户放弃进行反馈。其次,对用户反馈问题进行分类和分析本就是运营人员的工作,但这一功能却强加这部分任务到用户身上,加重其负担。最后,如果用户在反馈时对问题分类错误或者未进行归类,这些工作最终还是会落到运营人员身上。
如果想引导用户主动进行分类减少运营人员完全不必通过如此粗暴的方式,可以通过更加温和的方式达到此目的。——此功能将在第四章详细说明。
3.2.3 反馈时:输入前——常见问题、吐槽置顶的暗示和输入的hint提示
在用户点击“我要反馈”前,其注意力一定程度会被常见问题以及首条置顶帖子所吸引。根据心理学家洛钦斯的首因效应,通过置顶规范的用户吐槽帖子以及常见问题中建立并公示吐槽标准可以暗示并影响一部分用户规范地去反馈问题和建议;
在用户输入反馈文字前,通过hint提示可以更加直观地提示用户应该正确地进行用户反馈。
3.2.4 反馈时:输入时——建立准确齐全的用户反馈分类
清晰正确的用户反馈分类可以帮助用户将自己提交的问题归类,有助于产品运营团队将用户反馈分类以及有效率地跟进解决。
因为会遇到用户不知道将自己的问题归到哪一类的问题,所以分类要有明确的选项收集此类问题方便运营人员后期归类,例如建立“问题类型不明”分类。
3.2.5 反馈时:输入时——提供浏览器机型选择/版本号自动抓取
用户反馈往往会忘记填写产品的版本号和浏览器或者机型,导致产品运营团队在重现BUG或者追踪产品问题上有一定的困难。输入时提供浏览器机型选择和版本号自动抓取,有助于用户反馈时描述清楚自己的问题。
3.2.6 反馈后——运营人员的及时跟进
对于部分用户反馈,产品运营团队明知其是有效的用户反馈但用户仍然没有描述清楚问题出现场景或者其机型等,需要运营人员手动回复用户问清楚问题细节以便于产品团队跟进。
3.3 如何帮助产品运营团队更有效率的处理用户反馈(管理后台)
3.3.1 用户反馈的收集和过滤
面对大量的用户反馈,产品运营团队首先需要收集这些用户反馈的关键信息包括:内容文字、问题分类、用户ID、联系方式等。
其次需要对这些反馈内容进行判断和过滤,需要将无效的用户反馈的剔除,告知重复的用户反馈已经被反馈过,并跟进有效的用户反馈。
3.3.2 用户反馈的提炼
用户反馈的正确分类:针对有效的用户反馈,可能也会存在一定的问题。例如未分类和分类不准确的用户反馈,运营人员需要修改问题分类保证有效的用户反馈在导出的时候属于正确的分类;
用户反馈的提炼分析:针对使用用户的问题描述,产品人员可以发现潜在的用户需求,将对产品有益的用户需求化为产品需求。
用户反馈的重点标记:对于有效的产品运营团队极其重视的需要快速跟进的用户反馈,对其进行特殊标记以帮助运营人员快速跟进。
3.3.3 用户反馈的执行
有效的用户反馈自然代表着存在的问题,问题自然需要产品运营团队去解决。产品运营团队需要将用户反馈的问题进行需求管理,优先级排序同时将相对应的产品计划告知给用户以表示团队是重视用户反馈的。例如:在用户反馈的问题被确立需求排完期之后及时地告知用户:您的问题将会在X月X日的更新中被解决,敬请期待~
同时,产品团队对于用户反馈出现问题的解决也必须要有一个硬性规定,例如:BUG类问题一经确认后必须优先解决,如无法在当前版本解决,必须在下个版本更新解决。
对于出现的不同类型的问题,都必须在规定的时间或版本内解决而不是因当前过多的需求而拖着导致用户体验持续受到影响。
3.3.4 用户反馈的回复
每一个用户反馈都应该被认真对待即使是无效的,但是每次都手动去回复用户对于运营人员的工作压力也是很大的。回复时在产品端提供回复模板方便运营人员回复用户,节约工作时间,提高工作效率。同时用温暖有温度的语言取代冰冷重复的语言去回复会更好地帮助用户与产品运营人员以及产品之间的沟通。
3.3.5 用户反馈的数据分析
当最终所有的用户反馈被导出到一张EXCEL表格上时,运营人员可以清楚地看到用户反馈各种类型的具体数量和占比。根据这张表格,产品运营团队不仅可以明显地看出目前产品存在的主要问题是什么;用户最急切的需求是什么,也可以发现在“吐个槽”论坛是否形成有效合格的反馈氛围。
四、假如我是PM,我会如何优化这款产品?
4.1 提供用户反馈参考示例
即使已经有吐槽规范、置顶的吐槽示例和hint提示的暗示,用户在进行反馈时仍然有可能无法描述清楚自己的问题,因此在用户提交问题页面,提供用户反馈参考,以一个规范的示例,去提醒用户如何描述清楚自己的问题。
4.2 管理后台提供开放“问题分类”功能,将是否进行问题分类的选择权交给用户
上文提到在用户反馈时直接要求用户填写问题分类会增加用户的行为和思考成本,最终可能会导致其放弃反馈或者乱填问题分类。
我提出的较为温和的提示用户进行问题分类的方式是:
4.2.1 当产品反馈量较少时,可关闭“问题分类”的选择功能,将问题分类的这部分工作交给运营人员,由此运营人员也能准确无误地将用户反馈分类,减少其在修改问题分类的部分压力;
4.2.2 当产品反馈量适中时,提供用户端自主选择“问题分类”功能,即通过文字引导用户主动填写用户分类,减少运营工作压力,产品图如下;
勾选后问题分类框下拉
4.2.3 当产品反馈量过多时,再直接开放问题分类功能,将填写问题分类的行为交给用户。当产品反馈量已经多到产品运营团队无法处理时,因填写问题分类而流失的用户反馈背后的问题其他部门大概率也都会遇到,可以减小错过产品问题的可能性;
4.3 反馈页面全局通知滚动播报栏
当一个产品功能影响到大量用户时,产品必然会收到大量的用户反馈以及他们背后对此问题何时能够得到解决的期望;一个个去回复毫无疑问会增加运营人员的工作量,通过提供全局通知滚动播报栏,在用户提交反馈之前就解决用户的问题,减少运营人员工作量。同时,此功能还可用于其他重要的产品通知。
4.4 反馈内容输入时自动保存
用户在反馈时,可能会因为需要重现问题或临时遇到其他需要忙的事情而暂时退出应用,重新回到反馈页面时之前输入的反馈内容也需要输入最后导致用户放弃反馈行为。
因此在用户反馈时提供输入内容自动保存功能,防止用户在重新回到反馈页面时内容丢失的情况出现,给予用户方便流畅的用户反馈体验。
4.5 提供浏览器/机型选择和版本号的自动抓取功能
用户在反馈问题时往往仅仅只描述自己遇到的问题而忘记填写产品问题的重现环境,产品团队在跟进重现问题时往往会遇到一定的问题。因此,提供浏览器/机型的选择和版本号的自动抓取可以让产品团队更加直接的发现问题所在进而解决产品存在的问题。
4.6 支持修改问题类型
用户反馈问题时选择的分类可能会因为对产品的不了解或者其他原因将问题归于错误的分类,导致运营人员在后续收集分析统计产品反馈数据时出现一定的偏差。因此,提供管理后台的修改问题分类功能,可以帮助运营人员修改错误的分类,为后续的产品运营提供数据支持。
4.7 提供保存回复/回复模板/快速回复功能
当面对大量的用户反馈时,回复这些反馈是一件十分耗时耗力的事,特别是面对许多重复且无效的问题,运营人员可以用统一的话术去回复。因此,管理后台提供回复模板/快速回复功能可以提高运营人员的工作效率。
4.8 支持问题分类的查看与筛选
在运营人员完成对用户反馈的收集和分析时,需要选择有效的问题分类,剔除无效的用户分类并将有效的问题分类导出进行需求的执行。手动的选择用户反馈亦或是将全部用户反馈导出再手动筛选都将会降低运营人员工作效率。
4.9 举报内容的查看及处理
社区论坛的用户反馈社区氛围需要运营人员和用户共同维护。对于用户主动举报的内容,管理后台没有地方可以查看,在后台建立举报内容库,运营人员适时查看并处理,对于举报正确的内容及时处理并回复感谢举报用户,既可以节约运营人员的时间又可以培养用户的“主人翁精神”。
4.10 产品存在的问题
4.10.1帖子回复下拉时帖子详情未固定,关闭时需要上拉到顶端才能关闭;
PC端管理后台点击查看有多个回复的用户反馈,下拉时“帖子详情”一栏未固定,需上拉到顶端才能关闭帖子详情
作者:孙俞杰
本文为「人人都是产品经理」社区和腾讯吐个槽联合主办的“腾讯吐个槽产品测评大赛”中的获奖作品,未经许可,禁止转载。
有关产品测评大赛合作事宜,请联系邮箱:[email protected]