在昆明做网络推广B端产品和C端产品有那些区别,B端产品成功的关键

胡先生2023-04-07348

B端产品的冷启动多是依靠个别大客户,在为大客户做好基本功能之后,并不断优化系统,扩大客户范围。那么 ,该如何高效处理用户诉求与问题,并使用合理的运营推广策略,随之而来的挑战是不断优化系统,扩大用户范围。

这个过程中,如何让用户快速知道产品的功能?如何获取用户最真实的诉求?如何高效处理用户问题?如何提高用户的使用率?如果读者还没有很好的答案,本文可以为你提供一些非常实用的干货

一、B端产品和C端产品有那些区别

1、面向对象层面

C端产品面对的用户通常是消费者、个人用户,产品所经手的用户量级通常很大,所以toC产品更注重用户体验,界面设计。

B端产品面对的用户通常是企业、商家,产品的用户量级通常较小,但更注重业务逻辑,所以toB通常为了办事更高效来设计。

2、盈利模式层面

C端产品则更注重快速落实公司商业模式,通常会短时间内开发出MVP投放市场来测试产品的契合度,最终是以大量级的用户来达到盈利目的。

比如说:游戏类,主要直售皮肤/皮肤碎片/各种充值活动/点券夺宝的终极奖励/广告等来盈利,该盈利模式要基于有大量的用户;

B端产品往往是解决客户具有共性的痛点,因为问题的解决客户出现付费意愿;

这些痛点可能是开源:增加推广渠道、增加销售渠道(TB的电商)、增加知识来源;抑或节流:

降低生产成本、降低沟通成本、提升管理效率如OA/PMP 等;减少外部成本,如商旅服务、政务服务等;

3、产品场景和产品形态方面

C端产品的使用对象则更偏向于某一类人群,解决的多为生活场景,比如在家休闲或者外出游玩,轻松愉悦,约束很少,所以往往是APP、小程序形态比较多。如叮咚买菜、健康码、乘车码、亲子社区等;

B端产品的受众对象往往是组织单位,解决的场景多为工作问题,比如公司、学校、政府、特殊群体等,因为对应的多是公司办公场景下的使用,所以往往产品的主力端口为PC端,移动端为补充性端口;如CRM,销帮帮进销存等;

4、产品使用角色和客户耐受性

C端产品使用角色大多为单角色,如陌陌解决个人交友问题、京东到家解决个人商品购买问题、消消乐解决个人生活趣味的问题;基于此C端用户更倾向于感性使用,更具有个性化,用户乐于体验不同的产品,追求产品带给用户的感受,也会分享表达自身的感受和情感,寻求认可和共鸣;耐受性较低,随时可能会流失;

B端用户一般情况下默认是理性的,甚至是具有一定专业性的,比如某些财会人员,仓储人员,销售人员等,追求在功能完备的基础上效率至上,高效准确的完成任务,工作过程中也会受到老板的关注和监督,因为工作关系到整个公司的运作。基于此B端的客户往往行为更为理性,耐受性很强(更换B端产品对于客户方的使用习惯、额外经济成本也很大,这也是B端客户粘度较高的原因);

5、产品结构和设计的差异

C端产品是为了解决用户的某个核心需求而设计的,再加一些辅助的账户、登录注册等周边功能,大多逻辑相对比较简单,开发周期会相对较短;但产品设计上要关注人文和人性,迎合目标用户的需求,需要明确感知用户的需求,做好产品体验,所以对于同理心,交互要求较高;具有较好创意的C端产品可能在问世后短时间内用户获得爆发性的增长;

B端产品在不同行业不同业务之间的处理差异很大,一般都会涉及多个组织部门之间的协作,要求分工明确,责任归属也要清晰,所以在产品设计上往往会设计组织架构,操作权限和数据权限,保障产品能够表达出业务流程;在业务完备的基础上,还能够提高操作效率,降低操作成本和学习成本; 产品层级多、逻辑复杂,开发周期也较长,少则半年多则数年。B端产品一般逐步打开市场,不会有爆发性的增长;

6、关于产品决策的差异

