一款基于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），不忘初心，方得始终，与诸君共勉。
