那么如何做一次成功的宣讲呢？我总结到如下3个要点：
一、宣讲前：了解本次的宣讲对象，明确本次的宣讲目的。
B端产品因为一般涉及到公司的业务流转操作，所以在进行产品宣讲的时候，一般性会有这样几类常见的听众，他们各自有着自己不同的关注点。
基层业务操作人员
我需要负责的模块部分是怎么操作的？操作入口在哪里？我需要按照什么顺序点击哪几步操作？我如何得知自己的操作是不是都正确的？如果不慎系统提示出错了，或者是我人为的点错了，有没有什么补救的方法？我如何知道自己是不是做完了？我成功做完了之后，数据流会流转到哪里？
部门或者业务负责人
这个系统操作起来是不是可以满足我当前的全部业务需求？如果不能满足的话如何处理？使用这个系统数据是否安全？是否可以提升我的人员效率？这个系统比我们当前在用的系统，优势在哪里（如果当前有使用类似产品的话）？是否考虑替换？替换成本是否可以接受？
相关业务模块技术人员
这套系统是否需要在本地做相关部署？如果需要本地部署的话，需要什么资源？当前是否具备，如果不具备，是否可以申请到？系统是否需要与我司的相关业务系统做接口，技术框架等是否支持？后期运行维护的主要工作点有哪些？在我们对于各个不同模块的人员诉求有了初步分析了解之后，接下来就是明确本次宣讲的主要目的。这决定了我们宣讲内容的重点是什么。可以当前业务进程，做不同的侧重。主要包含如下两种场景：
售前打单宣讲：可以在宣讲前先通过简单的寒暄，大致了解一下听众的业务基础，或者他们对于市场上竞品的了解及使用情况。在介绍中可以更有针对性的强调一下我方产品的优势（产品特性本身的优势、价格优势等等）；售后业务培训：那么就更偏重于业务操作人员的流程介绍，最好是按照业务人员的日常工作流区分不同角色职位的人员来分别加以介绍。
二、宣讲中：注意节奏的把握和听众的反应
一场好宣讲最好也按照三个步骤来走。
开场环节，要对于本次的讲解做一个流程的总概性的介绍
主要包括本次的介绍分为哪几个部分。一般来说，建议以先总体讲解+后提问答疑的方式进行。
所以，建议在会议开场时加一句说明，“如果待会讲解时有疑问，可以等到结束时统一答疑。”这样也比较便于双方在有限的会议时间内做全方位的沟通。
总体讲解环节，遇到客户提问需酌情响应
如果在总体讲解的过程中，遇到有影响推进的关键性问题，建议还是先做客户的答疑。只是注意把握好时间即可。
自由提问环节，配合宣讲目的进行有效答疑
常见的提问类型，我这边也做了一个简单的小结：
1）用户流程操作方面的问题
这个问题难度系数相对较低，一般性是因为用户对于当前系统操作不熟悉导致的。
建议如果可以的话，一方面建议在宣讲前期，给予客户开设相关的测试账号并提供一份相关的操作手册，可以让用户先熟悉一下；另一方面在宣讲现场，建议可使用流程图等一些更加形象的图例展示方式来强化客户的观感。
2）业务或者技术需求实现方面的问题
这个问题的难度系统要相对高一些，这方面的问题，也可以归因为3类问题。
第一种是当前已有的功能，这个可能是由于前面整体宣讲过程中未提到，或者讲解时用户没有注意听到导致的。没关系，那就再重复一遍就好。
第二种是当前未实现，但是可以去做或者已经存在于你产品的短期或者长期规划中的功能。这种就是要考验产品经理的画饼功力了。
一般来说，客户会提出这种问题，就说明其对市场是有一定的了解的，而不全全是一个小白老鼠。
那么如果是售前宣讲，我们不妨美化说明一下产品的未来规划，特别是如果是竞品已有的功能，我们可能不仅要有，而且还要想着如何让客户感觉到“人有但我优”。
如果是售后宣讲，我们可以更具实一点，确定有时间规划的可以告知对方排期的安排。如果是未来还没有规划的，可以告知客户我们已经在调研计划中了。
就是第三种就是当前未实现，但是实现起来难度比较大。这种如果是涉及技术方面的问题，就很有可能是关于系统底层整体框架结构之类的。
这种一般性都是出现在售前宣讲，那这种情况，可以让双方技术人员就现有模式下简单探讨一下是否有曲线救国实现的可能性。如果没有的话，可能需要就这个客户本身的价值再重新探讨一下业务重构是否值得，此处就不展开讨论了。
3）报价相关的问题
因为价格问题一般性相对敏感，不建议在过多不同业务部门人员在场的场合进行公开讨论，可以建议在会后由专门的商务或者销售人员配合做具体一对一的跟进。
三、宣讲后：产品的回顾和反思
这个环节其实也非常重要，如果是售前的宣讲，我们可以通过客户现场的反馈来判断客户对于我们公司产品的兴趣和意向程度，后续可以让商务或者销售人员更有针对性的打单。
另外通过客户的提问，也可以了解到之前产品规划和设计上是否还有一些不足之处。闭门造车拍脑袋的产品是经受不起市场的考验的，我们的产品最终是要面向市场，面向用户的。
