B端产品的冷启动多是依靠个别大客户，在为大客户做好基本功能之后，随之而来的挑战是不断优化系统，扩大用户范围。
这个过程中，如何让用户快速知道产品的功能？如何获取用户最真实的诉求？如何高效处理用户问题？如何提高用户的使用率？如果读者还没有很好的答案，本文可以为你提供一些非常实用的干货。
一、宣导手册
一份结构清晰，说明详实的宣导手册是必不可少的。B端产品以完成业务工作为主，角色权限多，往往流程又长又复杂，对应的功能操作流也会很长，对于一名新用户（很有可能只是一个学历认知都不高的打工人）来说，学习成本很高，一份好的宣导手册可以给新用户心理安慰，也能帮助企业降低了人员培训成本。
宣导手册要点：
线下培训。在时间精力允许的情况下，产品经理应该亲自给用户做一次功能培训，一方面可以近距离接触实际用户，另一方面可以在培训的时候观察用户的反应，从他们的眼中判断产品的价值。
PS：培训前最好多了解用户的作业场景，避免用户觉得你不专业而质疑产品。
用云文档。传统我们都会以PPT、pdf文档交付给客户，可随着用户需求越来越多，产品迭代越来越频繁，打包、发送文件就会很耗时间，因此，用云文档来提供宣导手册就方便许多。这里要注意的是，B端产品的功能手册不能随意放在外网，需做加密或权限处理，否则容易造成知识产权泄漏。
结构清晰。首先，通过角色权限限定用户可以看到的功能范围，避免用户被与其无关的功能分散注意力；其次，每个功能模块以单独一部分进行功能说明；最后，为了避免太长的功能操作流让用户产生放弃心理，每个功能再分为第一步、第二步……
图文并茂。一图胜千文，但图片也不要放太多，比如一个订单有5个状态，那么放5张图就差不多了，没必要多个字段少个字段也单独贴图，容易把用户搞晕；关键节点、最终操作成功的界面一定要让用户看得很清楚（我经常听到用户说的一句话就是“你看到那个界面就对了”）。
说明详实。关键功能步骤要用线条、框框标出，并在边上加以文字说明；文字尽量简练，文字太多用户看了就觉得很复杂。
二、搞好关系
和客户搞好关系的道理大家都很明白，可关系是个虚的东西，一起吃肉喝酒并不能证明好的关系。大部分客户、用户都是只是因为“工作”才与我们产生交集，产品经理还是需要通过自身硬实力来与客户群体搞好关系。
与客户搞好关系。客户代表的往往是公司的领导层，与他们搞好关系能使产品推广顺风顺水。可如果自己级别不高，对方不怎么会关注到自己，怎么办？解决办法就是体现自己的专业性：产品能带给对方企业的价值、对方要付出的代价、产品的细节等等，我们都了然于胸，能随时告知对方想了解的信息，对方自然会被你刮目相看。与用户搞好关系。用户代表的往往是公司的执行员工，与他们搞好关系能获悉产品后续真实的改进方向。B端产品会收到很多定制化的需求，可很多定制化的需求其实是对方领导想要的，此时如果不听一听实际用户的心声，做出来的东西很可能会让用户很痛苦。学会提问：
放低姿态。我们跟用户打交道的时候，用户往往会将我们当作一个专业人士，或是上级派下来的调研人员，这就会导致用户只会说些“你想听的话，或者是他认为上级想听的话”。因此，在提问之前，我们要放低姿态，与对方拉近距离之后，再做提问；发散性问题。多问没有标准答案的5W1H问题，而不是判断、选择式的问题，比如：问“你觉得A功能带给你哪些价值？”，而不是“你会不会用A功能？”；问“相比于队伍的落后员工，你觉得他们和优秀员工的差距在哪里？”，而不是“你作为优秀员工，有哪些工作技巧？”。放空心态。切忌不可带着预期结果去沟通，这样只会引导用户给出你想要的答案。得到用户真实心声之后，可能结果并不是你所希望的那样，这反而是好事——避免公司资源浪费，有利于及时调整方向。三、问题处理机制
B端产品运营的最终目的是不断优化现有业务流程，从而为公司降本增效。因此，不论产品有没有瑕疵，我们始终做迭代优化的路上，所以，一个标准的问题处理机制非常必要，它能为产品经理、运营人员、开发人员、终端用户省去很多时间和精力。
问题处理机制应说明问题的处理步骤，规范处理过程中谁，在什么时间，干什么，完成的标准是怎样。
举个例子：
一款产品的用户2000人（2个营业部，每个营业部1000人），运营2人（每个营业部1人），产品1人，测试1人，开发5人。
如果把相关人拉个群，一旦某次版本有问题，问题的处理状况可能是：所有人都在反馈同一个问题，用户消息太多将真正的问题描述淹没，用户反馈的并不是系统问题只是不会操作……更糟糕的是，其他没反馈的用户看到群里问题这么多，就会以为产品不行，从而对产品失去了信任。
通过一个好的问题处理机制，各方都会轻松很多。
step1：用户发现问题，第一时间向营业部运营人员上报问题step2：运营人员收到问题后，做初步判断和问题除重，及时通知产品经理和开发团队step3：产品经理收到问题后，确认是需求问题还是系统bug，如是需求问题走需求版本流程，如是版本bug，评估bug影响范围，并交给开发团队处理step4：开发人员收到问题后，对于影响范围巨大的要在2小时内处理完毕；影响范围较大的要在当天处理完毕；影响范围较小的可以放在下个版本迭代中优化；step5：问题修复后，测试需做回归测试，并通知各方进行验证step6：用户验证通过后，开发人员关闭问题四、兴奋型需求
当用户已经使用你的产品，逐渐改变他们原来的工作方式时，可能会发现使用数据总是不温不火，与预期有一些出入。原因往往是多方面的：功能宣导还没到位，用户对产品价值还不认可；用户对新产品的不熟悉、不信任；被领导强制要求使用，内心会有所抵触；系统仅仅是将线下作业搬到线上，没有对业务流程做很大的优化；员工更喜欢直观的线下作业等等。
一个行之有效的办法就是为用户提供超出预期的兴奋型需求。那么，该如何做出兴奋型需求呢？
做好上文提到的搞好关系。了解用户真实的声音，看他们把时间都花在哪里了，工作哪一部分最让他们痛苦。然后，我们再以产品的方式帮助他们解决，让他们既赚钱又不那么累。
多去看看竞品，以及多去玩一玩其他类型的产品。很多优秀的设计光靠自己脑子想是想不到的，我们需要通过他人作品获得灵感，这样在发现新需求的时候，我们能最快的想到设计方案。比如：做业务系统时，设计数据产品的功能，用户会很感激你帮他省下的手工统计报表的时间；考虑中后台产品的用户体验，用户会觉得这是最懂他的系统；
小步快跑。我们以为那个功能用户会兴奋，实际用户内心毫无波澜。所以，此类功能最好先用MVP做验证，再通过大版本开发。
愿读到篇尾的你，成为引领业务的B端产品经理。