一款产品,需要「用户反馈入口」吗?

我是一名运营,当和产品提出可以加个反馈入口,这样集中收集一波用户真实反馈,形成一个意见池、需求池,或许会有什么意想不到的发现,帮助优化产品,实现新功能。可是产品小哥回复我,没必要啊,收集反馈发问卷就好了。

所以是这样的吗,一款产品,需要「用户反馈入口」吗?

回答·91
最热
最新
  • 一、用户反馈系统要实现什么? 用户反馈旨在能将用户的想法传递给产品方并进行处理后满足用户需求或功能迭代,也可通过反馈的数据分析进行产品迭代优先级排序。 1.用户反馈场景有哪些(场景丨画像丨方案) 产品部分功能体验差(BUG、功能不足……):暴躁的用户、难受又不忍离去的用户——及时处理,挽留用户; 产生功能需求(如:突发奇想;真实需求;看到别的产品有该功能,但又被沉没时间成本束缚……):资深用户、付费用户——沟通反馈,KOL 挖掘; 需要平台方帮助(引导、投诉):产品萌新、领域小白、受气的宝宝……——平易近人,增加融入感,一副大哥罩着你的样子。 2.用户反馈流程 用户侧反馈流程分为前、中、后三个步骤。 反馈前,用户找到反馈入口,准备提交反馈或直接由 FAQ 终止反馈; 反馈中,用户提交反馈内容,包含故障时间、问题所在、图片上传、联系方式等; 反馈后,产品方进行处理并对用户反馈进行终结,还可以以此作为建立社群的一个流量入口。 3.用户反馈系统双方需求分析 反馈方: 轻松找到反馈通道; 反馈过程通畅无阻; 反馈后能问题可被快速解决。 关键痛点:各平台反馈入口深度参差不齐;反馈流程周期长;问题泥牛入海。 被反馈方: 及时接受用户反馈; 收集用户需求; 处理流程高效简单; 可以获得产品迭代思路。 关键痛点:问题筛选过程复杂、处理流程滞后。 二、用户反馈系统功能 从反馈前中后三个步骤展开分析现阶段的用户反馈系统都涉及哪些功能,需要达到什么效果。 1.反馈前 在用户进行反馈前,排除产品结构需求,要尽可能降低反馈入口深度。如果实在无法实现降低深度也可以将入口位置尽可能的符合用户使用经验,比如:反馈放在【我的】-【帮助】下面。 除此之外,在用户反馈前可通过 FAQ 的形式进行“反馈过滤”,节省人工成本。 2.反馈中 除了接通人工客服外,反馈主要以填写表单的形式进行,一般都具备以下功能: 文字填写:最基础的反馈方式; 图片上传:截图或拍照的形式更方便用户表达,产品方也能更快的解析问题所在; 联系方式:手机号、邮箱的留存方便客服人员进行问题跟进及回访。 除了以上基础功能外,还有一些方式可以帮助用户更清楚地表达,如: 支持语音输入; 故障时间选择,微信中的反馈系统具备此功能,可以帮后台进行问题定位,也可以分析出问题时间段。 3.反馈后 反馈后系统提醒是有必要的,给用户时间预期可要比客服联系后说“久等了”效果更好。除此之外,也可以放社群链接或问卷调研,当然这里要注意问卷调研中要考虑用户的负面情绪。 三、产品方处理流程 用户反馈后通常需求会经过信息收集——需求过滤——分类后分别对接客服、产品、测试(——评审/开发)——回复用户——闭环反馈这几个步骤结束整个反馈流程。 产品方处理流程可用下图进行表示: 管理员作为与用户接触的唯一出口,判断需求后分别进行反馈,待确认解决后进行用户回复,当用户有反复疑问时,就可能会出现反馈不及时的现象。 在一些 ToB 产品的反馈流程客服作为一个对接角色将需求反馈后直接由技术人员对接,这样可以大大提高效率。 四、简单问题复杂化 上文提到的反馈功能可以满足基本的用户反馈处理流程,客服的人工筛选时间及对接时间是否可以等到进一步优化,我觉得可以“简单问题复杂化”,也可以说繁琐问题功能化,从功能优化上进行效率提升。 功能前提: 反馈前用户需进行问题分类选择操作,可采用多级分类,但一级分类必选,且分类表述需要明确、清晰。如:BUG、引导、功能建议、投诉等; 产品方管理员在后台可对需求反馈类别进行选择,类似于权限设置,如:管理员 A(测试)只选择接受 BUG 反馈; 可设置反馈消息推送,实时反馈,当然为了避免非客服人员受用户频繁反馈打扰,提供推送时间段、频次选择。如:产品经理可接受功能建议,设置为每周一次反馈; 反馈可在管理员中互相推送。考虑到用户对问题的判断力不足,当一级分类选择错误推送至错误的管理员处时,管理员可将问题推送至相关人员处。 对于反馈量少的产品没这个必要,毕竟还是存在一定开发成本的,但对于大反馈量,可在需求筛选和人员安排方面有效解决问题。
  • 如果是 TB 的产品,其实可以直接看后台的数据,区分不同类型的客户,进行客户回访。如果方便,可以直接到客户那里去,面对面沟通进行需求沟通,在系统内收集加反馈的入口收集的是比较零散的,还不如直接拜访客户。 如果是 TC 的产品,其实一般普通用户是不会去反馈的,加这个功能前 还是得看目前的使用人数,是否有足够多的人群?活跃用户等,是否有可能会有人去反馈,反馈是否会获得奖励,鼓励他们来反馈?用户反馈后是否会对产品、对企业有帮助?是要收集需求,还是 bug 等。
  • 问卷收集的是想出来的问题,反馈收集的是及时的问题.但是加了反馈你就需要维护,如果客户反馈多次无结果后很可能造成客户的流失.
  • 这个要看你的产品是 TB 还是 TC,还有目前的产品及所处的阶段,还有目前的客户量,等这些都应该考虑 (1)如果是 TB 的产品,其实可以直接看后台的数据,区分不同类型的客户,进行客户回访。如果方便,可以直接到客户那里去,面对面沟通进行需求沟通,在系统内收集加反馈的入口收集的是比较零散的,还不如直接拜访客户。 (2)如果是 TC 的产品,其实一般普通用户是不会去反馈的,加这个功能前 还是得看目前的使用人数,是否有足够多的人群?活跃用户等,是否有可能会有人去反馈,反馈是否会获得奖励,鼓励他们来反馈?用户反馈后是否会对产品、对企业有帮助?是要收集需求,还是 bug 等 (3)最重要的还是看公司当前所处的阶段,是否有人有精力去维护那块,如果只是有人反馈,没有人去回复、去整理,其实是没有用的,一定要用起来才能达到效果。另外还要看产品所处的阶段,是否产品已经能满足基本用户,当前阶段需要收集更多的意见等
  • 这个问题本身非常的片面,没办法当下立断对与错,不同行业不同业务不同产品,诉求不一样,不一定做了就一定好! 如果你们公司做的业务是用户的行为链路相对简单,用户不需要过多的去进行功能探索,那建立用户行为路径分析或转化漏斗就完全可以来观测过程中的问题并进行优化,没有太大必要开通一个入口。一旦开通,就要有整套的从反馈内容设计,收集,推进,回复,更新迭代等一系列问题,甚至还要考虑奖励激励机制。这个过程无形当中增加了额外成本。 而,如果是一个复杂业态的产品,且开放了多功能入口,这时候留一个问题反馈入口不如开通在线客服,对待问题的解决效率远要高于收集问题的用户体验。由客服定期再向产品反馈用户问题,并又产品进行统一优化,这个链路效率更高。
  • 需要,但是要见势而行
  • 如果是 TB 的产品,其实可以直接看后台的数据,区分不同类型的客户,进行客户回访。如果方便,可以直接到客户那里去,面对面沟通进行需求沟通,在系统内收集加反馈的入口收集的是比较零散的,还不如直接拜访客户。 如果是 TC 的产品,其实一般普通用户是不会去反馈的,加这个功能前还是得看目前的使用人数,是否有足够多的人群?活跃用户等,是否有可能会有人去反馈,反馈是否会获得奖励,鼓励他们来反馈?用户反馈后是否会对产品、对企业有帮助?是要收集需求,还是 bug
  • 肯定需要啊,集思广益,可以得到用户问题和用户需求,用于产品改进升级……
  • 作为运营者需要 作为软件产品纠结 作为开发就想杀人了 作为客服觉得在搞事情 作为客户就是情绪宣泄 作为老板有数据依据就可以搞事情了 总结一下对于企业而言是需要的,但要知道客户特别是 c 端客户,他们的诉求往往情绪化,各部门拿到数据的反应也是情绪化的,有要借题发挥的,有贬低质疑的,大家可以根据自己的职务对号入座
  • 答案是需要的。 用户反馈入口是用户自发的反馈渠道,能较为真实地让客户主动地即使地反馈他在产品使用过程中的困难。为增加客户与产品提供方的一对一直接对话提供了渠道。 最直接的例子就是国内大多数软件,在卸载的时候普通增加了反馈收集。一方面是放慢客户卸载的速度,给予用户二次思考的时间;另一方面就是为了收集客户卸载的主要原因,为产品优化提供了指南。 至于反馈渠道什么时候做与怎么做,下面给出我的一点建议: 产品若处于稳定成熟期,可以尝试增加此项功能。因为在成熟期之前,公司一般会将大部分的资源都投放在拓展市场和完善核心业务上。无谓在非主线流程上浪费时间和金钱。 在实现上,一般需提前将用户的反馈进行细致的分类,以方便后期做统计筛选之用。一般地,只有少数的集中被反馈的问题会被得到解决。