一款基于2B市场的反馈产品分析
本文将会通过基础分析、2B产品的市场特点、何为互动社区以及我对下个版本的策划,4个角度来与大家进行分享。当然,分析以及策略的基础都将围绕相同的目标产品,即“吐个槽” 这款以“建议反馈”为核心亮点的2B 产品。
文中观点主要针对与 小程序版本的“吐个槽”,本人着重体验了小程序版本,至于APP和WEB 版本则略过了,为了帮助大家更好的理解,建议将本文观点映射至小程序版本的吐个槽。
基础分析
一款B端产品的核心往往会被作为卖点重点宣传。
对于“吐个槽”这款产品而言,与微信开展的协作,打通用户到官方,官方到用户的双向信息沟通渠道,确实提供了一种非常特殊的能力,称之为亮点,毫不为过。
以此打造的“建议反馈产品”不仅仅节省了互联网团队的开发资源,更重要的是提供了一种新的能力,而这种能力相信大部分互联网团队并不具备。即:与微信的通讯能力打通。
尽管我不是很喜欢“赢在起跑线上”,但我却不得不承认,原本并不十分出彩,乃至最容易被我们舍弃,不断降低优先级,甚至排期一年后再开发的“建议与反馈”这个功能,因为打通微信,而有了颠覆式的变化。
因为起跑线,将会赢的更加轻松。可是,兔子也会有输给乌龟的时刻,起跑线的优势能构造壁垒,但也终究是起跑线,过程中仍然会遇到许多问题,而每一个问题,都有可能导致项目无法到达终点。
我提出两个问题,视为抛砖引玉,还请诸君思考——“2B产品的市场特点”以及“何为互动社区”。
2B产品的市场特点
2B产品 尤其是以围绕“帮助产品,更好的服务用户”相关能力的2B产品,具备一个鲜明特点,他应该是隐形的,他的存在应该完全隐藏在产品本身之下。
排除一些版权标示,我们几乎难以从用户的视角发现这个服务并不是来自于产品本身。
有部分提供隐形服务的产品,诸如数据统计,客服系统,甚至会完全不被用户察觉,最大限度的减少了对于B端产品的影响。
2B产品的第一个市场特点:
作为互联网团队而言,我希望这个B端的服务能够被用户使用,但我并不希望让用户感知到自己使用了其他的产品,我希望所有我所接入的B端服务,都能让用户产生一种错觉,这个功能是属于我这款产品本身的,而不是第三方的,尽管他的本质任然是第三方的。
这个截图 ,是小程序:腾讯小经费接入的吐个槽社区,我很难将这个界面与小经费建立关联,我甚至没有办法产生这样的判断,这是“小经费的吐个槽社区”或者,这是“小经费的建议与反馈”。
作为B端产品而言,还具备另一个特点:我希望我所使用的第三方服务,是植入到我的流量路径之中的, 是能形成流量闭环的。
也就是说,我不希望这些服务阻塞了用户的使用路径,同样的,我也不希望我自己的用户被第三方服务截流。
我所理解的针对第三方服务的流量闭环,是指具备多个路径到达自有服务,以此形成闭环,用户在整个使用过程当中,极大的降低离场,转场感。这种闭环不仅仅需要满足返回路径,更多的则是正向路径的延续跳转,能够通过第三方服务,进入到下一个自有服务。
目前小程序版本的吐个槽,仅仅满足了前者,仅通过返回的触发,能够回到自有服务。
我们可以尝试思考一个场景,用户在吐个槽页面跳出,这应该被视为原有产品流失用户,还是视为吐个槽流失用户。
B端产品,尤其是以提供面向用户的服务内容,尽量多的去推动用户回流,减少“截流”的可能性。我将其理解为,用户从哪里来,便回到哪里去。
(小程序版 吐个槽的用户路径,仅通过返回按钮,能回到产品自有服务里)
何为互动社区
我们曾经将建议反馈视为信息的通道,一方面是指用户的信息传达到开发团队的通道,另一方面也是指开发团队将一些重要信息,引导信息乃至于教育信息,规则信息传达给用户的通道。
对于任何一个团队而言,都非常重视 用户的意见与反馈,但很遗憾的是我们重视这个通道,并不代表我们有足够的资源来完善和强化这个通道,因为他并不能为我们带来更加直观的数据价值。
我很惊讶于“吐个槽”对自身的定义并不是“通道”,而是一个“互动社区”。
这是一种质变,对于大部分互联网团队而言,我们是不具备打造社区的能力及资源,许多时候,我们甚至连通道的稳定性也没有与之相匹配的资源预算。
从定义上来讲,这是一个让人眼前一亮的概念,有一瞬间,我反问自己,“通道,为什么不能是社区呢?”
遗憾的是,经过我的体验,吐个槽,目前的产品设计里,仍然是在构建“通道”,而非构建基于通道的“社区”
也许,我们很难将通道和社区联系在一起,不妨思考这个问题:在一个管道里,如果只有零散数人,那么他是一个通道,但这个管道一旦涌入大量的人群,数以万计的人流转到这个通道里,他是否就构成了一个社区?
有人的地方,就有社会。通道是从信息传递的角度去看待建议与反馈,如果是站在人数的角度看待,当一个通道拥有足够的人数时,他即是通道,也是社区。
建议与反馈,是具备构造社区的基因的,因为他对一些特定的用户具有足够明确的吸引力。
这些热衷产品,愿意贡献反馈和建议的特定用户,往往可以成为产品的死忠用户。(并不是所有人遇到问题都想去反馈,更多的是遇到问题了,然后就流失了)
建议与反馈具备极大的提升空间,只是单个团队难以付出完成该空间所需的成本,实际上一个基于死忠用户的小社区,并不需要太大的用户基数,日活5万左右,便可构造一个小社区。
对于2B产品定位的“吐个槽”而言,所服务的产品对象,相信大部分都是满足这个数值的。
以目前而言,吐个槽所提供的服务,仅仅满足了作为通道的诉求,能发起反馈,能查看他人反馈,能发布官方信息的作用。几乎没有满足构造社区的特点,比如:氛围。
社区氛围
用户其实是很容易被影响的。在这里,我们可以理解为用户是否发起反馈,是否阅读他人反馈,是否参与反馈,均是受到氛围的影响。
对于面向用户的服务,我们不能用“有”和“无”来判断好坏,基数足够大的情况下,必然会形成“有”的格局。
随着产品用户的增长,一定会有用户发起反馈,也一定会有用户阅读,或者参与反馈,这与我们做好,或者做坏无关,只是人数增长带来的概率效应。实际上,面向用户的服务,都会强调氛围对用户的影响,我们会通过反馈率(反馈人数/页面访问人数)来衡量一个反馈页面的氛围是否构造到位。
通道是工具,工具满足人们既定需求,社区的根本在于氛围,而氛围引导并创造用户需求,再来满足用户需求。
永远不要低估氛围对人行为的影响,实际上,人们大部分的行为,都是受到环境的影响而产生的结果。
什么样的氛围,是以反馈为前提构造的社区应该具备的氛围?
真实、真诚、平等、尊重,这四点是基础氛围,再之上还有活跃,响应,以及竞争(同一个功能的AB派系之争),当然,最重要的是,这里有人,这需要我们构造的人物形象足够丰满。比如:一个大头像,比小头像,更容易让人感觉到“人味”
人们只会在一个相对放松的环境能够畅所欲言,反馈也是用户真实想法,内心话语的倾述。
一个严肃的环境下,只有“忍无可忍”的建议会被暴露出来,俗气点来讲,严肃的反馈社区,只能收集到一些“憋不住了”的反馈,大部分还能“再憋一下”的反馈,是不会被收集到的。
简单来讲,吐槽首页,是在被动的等待用户反馈,并没有主动的引导用户反馈,是冷冰冰的工具,而不是有人味的社区。
如果有这样一句话, 那我们的感知就会产生很大的区别,这便是对氛围的构造。
“非常感谢你使用我们的产品,你的每一个建议,我们都会认真对待,小经费全体团队,期待你的反馈”
顺带一提,你是否还记得,这个页面是从“腾讯小经费”这款小程序进入的建议与反馈。我想,已经很难想起这款小程序的名字了。
我的策划
如果是我来做这款产品的下个版本,我会围绕B端定义,以及社区构造来策划和设计。
1. B端定义
(1)将产品风格以及反馈主场景还给B端客户
产品风格和反馈主场景,是解决“我在哪”这个问题,反馈和建议是从属于主产品的,并不是一个独立的分支。
他需要继承主产品的设计风格,以及主要的氛围场景。
我会将吐个槽主页的视觉主场景“还”给B端,这很简单,只需要开放针对内容的配置项即可,后续迭代也可以在主场景构造不同的风格样式。
2. 让流量从哪来,回哪去
作为产品体系的一个业务,需要有能力联动至不同的业务场景,我会考虑用交叉路径的设计方法替代死胡同折返路径。
我们构思一个场景来理解这个需求吧。
用户进入意见与反馈,必然是对某个业务产生了疑问,前来提出问题,或者寻找答案。
我们假设用户在“吐个槽”经过两次操作找到了答案,并回到业务场景,我们来看看这个流程用户需要经过几个步骤。
- 首页–>二级页面(疑问)–>返回首页–>进入个人中心–>进入吐个槽–>进入二级页面(找到答案)【正向路径】
- 返回吐个槽首页–>返回个人中心–>返回首页–>再次进入该业务【死胡同折返路径】
为什么不能在找到答案时,直接回到业务场景呢?
通过路径交叉,我们能极大缩短用户回到对应业务的流程。
实际上,面对用户的真实操作所产生的路径比我们文中的案例还要长许多,正向路径不能减短,但受到需求(解惑)驱动,尚能推动用户完成该路径。但死胡同折返路径时,由于已经得到了答案,但却是“原路返回”此时,没有需求驱动,在这个漫长的返回路径里出现若干次流失漏斗。
最终,大部分用户并没有回到原来的业务场景,而是流失在返回路径当中。
让流量从哪里来,回到哪里去,并不是指产品之间的跳转,而是指A业务的流量回到A业务里,建立业务和反馈问题之间的交叉路径。
这也仅仅只是开放给B端用户,定向配置跳转页的能力。
3. 社区氛围构造
建议与反馈对于互联网团队而言,其具备的基础价值是信息收集与传达,在此之上,也能一定程度聚集,活跃死忠用户,并且能促使死忠用户的产生。
站在基础价值的角度,我会尝试通过氛围的营造来增加用户的反馈率,获得更多的反馈信息,也会通过一些激励设计,刺激用户提供高质量的反馈。(评测,送奖品,对此类型活动的支持,会是非常有效的方法。)
在我的产品经验里,我发现某个时间点产生的问题,会具有极强的趋同性,比如:我们上线了一个新功能,一定时间范围里,80%的反馈都是围绕新功能展开的。
用户提供的建议,并不是一笔一笔的流水账,反而是和时间具有高度共鸣的信息。对问题趋同性的表达,会增加用户对产品的熟悉感,同时也会引导用户产生共同的关注点,乃至延展教育引导意义。
反馈其实与话题很像,都是极易受到时间,事件的影响。
我会减少热门话题的暴露,更多的暴露用户新提出来的问题,而不是一些所谓的经典问题,要知道许多的经典问题,并不是用户当前最关注的问题。同时,我会将“如同评论一般”的视觉更改为卡片式的内容流,相对于评论视觉而言,卡片本身对内容能起到很好的聚焦以及分割作用。
在多个评论之间,其实上下并没有联系,两条信息是分割的,也是独立存在的,卡片更符合这里的场景。
同时,我取消了时间参数。
时间参数是双刃剑,对于有大用户规模的产品而言,能够用时间表达出“人气”,“热闹”的氛围。然而对于中小产品而言,时间只会产生“冷清”,“不火”,乃至“这个产品是不是死了”的感觉。
我们可以回顾一下之前的截图,在腾讯小经费的吐槽社区里,第一条信息显示的日期是:4个月前。
无形当中,其实是削弱了产品对用户的吸引力,减少了用户的兴奋值和新鲜感,甚至产生一种淡淡的嫌弃。
时间参数在两个环节有弊端:
- 其1,时间是不可逆不可暂停的,今天的信息终究会被贴上1个月前,1年前的标签,若没有持续的新的信息,很容易出现首条信息来自数月前的现象。
- 其2,通过查看两条信息之间的时间差,用户能解读出该产品是否活跃,是否有人气。如果两条信息之间的时间差是秒级,显然是很活跃的社区,如果两条信息之间的时间差是数日乃至1个月以上,显然是极度不具备人气的社区。
这就如同贴吧,火的贴吧,和冷清的贴吧,都会通过时间,很真实的反应出来。
站在产品的角度,我们可以尝试理解,毕竟是反馈和建议,是低频,是极少用户进入的地方。遗憾的是 ,用户并不会对产品的主场景和副场景进行区分,实际上不管是主还是副,用户都会将自己所看到的信息,理解为这款产品怎么样,而不是这款产品的某个业务怎么样。
除了删除时间参数,我还增加了官方答复的标签,放大了人物头像。
放大人物头像,会增加提问的真实感,以及人味,真实且丰满的人物所提出来的问题,恰恰会引起阅读者的好奇,乃至联想,甚至于“这就是我要问的”。
官方答复标签,此时会增加用户的安全感,信任感,从而进入问题详情,查阅答案。
反馈按钮则调整为固化在底部的按钮,在用户翻页浏览内容时,能够最便捷的方式发起反馈,不用再回到页面顶部再来发起反馈。并且我在反馈按钮上植入了一些具有暗示效果,具有亲和力的文案,用来让反馈,倾诉这个行为不显得那么沉重。
以反馈和建议构造的社区还有很多可能性,站在B端的角度要充分考虑到不同产品的背景条件并给予支撑能力。
- 用户量大的产品,每天都有一定流量经过反馈页的,甚至可以植入一些提建议,送红包,送礼品等具有运营性质的能力。
- 用户量少的产品,缺少集中流量的,就需要隐藏产品的缺点,而是去引导死忠用户的产生,给予到足够的尊敬,足够的氛围,促使用户提出宝贵的建议。
总结
我认为,针对拥有核心优势的产品,无需堆砌太多重量级功能,反而是需要注意许多细节与体验,在产品设计上,尽量去依赖核心能力,尽量不要去干扰核心能力。
吐个槽的核心能力拥有非常强的市场竞争力及壁垒效应,此时,不需要增加过多的所谓的核心业务,而是应该去包装,完善核心能力的使用场景,以点破面。
我将其称之为 大招少一点,秒招多一点。
简单来讲,“吐个槽”拥有核心能力,但缺少对B端产品的洞察,尚且没有明白“帮助B端客户服务客户所拥有的用户”的含义,所以在做法层面,甚至没有在服务内,给到B端产品署名权。
同时,以“建议与反馈”作为根基 构造互动社区仍然处在探索阶段,还没有完成社区的构造,目前仅仅只是名字被称呼为“互动社区”“吐个槽社区”,实际上,仍然只是一个信息传达的通道。
在吐个槽官网首页,有这样一句话:
我想指出几个点:
- 也许客户需要的是腾讯网一样功能强大的互动社区,而不是指“长得一样”的互动社区;
- 如果没有腾讯网的流量,即使长的一样,也不会具备太大的收集反馈的能力;
- 副标题是让反馈变得便捷,轻巧,那么,反馈和社区有什么关系呢,难道不应该是“让社区收集更多的反馈,更高质量的反馈吗”;
- 或许这里想表达的是“接入便捷,开发轻巧”,但不要忘记,这项能力,即服务于客户,也服务于用户。
Ps:具备核心能力,已经赢在起跑线,但龟兔赛跑的故事屡屡上演(OFO),不忘初心,方得始终,与诸君共勉。
相关阅读
腾讯吐个槽产品测评大赛报名启动,iPhone XR等你来拿!
作者:作者:枯叶,微信公众号:枯叶咖啡馆。人人都是产品经理专栏作家。7年产品人,3年产品总监
本文为「人人都是产品经理」社区和腾讯吐个槽联合主办的“腾讯吐个槽产品测评大赛”中的三等奖作品,未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
写的不错
给枯叶大神点赞