C端产品的决策者一般很简单,使用者本身,决策周期也很快,如一个C端的用户可以很快决策出是否要在饿了吗上点餐、是否要选择用滴滴出行叫车、是否要在某个美妆社区里点击链接买一只口红等;

B端产品的决策者相对要复杂,往往不是某一个人,而是需要在应用中进行协作的一群人,如直接决定购买行为的关键人,话语权最高的老板或高管, 话语权一般,有较强的否决权的企业IT管理者; 还有话语权低,但集体行为会对决策有直接影响企业员工,这些员工可能还来自不同部门、有着不同职级,每个人的诉求都有差异。基于此产品体验不好或功能无法覆盖实际场景时,使用者集体的罢用对产品便是致命的打击;

7、持续运营优化的策略

C端产品,因为面对大量用户,不断留存、活跃、转化、传播是终极目标,这就要求运营人员要持续关注相关数据,DAU,MAU,GMV等核心指标,分析数据找出差异原因,预测趋势,并反馈到产品端不端的迭代优化,形成良好的市场推广闭环;

B端产品,往往是由公司的“客户成功团队”或“售后部”持续跟进独立用户的使用过程及效果,并将问题反馈到产品端不断进行功能性升级维护,B端产品是逐步打磨的过程,虽然解决的是问题共性,但不同客户也会提现出差异,产品对应的业务场景也在持续变化中,所以不断升级的终极目的是抽离共性、弥合差异,提高产品的适应度,超越竞争对手扩大市场份额。

123.webp.jpg

二、B端产品做好宣导手册

一份结构清晰,说明详实的宣导手册是必不可少的。B端产品以完成业务工作为主,角色权限多,往往流程又长又复杂,对应的功能操作流也会很长,对于一名新用户(很有可能只是一个学历认知都不高的打工人)来说,学习成本很高,一份好的宣导手册可以给新用户心理安慰,也能帮助企业降低了人员培训成本。

宣导手册要点:

线下培训。在时间精力允许的情况下,产品经理应该亲自给用户做一次功能培训,一方面可以近距离接触实际用户,另一方面可以在培训的时候观察用户的反应,从他们的眼中判断产品的价值。

PS:培训前最好多了解用户的作业场景,避免用户觉得你不专业而质疑产品。

用云文档。传统我们都会以PPT、pdf文档交付给客户,可随着用户需求越来越多,产品迭代越来越频繁,打包、发送文件就会很耗时间,因此,用云文档来提供宣导手册就方便许多。这里要注意的是,B端产品的功能手册不能随意放在外网,需做加密或权限处理,否则容易造成知识产权泄漏。

结构清晰。首先,通过角色权限限定用户可以看到的功能范围,避免用户被与其无关的功能分散注意力;其次,每个功能模块以单独一部分进行功能说明;最后,为了避免太长的功能操作流让用户产生放弃心理,每个功能再分为第一步、第二步……

图文并茂。一图胜千文,但图片也不要放太多,比如一个订单有5个状态,那么放5张图就差不多了,没必要多个字段少个字段也单独贴图,容易把用户搞晕;

关键节点、最终操作成功的界面一定要让用户看得很清楚(我经常听到用户说的一句话就是“你看到那个界面就对了”)。

说明详实。关键功能步骤要用线条、框框标出,并在边上加以文字说明;文字尽量简练,文字太多用户看了就觉得很复杂。

三、B端产品需要搞好关系

和客户搞好关系的道理大家都很明白,可关系是个虚的东西,一起吃肉喝酒并不能证明好的关系。大部分客户、用户都是只是因为“工作”才与我们产生交集,产品经理还是需要通过自身硬实力来与客户群体搞好关系。

1、与客户搞好关系

客户代表的往往是公司的领导层,与他们搞好关系能使产品推广顺风顺水。可如果自己级别不高,对方不怎么会关注到自己,怎么办?解决办法就是体现自己的专业性:产品能带给对方企业的价值、对方要付出的代价、产品的细节等等,我们都了然于胸,能随时告知对方想了解的信息,对方自然会被你刮目相看。

2、与用户搞好关系

