解决方案汇报：4个方向、18个关键内容，不再让汇报枯燥乏味

经常给相关人员（领导、合作公司、甲方单位、监理单位）进行项目汇报，你是不是会发现，汇报结束后总能发现一些不满意的内容，特别是重点内容或者关键内容没有能够全部表达出来，即使有些内容点到了，但是没有讲透，根本不具有杀伤力，没有起到打动客户的预期效果。更甚至汇报从一开始可能就没有抓住客户听下去的欲望，直接被客户打断，场面一度失控，汇报交流基本维持在给面子的层面，基本不会有下次交流的机会。白白把商务前期做的局浪费掉。除了以上总结的问题，我相信每个人还有自己个性化的问题。如果打破这种僵局，最起码让自己经过一段时间的锻炼，能够熟练地进行汇报讲解，逐渐达到前期制定的预期效果。

针对以上问题，个人有两点建议：

1、如果你是那种非常聪明、悟性非常高，经过老员工的指点或者一段时间的锻炼，你就能够胜任这份汇报交流的工作，而且每次都能过讲到客户的心里，更甚至汇报交流的会议的发展方向都能够根据你的思路进行，也就是你的控场能力非常强，那建议你没有必要继续往下阅读次文章。工作这么多年，小编只遇到一位同事有这个能力，很强、很佩服、很气人，但是没办法。

2、除了第一条描述的那种人，我相信大部分人和小编一样，都是需要脚踏实地的一步一步往前走。如何往前走是有一定的方法的，不是盲目前行。根据小编的经验，要想熟练的汇报交流，其中最重要的就是固定自己的汇报模式，也就是汇报的框架，然后框架的内容根据不同的场景进行定制，这样既能给客户从整体层面灌输你的汇报思路，而且客户也能够清楚，那一部分是自己需要详细了解的部分。

那么，一个优秀的汇报思路应该是什么样的？需要包括哪些内容呢？

首先，一个修改的汇报思路至少应该包含如下几个方面：

• 建设背景的理解
• 总体规划的设计
• 建设内容的规划
• 实施保障的措施

以上4点是一次汇报必须包含的内容，可以这么说，缺任何一块，你的汇报都是不完整的，只不过你讲解的过程中，可能有些部分需要强调，有些部分需要弱化。

接下来需要我们细化上面四个部分的内容，具体每个部分包含哪些章节，每个章节需要包含哪些内容。

建设背景

建设背景应该包含如下几个方面：

• 行业发展趋势
• 面临的问题
• 需求分析

行业发展趋势：

行业的发展趋势是我们汇报交流应该首先讲解的内容，因为这部分内容是客户最想听到的（大部分客户对行业的发展趋势都不是很了解），是他们一次学习的机会。这部分内容讲解就像谈恋爱的第一印象，处理不好，后面要想提起来客户的兴趣就很难。

这部分内容分两个方向进行讲解，第一就是政策，第二就是行业发展动态，特别是比较发达地区该行业的发展趋势。

面临的问题：

面临的问题，说白了就是要与客户产生共鸣，你们遇到的问题我非常了解，让客户觉得你就是他们的知己。一旦产生这种会议效果，，他们对你排斥的心里状态已经完全没有了，可以说，接下来你的汇报就非常顺利，而且他们非常愿意听你讲解。

需求分析：

剖析了他们面临的问题，从他们的问题中我们就能够梳理出他们的需求，也就是希望拿那些办法解决他们的问题。需求分析最重要的就是要与他们面临的问题相结合，不要做一些无事生非的事情，客户非常讨厌，因为他们觉得你在骗他们的钱。反之，你一定让用户认为，你是来帮他们解决问题，而且很努力，那么你就做的很好了。

总体规划的设计

总体规划应该包含如下几个方面：

• 建设目标
• 建设思路
• 总体架构
• 功能结构

建设目标：

建设目标其实就是客户最终想达到的效果，建议你提前通过其他途径了解一下，尽量与客户的想法保持一致，不然可能出现实质性的偏差，你就尴尬了（曾经遇到过，后续基本就是以失败告终）。

建设思路：

建设思路就是你用什么手段达到客户预期的目标，这部分内容重点就是让客户认为是可行的，能够接受的，而不是漫天吹牛，给客户的感觉就是根本无法落地。

第二就是，为了达到客户的目标，你第一步会做哪些，第二步会做那些事，之间有什么关联，是打基础还是为提升性能等等。还是那句话，就是可行性。

总体架构：

总体架构通常需要利用一张架构图来来表达各系统之间的关系，包括接口关系、数据库关系、业务关系、访问关系等等，具体大家可以参考我的专栏，里面包含了常用的20个架构图，内容全部为PPT，可以直接进行二次编辑修改。

功能结构：

功能结构不是很重要，因为一般领导都不是很关心，但是你要与项目预算想匹配（凑也得凑够），不然客户预算1000万，你就写了几个功能点，那不是搞笑么。

建设内容的规划

建设内容根据项目的规划进行罗列就可以，但是有一个原则就是“先总体--后详细”。

建设内容可以分章节介绍，具体拆分的细节根据实际情况进行选择，给大家举个例子参考：

如果客户计划建设一个整体平台，包括很多个系统，建议按系统进行拆分，每个系统尽量把亮点和业务流程提取出来，这样你自己讲起来也不会很乱，客户听着也有条理。如果你拆的太细，你会讲起来繁琐，而且客户不一定买单。但是你要有所准备，如果客户对那个系统需要详细了解，你是能够快速响应。

如果客户只是计划建设一个系统，那么你需要按系统的模块进行拆分，主要体现你对业务的理解和功能模块的熟悉。

实施保障的措施

实施保障应该包含如下几个方面：

• 实施步骤
• 运维保障

你讲得再好，客户最关心的就是你的实施保障，也是对你实施能力的考验。

我们应该从实施步骤和运维保障两个方面进行表达，实施步骤表达我们是有经验的，对实施流程是非常清楚，运维保障就是我们项目实施完成了，还会给你提供对应的服务，不会跑路。如果有条件，把给一些优质人员的信息放上来，彻底把用户怀疑的心里消灭。

以上就是我个人的理解，希望能够对大家有帮助。

如果觉得有用，请转发、点赞哦，非常感谢！