- 不要只看重文档的页数，更重要的的文档的质量。在完成解决方案的时候，不写大家都知道的业务现状，只谈业务中需要改进的问题。不要写功能清单，而是要按照企业业务写应用模式和效益，如果有功能清单或者其他相关介绍，可以通过附件的形式单独提供。简单的阐明实施思路和策略，而不需要将详细的实施计划列出来。也可以在方案中重点介绍一两个接近的客户资料，其他客户则提供清单即可。
- 写解决方案的时候，我们就要像写议论文，需要有观点鲜明、有理有据、有血有肉。好的解决方案不但要能够发现问题、提供答案。更要去研究这些问题是怎样产生的，以及如何解决这些问题。
- 在方案中一定要想办法设计一些简明清晰的图表，把写WORD方案当作演示文档一样的书写，减少文字的比例，把大段的解释变成图标式直观表达。对客户而言，评价一份方案质量，往往也就是通过方案图表质量来感觉。
好的方案首先要把能支撑解决问题的论点穷尽出来，每个论点都是独立的，不能和其他论点重复论证。所有的分论点是有层次的，大的分论点要能覆盖小的子分论点，同层上的分论点在逻辑上是平级的，同级的论点在文档内是同一级标题。子标题是上级总标题论点的分论点，逐层论证，然后每个分论点一定是在前一个分论点的基础上往前深入进一步，一句话一个意思，一层意思推动一层意思，就想剥笋一样，层层剥开，问题解决思路也就步步清晰了，企业看起来也就非常清楚。
这种论证的过程就是一个金字塔型的结构，论据（各级分论点和事实证据）构成金字塔坚实的基础，论证逻辑的合理性是联结金字塔的纽带，最后的论点就是我们要让客户认可的核心价值。
- 在给客户写售前方案时，建议尽量用客户做前缀，例如说某某企业的某某项目，让客户觉到针对性，认为这个方案的确是为客户准备的。而对于自己公司的名字，只需要出现几次便可，最好不要重复出现。我们可以通过页面标志（页眉页脚等）突出我们的存在。
如果确实需要用一些企业实际情况说明企业业务已经存在的问题，不要用刺激性强的语言。例如表达"企业业务存在问题"可以用"企业有可改进的地方"的说法，表达"企业管理"可以用"管理上存在难以控制的环节"的说法，这样的表述企业更容易接受。
此外，如果项目是要给政府申报或提交专家评审的材料，这种方案就必须侧重逻辑图、原理图或业务图等思路性内容，少用接口等成果性内容，文字也要专业化术语话，少用企业易于理解的大白话。
- 考虑到项目的售前周期从提交解决方案到正式实施需要半年甚至更长的周期，那么解决方案的技术方案可以适当超前，充分融合公司最新产品规划来考虑系统解决方案。
- 利用范本复制的方案如果不经过很好的核对，往往容易出现各种低级错误，例如常见：
- 替换不完整，在方案中出现了其他企业的名称
- 替换过度，把一些典型案例中的典型客户名称也替换成为方案客户名称
- 只注意文字替换，不注意图形中文字包含的客户名称或其它内容替换。
- 只注意正文替换，忽视页眉页脚的替换，特别是在首页或目录和正文不同的情况下
- 目录不对，忘记刷新，出现页码或者标题名称错误。
- 案例不对，没有查到本行业案例，案例全部都是其他行业的。
- 联络方式不对，给不同地区方案需要注意更正服务信息和联系方式。
- 文件属性没有更改，导致在资源管理器浏览时显示其他企业的名称。
- 存在大量技术硬伤，包含大量非本行业的专用词汇和概念，和正文内容无关。