B端产品成功的关键——运营推广

0 评论 9954 浏览 65 收藏 11 分钟

B端产品的冷启动需要依靠大客户,并不断优化系统,扩大客户范围。那么 ,该如何高效处理用户诉求与问题,并使用合理的运营推广策略。本文总结了几点用户运营策略,希望对你有所帮助。

B端产品的冷启动多是依靠个别大客户,在为大客户做好基本功能之后,随之而来的挑战是不断优化系统,扩大用户范围。

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

一、宣导手册

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

宣导手册要点:

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

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

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

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

图文并茂。一图胜千文,但图片也不要放太多,比如一个订单有5个状态,那么放5张图就差不多了,没必要多个字段少个字段也单独贴图,容易把用户搞晕;关键节点、最终操作成功的界面一定要让用户看得很清楚(我经常听到用户说的一句话就是“你看到那个界面就对了”)。

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

二、搞好关系

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

  • 与客户搞好关系。客户代表的往往是公司的领导层,与他们搞好关系能使产品推广顺风顺水。可如果自己级别不高,对方不怎么会关注到自己,怎么办?解决办法就是体现自己的专业性:产品能带给对方企业的价值、对方要付出的代价、产品的细节等等,我们都了然于胸,能随时告知对方想了解的信息,对方自然会被你刮目相看。
  • 与用户搞好关系。用户代表的往往是公司的执行员工,与他们搞好关系能获悉产品后续真实的改进方向。B端产品会收到很多定制化的需求,可很多定制化的需求其实是对方领导想要的,此时如果不听一听实际用户的心声,做出来的东西很可能会让用户很痛苦。

学会提问:

  • 放低姿态。我们跟用户打交道的时候,用户往往会将我们当作一个专业人士,或是上级派下来的调研人员,这就会导致用户只会说些“你想听的话,或者是他认为上级想听的话”。因此,在提问之前,我们要放低姿态,与对方拉近距离之后,再做提问;
  • 发散性问题。多问没有标准答案的5W1H问题,而不是判断、选择式的问题,比如:问“你觉得A功能带给你哪些价值?”,而不是“你会不会用A功能?”;问“相比于队伍的落后员工,你觉得他们和优秀员工的差距在哪里?”,而不是“你作为优秀员工,有哪些工作技巧?”。
  • 放空心态。切忌不可带着预期结果去沟通,这样只会引导用户给出你想要的答案。得到用户真实心声之后,可能结果并不是你所希望的那样,这反而是好事——避免公司资源浪费,有利于及时调整方向。

三、问题处理机制

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:用户验证通过后,开发人员关闭问题

四、兴奋型需求

当用户已经使用你的产品,逐渐改变他们原来的工作方式时,可能会发现使用数据总是不温不火,与预期有一些出入。原因往往是多方面的:功能宣导还没到位,用户对产品价值还不认可;用户对新产品的不熟悉、不信任;被领导强制要求使用,内心会有所抵触;系统仅仅是将线下作业搬到线上,没有对业务流程做很大的优化;员工更喜欢直观的线下作业等等。

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

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

多去看看竞品,以及多去玩一玩其他类型的产品。很多优秀的设计光靠自己脑子想是想不到的,我们需要通过他人作品获得灵感,这样在发现新需求的时候,我们能最快的想到设计方案。比如:做业务系统时,设计数据产品的功能,用户会很感激你帮他省下的手工统计报表的时间;考虑中后台产品的用户体验,用户会觉得这是最懂他的系统;

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

愿读到篇尾的你,成为引领业务的B端产品经理。

本文由 @吴德馨 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!