用户代表的往往是公司的执行员工,与他们搞好关系能获悉产品后续真实的改进方向。B端产品会收到很多定制化的需求,可很多定制化的需求其实是对方领导想要的,此时如果不听一听实际用户的心声,做出来的东西很可能会让用户很痛苦。

学会提问:

1、放低姿态

我们跟用户打交道的时候,用户往往会将我们当作一个专业人士,或是上级派下来的调研人员,这就会导致用户只会说些“你想听的话,或者是他认为上级想听的话”。因此,在提问之前,我们要放低姿态,与对方拉近距离之后,再做提问;

2、发散性问题

多问没有标准答案的5W1H问题,而不是判断、选择式的问题,比如:问“你觉得A功能带给你哪些价值?”,而不是“你会不会用A功能?”;问“相比于队伍的落后员工,你觉得他们和优秀员工的差距在哪里?”,而不是“你作为优秀员工,有哪些工作技巧?”。

3、放空心态

切忌不可带着预期结果去沟通,这样只会引导用户给出你想要的答案。得到用户真实心声之后,可能结果并不是你所希望的那样,这反而是好事——避免公司资源浪费,有利于及时调整方向。

四、B端产品的问题处理机制

B端产品运营的最终目的是不断优化现有业务流程,从而为公司降本增效。因此,不论产品有没有瑕疵,我们始终做迭代优化的路上,所以,一个标准的问题处理机制非常必要,它能为产品经理、运营人员、开发人员、终端用户省去很多时间和精力。

问题处理机制应说明问题的处理步骤,规范处理过程中谁,在什么时间,干什么,完成的标准是怎样。

举个例子:

一款产品的用户2000人(2个营业部,每个营业部1000人),运营2人(每个营业部1人),产品1人,测试1人,开发5人。

如果把相关人拉个群,一旦某次版本有问题,问题的处理状况可能是:所有人都在反馈同一个问题,用户消息太多将真正的问题描述淹没,用户反馈的并不是系统问题只是不会操作……更糟糕的是,其他没反馈的用户看到群里问题这么多,就会以为产品不行,从而对产品失去了信任。

通过一个好的问题处理机制,各方都会轻松很多。

  1. step1:用户发现问题,第一时间向营业部运营人员上报问题

  2. step2:运营人员收到问题后,做初步判断和问题除重,及时通知产品经理和开发团队

  3. step3:产品经理收到问题后,确认是需求问题还是系统bug,如是需求问题走需求版本流程,如是版本bug,评估bug影响范围,并交给开发团队处理

  4. step4:开发人员收到问题后,对于影响范围巨大的要在2小时内处理完毕;影响范围较大的要在当天处理完毕;影响范围较小的可以放在下个版本迭代中优化;

  5. step5:问题修复后,测试需做回归测试,并通知各方进行验证

  6. step6:用户验证通过后,开发人员关闭问题

五、B端产品的兴奋型需求

当用户已经使用你的产品,逐渐改变他们原来的工作方式时,可能会发现使用数据总是不温不火,与预期有一些出入。

原因往往是多方面的:功能宣导还没到位,用户对产品价值还不认可;用户对新产品的不熟悉、不信任;被领导强制要求使用,内心会有所抵触;系统仅仅是将线下作业搬到线上,没有对业务流程做很大的优化;员工更喜欢直观的线下作业等等。

一个行之有效的办法就是为用户提供超出预期的兴奋型需求。那么,该如何做出兴奋型需求呢?

做好上文提到的搞好关系。了解用户真实的声音,看他们把时间都花在哪里了,工作哪一部分最让他们痛苦。然后,我们再以产品的方式帮助他们解决,让他们既赚钱又不那么累。

多去看看竞品,以及多去玩一玩其他类型的产品。很多优秀的设计光靠自己脑子想是想不到的,我们需要通过他人作品获得灵感,这样在发现新需求的时候,我们能最快的想到设计方案。

比如:做业务系统时,设计数据产品的功能,用户会很感激你帮他省下的手工统计报表的时间;考虑中后台产品的用户体验,用户会觉得这是最懂他的系统;

小步快跑。我们以为那个功能用户会兴奋,实际用户内心毫无波澜。所以,此类功能最好先用MVP做验证,再通过大版本开发。


相关内容