B端产品的冷启动多是依赖个别大客户，在为大客户做好根本性能之后，并不断优化系统，扩张客户范畴。那么 ，该如何高效处置用户诉求与疑问，并采用合乎逻辑的运营推销手段，随之而来的挑衅是不断优化系统，扩张用户范畴。
这个过程中，如何让用户快速知道产品的性能？如何获取用户最真实的诉求？如何高效处置用户疑问？如何提高用户的采用率？假如读者还没有很好的答案，本文可认为你提供一些非常适用的干货
一、B端产品和C端产品有那些区别
1、面向对象层面 C端产品面对的用户通常是花费者、个人用户，产品所经手的用户量级通常很大，所以toC产品更注重用户体会，界面设计。 B端产品面对的用户通常是企业、商家，产品的用户量级通常较小，但更注重业务逻辑，所以toB通常为了办事更高效来设计。 2、盈利模式层面 C端产品则更注重快速落实公司商务模式，通常会短时间内开发出MVP投放市场来测试产品的契合度，终极是以大批级的用户来到达盈利目标。 比如说：游戏类，主要直售皮肤皮肤碎片各种充值活动点券夺宝的最终奖励广告等来盈利，该盈利模式要基于有大批的用户; B端产品往往是解决客户具有共性的痛点，由于疑问的解决客户显露付费意愿; 这些痛点可能是开源：增加推销渠道、增加销售渠道(TB的电商)、增加知识起源;抑或节流： 降低生产成本、降低沟通成本、提升控制效率如OAPMP 等;减少外部成本，如商旅服务、政务服务等; 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端产品是逐步打磨的过程，固然解决的是疑问共性，但差异客户也会提现出不同，产品对应的业务场景也在连续变化中，所以不断升级的最终目标是抽离共性、弥合不同，提高产品的安适度，超越竞争对手扩张市场份额。 一份组织清楚，说明详实的宣导手册是必不可少的。B端产品以完成业务任务为主，角色权限多，往往流程又长又复杂，对应的性能操纵流也会很长，对于一名新用户（很有可能只是一个学历认知都不高的打劳工）来说，吸取成本很高，一份好的宣导手册可以给新用户心理安抚，也能辅助企业降低了人员训练成本。 宣导手册精华： 线下训练。在时间精神许可的场合下，产品经理应该亲身给用户做一次性能训练，一方面可以近间隔接触实际用户，另一方面可以在训练的时候观测用户的反映，从他们的眼中判断产品的价值。 PS：训练前最好多了解用户的功课场景，避免用户觉得你不技术而质疑产品。 用云文档。传统我们都会以PPT、pdf文档交付给客户，可跟着用户需求越来越多，产品迭代越来越频繁，打包、发送文件就会很耗时间，因此，用云文档来提供宣导手册就便捷很多。这里要留心的是，B端产品的性能手册不能随便放在外网，需做加密或权限处置，否则容易造成知识产权泄漏。 组织清楚。首先，通过角色权限限定用户可以看到的性能范畴，避免用户被与其无关的性能分散留心力；其次，每个性能模块以单独一部门进行性能说明；最后，为了避免太长的性能操纵流让用户发生抛却心理，每个性能再分为第一步、第二步…… 图文并茂。一图胜千文，但图片也不要放太多，比如一个订单有5个状态，那么放5张图就差不多了，没必须多个字段少个字段也单独贴图，容易把用户搞晕； 关键节点、终极操纵胜利的界面一定要让用户看得很清晰（我常常听到用户说的一句话就是“你看到那个界面就对了”）。 说明详实。关键性能步骤要用线条、框框标出，并在边上加以文字说明；文字尽量简明，文字太多用户看了就觉得很复杂。 和客户搞好关系的道理大家都很明白，可关系是个虚的东西，一起吃肉饮酒并不能证实好的关系。大部门客户、用户都是只是由于“任务”才与我们发生交集，产品经理还是需要通过自身硬实力来与客户群体搞好关系。 1、与客户搞好关系 客户典型的往往是公司的领导层，与他们搞好关系能使产品推销顺风顺水。可假如自己级别不高，对方不怎么会关注到自己，怎么办？解决设法就是体现自己的技术性：产品能带给对方企业的价值、对方要付出的代价、产品的细节等等，我们都了然于胸，能随时告知对方想了解的信息，对方天然会被你刮目相看。 2、与用户搞好关系 用户典型的往往是公司的执行员工，与他们搞好关系能获悉产品后续真实的改进方向。B端产品会收到许多定制化的需求，可许多定制化的需求其实是对方领导想要的，此时假如不听一听实际用户的心声，做出来的东西很可能会让用户很苦恼。 学会提问： 1、放低姿态 我们跟用户打交道的时候，用户往往会将我们当作一个技术人士，或是上级派下来的调研人员，这就会导致用户只会说些“你想听的话，或者是他以为上级想听的话”。因此，在提问之前，我们要放低姿态，与对方拉近间隔之后，再做提问； 2、发散性疑问 多问没有尺度答案的5W1H疑问，而不是判断、抉择式的疑问，比如：问“你觉得A性能带给你哪些价值？”，而不是“你会不会用A性能？”；问“比拟于队伍的后进员工，你觉得他们和优秀员工的差距在哪里？”，而不是“你作为优秀员工，有哪些任务技能？”。 3、放空心态 切忌不可带着预期结局去沟通，这样只会率领用户给出你想要的答案。得到用户真实心声之后，可能结局并不是你所但愿的那样，这反而是好事——避免公司资源糟蹋，有利于及时调换方向。 B端产品运营的终极目标是不断优化现有业务流程，从而为公司降本增效。因此，不论产品有没有缺点，我们始终做迭代优化的路上，所以，一个尺度的疑问处置机制非常必须，它能为产品经理、运营人员、开发人员、终端用户省去许多时间和精神。 疑问处置机制应说明疑问的处置步骤，规范处置过程中谁，在什么时间，干什么，完成的尺度是怎样。 举个范例： 一款产品的用户2000人（2个营业部，每个营业部1000人），运营2人（每个营业部1人），产品1人，测试1人，开发5人。 假如把相关人拉个群，一旦某次版本有疑问，疑问的处置局势可能是：所有人都在反馈同一个疑问，用户动静太多将真正的疑问描述淹没，用户反馈的并不是系统疑问只是不会操纵……更糟糕的是，其他没反馈的用户看到群里疑问这么多，就会认为产品不行，从而对产品失去了信任。 通过一个好的疑问处置机制，各方都会轻松许多。 step1：用户发明疑问，第一时间向营业部运营人员上报疑问 step2：运营人员收到疑问后，做初步判断和疑问除重，及时告诉产品经理和开发团队 step3：产品经理收到疑问后，确定是需求疑问还是系统bug，如是需求疑问走需求版本流程，如是版本bug，考核bug阴碍范畴，并交给开发团队处置 step4：开发人员收到疑问后，对于阴碍范畴庞大的要在2小时内处置完毕；阴碍范畴较大的要在当天处置完毕；阴碍范畴较小的可以放在下个版本迭代中优化； step5：疑问修复后，测试需做回归测试，并告诉各方进行验证 step6：用户验证通过后，开发人员关闭疑问 当用户已经采用你的产品，逐渐变更他们原来的任务方式时，可能会发明采用数据老是不温不火，与预期有一些出入。 原因往往是多方面的：性能宣导还没到位，用户对产品价值还不认可；用户对新产品的不认识、不信任；被领导强制要求采用，内心会有所抵触；系统仅仅是将线下功课搬到线上，没有对业务流程做很大的优化；员工更喜欢直观的线下功课等等。 一个行之有效的设法就是为用户提供超出预期的激动型需求。那么，该如何做出激动型需求呢？ 做好上文提到的搞好关系。了解用户真实的声音，看他们把时间都花在哪里了，任务哪一部门最让他们苦恼。然后，我们再以产品的方式辅助他们解决，让他们既赚钱又不那么累。 多去看看竞品，以及多去玩一玩其他类型的产品。许多优秀的设计光靠自己大脑想是想不到的，我们需要通过他人作品牟取灵感，这样在发明新需求的时候，我们能最快的想到设计方案。 比如：做业务系统时，设计数据产品的性能，用户会很感谢你帮他省下的手工统计报表的时间；斟酌中后台产品的用户体会，用户会觉得这是最懂他的系统； 小步快跑。我们认为那个性能用户会激动，实际用户内心毫无波澜。所以，此类性能最好先用MVP做验证，再通过大版本开发。
二、B端产品做好宣导手册
三、B端产品需要搞好关系
四、B端产品的疑问处置机制
五、B端产品的激动型需求