售前材料学习范文

售前材料学习范文 如何写售前技术解决方案 一、引言主要讲信息化趋势，企业所属行业，特别是竞争对手的信息化动向。 二、企业现状分析主要是问题分析，问题是指信息化可以解决的问题，无关的问题不要谈。 这些问题有共性，比如信息孤岛无法集成和共享，企业流程效率低下，成本无法有效控制等等，同时，也要分析本企业及所属行业的一些特殊性问题，比如快速消费品行业对高效供应链管理的迫切需求。 这些问题的写法可以借鉴一些咨询公司的方案，尤其是问题的表达，很多咨询公司的方案堪称典范。 三、信息化如何解决这些问题。 本部分是重中之重，一般说来，要分成以下小章节。 1。 关键业务流程，信息化功能实现（重点，用流程图，数字，模型说明信息化功能实现，特别是如何解决企业现在面临的问题）2。 流程优化与重组。 3。 企业最佳业务实践复制。 四、实现的价值和收益要区分可以计量的，和不可以计量的，可以计量的，甚至可以细化到资产负债表事项。 五、项目实施初步规划可以用甘特图作简单描述，说明时间，阶段，成果，参与人员等。 六、项目资金概算。 软硬件投资，咨询费用，新增的项目组人员薪资等。 这个概算，也是作为一个初步报价的过程，具体价格要慎重，不可多写，也不要少写，摸清对方心理底线。 七、一些建议。 如，尽快启动项目，要注重项目组成员的福利待遇等等。 我的感觉是，文字尽量控制在100页以内比较好，同时，一定要出一个简化版本，将方案浓缩在3页，5页A4纸上，这样便于领导查看主要数据。 售前浅谈1.售前人员需要具备的素质售前人员应该是项目开发人员与业务销售人员的桥梁，在业务销售人员眼中，售前人员扮演的是技术人员或技术专家的角色，而在项目实施中的开发人员眼中，售前人员是专注技术的销售人员，在用户眼中，售前人员，是代表公司技术水平的技术专家。 在一个具体的售前技术支持活动中，售前人员协调销售人员、用户、后期开发人员间的关系，将公司的技术实力向用户展现，听取用户的初步需求，与用户讨论项目系统的初步框架，协助销售人员将公司的产品和技术优势推荐给用户，为后期开发人员屏蔽用户不合理的、给项目实施带来技术风险的需求，是项目的技术框架的最初设计者。 售前人员要求具备一个技术人员和销售人员两方面的素质，具体如下熟悉自己的产品。 具有比较全面技术专业知识。 熟悉当前IT的技术发展方向。 对本公司的开发能力、技术优势、劣势有比较清楚的认识。 作为行业软件的销售，必须熟悉本行业的业务，对本行业的信息化的现状和发展方向有一定的认识，了解行业中的其它专业软件的基本情况。 熟悉本行业的技术和产品动向，了解同类产品及其竞争对手的情况和特点。 能熟练使用文本和图形器进行方案、标书的编写。 熟悉项目招投标的一般程序。 善于交流，有良好的沟通能力和技巧。 一个人通常不可能具备这么全面的知识和技能，因此，对于大型项目，为了与客户进行全方位的交流，展现公司实力，对系统进行初步的论证和设计，其售前往往是一个团队，这个团队根据项目的需求，可能有行业业务专家，数据库专家、操作系统专家、信息安全专家、网络构架师、软件系统分析员、项目管理专家等角色。 2.项目招投标活动的过程描述项目从前期跟踪，签单，作为售前人员，需要与销售人员密切合作。 通常获得一个项目的前期过程如下1.销售人员拜访用户，了解用户的项目基本情况，向用户介绍公司和公司的产品，与用户建立起良好的关系。 2.销售人员在用户招标前，引入售前技术支持人员，与用户进行技术上的交流和沟通，了解用户在项目上的需求，偏好的技术构架，引导用户到本公司的技术思路上，这个过程可能是需要多次反复。 至少要做到用户对公司有一定的兴趣，愿意邀请你参加投标。 3.用户发招标书，售前人员根据招标书的要求，结合前期与用户交流的情况，编写投标书。 4.参加招投标会，进行技术、商务上的讲解和答疑。 5.参加商务和技术的谈判，起草项目商务合同和技术协议书。 6.签订合同，项目实施以及维护。 2.1.招投标前与用户的接触招投标前与用户接触，了解用户的真实需求和想法，通过交流，了解用户对系统框架、平台、新技术的偏好，使以后在投标中能“投其所好”“命中要害”。 介绍公司的技术和产品，使用户在招标前对本公司技术和产品能有比较清楚的认识和了解，将用户的需求引导到本公司的技术和产品的思路上，使用户的在技术上对本公司有一定的偏好。 交流和需要了解的内容通常包括1.用户的组织机构，信息化的现状，现有的硬件设备、网络情况、正在使用的软件系统情况；2.新系统的规划、目标、规模，要求等，包括用户对系统的安全性、可靠性、易用性、扩展性的要求；3.业务内容、业务流程系统的现状，软件功能需求；4.平台和数据库的选型；5.信息安全、存储的需求；6.对软件开发机制的认识；7.用户感兴趣的热点技术；交流应该广泛，不要只限于项目的具体负责人，如果有条件，可以拜访更上级的用户，以及各部门的主要负责人或技术权威，尽量了解用户的对项目的认识和想法，交流和拜访中要善于识别用户的身份，抓住对项目有决定权、影响大的用户的想法，同时，可以初步分析哪些用户可能是以后的招标评委，留意他们对项目感兴趣的地方。 以便在投标和讲标中有所针对性。 引导用户向本公司的擅长的技术路线和产品特点上。 可以将以往做过项目的情况、功能特点讲给用户，最好是借助演示，这是用户会告诉你哪些是他感兴趣的，哪些是没有意思的，其它对手的产品是什么样的等等。 这样便于与用户进行深入的交流，找到与用户相互的共鸣点。 跟踪和了解对手情况，了解同类产品的现状，这是一个长期积累的过程，分析对手的产品和解决方案可能的特点，找到或提出比对手有新意的、能吸引用户的系统亮点。 当然，这些亮点的提出必须先考虑自己的技术实力和项目的投资规模。 2.2.投标及投标文件的准备2.2.1成立投标小组成立项目投标小组，投标小组的核心应该是项目的法人代表授权人。 根据项目的规模、技术难度和招标时间的要求，制订投标计划，将计划分解到每个人员上，确定每个人工作内容和计划，确定计划的执行的监督人员。 投标的时间一般都是确定的日期，而且比较短，这也是考验一个公司和团队的响应速度，必须在这个有限的时间内完成投标书的制作，否则，将由于准备不充分而丢标。 这需要平时的技术积累，对行业知识的积累，投标书的积累，如有类似的的标书或模版，以及良好的团队合作精神和氛围。 作为一个行业应用项目，技术部分可能涉及到的人员有网络规划师、硬件产品经理、软件构架师、行业专家、数据规划专家或数据库专家信息安全专家，以及其它专业领域的专家等。 这个团队建立，需要整合公司内部和外部的相关资源，来共同完成。 例如，可以临时请专业公司相关的售前支持（HP、IBM等）、相关行业的专家、相关专业的大学教授等来扮演相关的角色。 甚至可以考虑与相关的其它公司联合投标。 在投标小组中，建立保密制度，特别是对于特大型项目，关于报价、核心技术等内容，最好在小范围讨论和确定。 必要的情况下可采用封闭开发的方式。 2.2.2.编写投标书用户的招标书通常包括招标邀请函、商务要求部分、技术要求部分、附件和附图等文档，这些文档是编写投标书的基础。 投标小组成员在编写标书前，应该仔细、反复阅读招标书，特别是对投标商的资质要求等内容，投标小组对招标书进行讨论，找出招标书中描述不清楚的地方，根据情况向招标方提出要求解释，确定项目资质情况、投标以及实施的风险、对手情况、投标的优势、劣势等；制订投标策略；确定投标书的内容、投标方式；初步编写投标书的大纲。 在投标书编写过程中，应该注意一下几点1.商务投标书应该按照招标书的要求进行严格的应答，应答的顺序和格式最好严格遵循招标书的要求。 2.对于招标书没有要求的内容，特别是商务标书，最好不要画蛇添足，如果希望增加对项目投标有帮助的资质，最好经过慎重的考虑，确保没有漏洞。 商务部分主要的目的是展示投标公司的实力，确保参加投标的资格。 首要是确保投标有效。 注意有些东西可以讲出来，但不是所有可以讲出来的东西都适合写出来。 3.差异表的处理对于投标文件与招标文件中有差异的部分，通常招标方要求标注在差异表中，在编写投标方案时，应该尽可能的将差异部分找出来，描述清楚，但是，在最后、提交差异表时，就需要特别慎重，并不是每个差异都适合在这个正式的场所以正式的方式提出，有些东西需要保持一种模糊的状态，以提高中标的可能性，同时，又可以为商务和技术谈判留下伏笔，便于谈判中的进退。 4.对于报价单的处理报价单按照正规要求填写、盖章、密封后，最好能有一两套空白的备份，报价单的格式与正式报价单一样，但是价格不填写。 因为在正式报价单封装好到递交报价单前的这段时间，销售人员很可能探听到对手的价格或用户对项目整体价格的意见，这是候需要根据项目、市场、对手、用户的情况进行价格调整，这时就可以使用备份的报价单。 特别是公司到异地投标，要想重做报价单，时间基本上是不允许的。 5.密封条的处理在规定的投标文档密封条基础上，一定要多准备几张备用的密封条，当然是盖好章的，特别是公司到异地投标，市场信息千变万化，你不可能保证在投标前不修改你的价格和投标书。 6.商务投标书中的资质和要求公司盖章的部分一定要对照招标书的要求，严格检查，这部分的错误和遗漏将有可能造成废标，因此，最好有两个以上的人员专门检查核对。 7.对于一个集团公司下的多个法人公司之间，可能存在资质共享的情况，这时，应该注意检查哪些资质不是投标法人单位的资质，如果本投标法人单位的资质，应该请资质拥有的法人单位签署授权声明，否则，招标时可能造成“擅用第三方公司的资质欺骗招标单位”的后果而成为废标。 2.3.参加投标对于比较大的项目，参加投标的团队的人员合理分配是很重要的，根据项目具体情况，可将投标人员按照编写标书分工的情况分为商务人员、技术人员。 继续细分为商务联系人员、商务投标人员、技术部分可以分为负责网络部分的、体系结构的、应用系统功能的人员等。 参加投标人员应该统一服饰，穿统一的职业装，佩戴公司的标志，自信、自然，给招标评委一个良好的整体形象。 严格遵循招标纪律。 通常情况下，不要过多的对熟悉的评委交流。 尽管前期与用户有充分的接触，可能与一些评委熟悉并有良好的关系，但是，在招标的正式场所，通常是礼貌的打一下招呼，寒喧一下即可，不易与用户有太多的交流和亲密交谈，这些举动可能会造成其它评委的误会，也可能会给对手“授之以柄”。 除非你是专门的、有特殊目的的行为，例如，在有些情况下，与招标中的最好领导或核心人员表现出亲密的关系，可以给其它评委造成“某某人可能已经偏向某公司了，我也应该顺势而为”的误导，同时，给对手造成更大的心理压力和负担。 但这种方式有很多风险，要非常。 慎重。 在投标前，讲标的每一部分应该准备好相应的幻灯片，幻灯片的作用有两个，一是通过文字、图片、动画等多种方式，比较直观的向评委传达信息，便于评委对讲解内容的理解，二是通过幻灯片，帮助讲标人自己规范思路，不至于跑题。 因此，幻灯片制作，要以这两个作用为目标。 每张幻灯片讲些什么内容，讲多长时间，都要做到心中有数。 最好有实际的演示，结合演示讲标。 作为行业应用软件的用户，比较重视投标厂商以往同类系统的业绩，如果能向用户展示同类的应用系统，结合实例演示来讲解系统的体系结构、功能特点，通常会取得较好的效果。 但是，在展示以往系统的时候，要注意扬长避短，屏蔽掉一些系统的弱点和缺陷，同时要注意演示的时间控制。 对投标中使用的设备要主要保护，投标中使用的笔记本电脑，在安装好演示系统和幻灯片后，要对设备慎重使用，防止设备的意外损坏导致投标中的设备异常，例如，注意防病毒、防止意外碰坏，不要在投标出差期间用笔记本电脑到网吧上网，在宾馆中防止电脑进水、摔坏，不要轻易计算机系统的文件，可能因为不小心删除某文件造成系统不能正常启动。 最好在投标出差前将系统的安装盘，应用系统的安装盘等备份好，有条件的可以采用两套笔记本电脑安装。 适当的与参加投标的对手交谈，也许下次你们还会在另外一次投标中对阵，也许下次他与你并肩战斗，通过交谈，你也可以意外的获得一些有用的信息。 2.3.1.讲标讲标应该有既要有重点，又要覆盖到各项内容，突出公司特点和优势、突出技术优势和特点。 内容要尽量照顾到每个评委。 讲标通常都有时间限制的，在这个时间段内，如何将公司介绍、商务介绍、技术介绍、项目实施、技术支持与服务等内容的时间合理分配，需要在讲标前仔细斟酌。 时间和内容的分配主要根据以下情况来调整本公司和技术上的优势和特点。 讲标中，特别是讲标的顺序排在后面的时候，对于一些共性的东西，评委已经比较清楚了，也没有兴趣听你重复，他关心的是你与其它对手相比的特点招标评委的组成和特点。 要力所能及的分析招标评委的组成情况，高层领导、技术专家、部门业务专家等角色的人员组成和数量。 通常高层领导对IT技术不熟悉，他评判的主要依据更多的是公司规模、资质、实力、售后服务、价格等非技术性指标，技术专家评判的主要依据是系统体系、采用的新技术、安全性、扩展性、软件开发管理机制等技术指标，而部门业务专家更关心软件的功能、易用性、与现有系统的接口等问题。 讲标的过程中要注意观察评委的表情、态度，及时调整内容的深度。 对手讲标后的情况和弱点。 针对对手讲标后评委普遍反映的问题进行重点阐述，例如，评委认为系统的安全性和项目开发的规范性很重要，但其它讲过标的对手都没重视，这时，你需要及时调整内容，将安全性和项目开发机制做重点来阐述。 另外，不要轻易攻击对手，可能有些评委对你的对手有好感，你对对手的直接攻击，会引起他的反感而刻意打压你。 攻击对手的方法是突出自己的优势。 讲标中可能由几个人分工，讲不同的内容，但要注意整体的逻辑上要严密。 可以先由一个人将讲标的全部内容安排做一个介绍，然后在每个人讲完自己部分后，简单介绍下部分的内容，引入下个讲解人员。 使整个讲标连贯统一。 讲标前要调整好自己的状态和心态，讲标过程中要放松，不要报着“上考场应考”、“被人评判审核”这样的心态，这样会使你陷入一种紧张、诚惶诚恐的状态。 当你上到讲标台上，看见评标的人很多，你会更加紧张，越容易出错。 你应该对自己方案和产品充满信心，你就是专家，报着“咳！让我给大家介绍一下我们的好东西，绝对能解决你们现在的问题！”的心态，你应该有一种急于向外人展现你的得意作品的冲动，人越多，你越得意、越兴奋，这时，你最好的状态来了！2.3.2.答疑回答讲标和提问时，掌握的原则是讲不清楚没关系（模临两可），但决不能错！不能与评委发生争论。 不能对评委的问题表示轻视。 回答不了的问题的答疑的人员要相互配合。 当你发现你的同伴被问住的时候，如果你能协助他回答最好，你也不能回答的，你应该迅速想到一个方法，从另外一个角度的回答这个问题，从而逐渐将话题引开，避免尴尬。 2.4.商务和技术谈判在预中标后，将会进行商务和技术谈判，售前技术支持人员主要参加技术协议的谈判和起草。 技术协议的谈判是降低项目风险的关键过程，谈判的成果技术协议书通常会作为合同的附件，直接影响到项目实施的难度和风险。 因此，一定要耐心、细致，不能为了尽快签合同，就草草了事。 技术协议目的是界定好功能边界和深度。 特别是在行业应用软件中，投标文件和讲标中，通常会有忽略一个“度”。 如应用系统的深度、功能的具体边界、新技术采用的程度等问题，往往是比较模糊的，很大的可能性是双方在这些方面的认识存在着较大的差异，这些差异的会给后续的项目实施带来风险。 技术协议的谈判就是要对这些“度”进行控制，对敏感问题和技术难点要进行沟通，达成共识，注意不能在技术协议中出现“全面解决某某问题”、“完全解决”等模糊的字眼，这种模糊的界定会给项目开发带来很大的风险，都必须讨论清楚，将完成的深度和采用的技术手段写入技术协议中，使项目风险在项目实施前就得到充分的展示和控制。 3.投标文件的编写投标书的编写最核心的要点是要逐条响应招标书，不能有遗漏。 作为一个大的公司或集团，需要也应该制定统一的投标标书编写规范与指南，通过积累，建立一个投标书模版库，以保证投标书的质量、缩短投标书的编写周期。 关于投标的文件的具体编写，有许多文章都有较好的描述。 在此不再赘述。 如何做好售前售前，是一种对销售阶段的工作的统称，不是指固定的岗位。 那种将售前理解成为由专门的人员来完成的想法是不正确的。 任何的销售过程，其实都是分为售前、售后两个阶段，是以合同签订做为两个阶段的划分标志的。 产品由于其技术含量的不同以及标准化的程度，参与售前的人员会有多有少。 标准化的产品，销售人员既承担技术职责又承担商务职责；非标准化的的产品可能会由不同的人员来完成，以知识做为最终产品的软科学的销售过程对参与人员的知识要求更高。 在合同签订以前，所有参与者，为了达到签单的目的，所做的工作统统称为售前。 为了区分不同的人员在该阶段所做工作的范围和职责，不同的行业设置了不同的岗位和职责。 例如，在IT行业，一般有销售、客户经理负责销售机会的把握和客户关系的联络；由技术支持，咨询顾问，售前工程师，产品经理等做技术方案的选型，由市场推广人员提升品牌价值、提升市场知名度等的工作等。 会有不同的人员参与的售前的过程中来，不同的岗位，完成不同的工作，但是大家的目标是一致的。 同样的，售后是指合同的执行、交付以及服务过程，也是由不同的岗位参与完成的。 签单是售前工作的最终目标。 管理软件由于具有很高的知识含量，因此，其销售过程更需要是不同的人员合作完成，团队合作因而显得尤为重要，特别是必须建立一种团队售前的方法论。 那么，如何统一不同的人员的工作方法？必须把握这么几个原则l必须要有“引导”客户的意识；l必须要从如何体现客户价值来进行软件讲解；l必须要体现出“咨询”的价值。 如何引导客户如果能够成功的引导客户对项目的成功是非常重要的。 引导客户一般有这么几种做法一是如果客户处在选型阶段，对产品并没有非常明确的倾向性。 这时候要尽量了解客户最关心的问题和客户打算希望了解那些友商的产品。 掌握了客户最关心的问题，也大概知道了后面可能碰到的竞争对手，这时候我们可以在软件演示和讲解中，侧重于如何很好的处理客户最关心的问题，并不动声色的横向比较一下和友商的区别。 当然，孩子是自家的亲，我们的目的就是要让客户的头脑中体现出“这家的产品很不错，很有特点。 如果选择友商，会存在一些问题”当然，做到这一点，需要我们对自己的产品要非常了解，对其他友商的产品也要尽可能的了解。 同时，一定要注意，只有你能确定某个产品的功能和我们的区别，你才可以说出他们的名字。 否则，不确定的事情就不要指名道姓的说，要提防万一以后客户看了这家产品，发现你说的和事实有出入，可能会影响客户对你的印象。 二是如果客户选型已经很长的时间了，并且有倾向性的意见。 这时候的引导就要多费些力气，尽量采用这样的语气是，你说的很正确，能这样处理业务的系统确实很好，比起那种只能的系统，这样做要好的多，不过，好像还有另外一种处理方式，这样比刚才那种处理方式的优点在于。 总之，这时候的目的是先让客户的立场产生动摇，这样才可能有机会产生奇迹。 如何最好软件演示做好软件讲解，也是非常具有挑战性的。 笔者在近几年的软件讲解中，也有不少的感悟。 如果客户是技术人员，他比较关心的是你实现功能的方式。 就像我们技术人员看一些软件，首先关心的是这个软件采用了一个第三方组件做报表，挺好的；这个软件的架构挺有优势的等等。 对这样的客户，那就要解释技术优势。 但如果是管理人员，他关心的是我的业务，你是怎么实现的？你们这样做，有什么好处？等等。 这个时候，就要尽可能用他们听到懂得语言，不要讲有什么功能，而是要描述业务如何处理，这样做的好处是什么。 在软件演示的时候，一定要注意不要急着开始。 而是要先和对方聊聊，倾听对方的兴趣点，这个时候，你就可以说我们是这样做的.。 这个问题演示完了，要先停下，继续和客户交流，发现问题，再演示，如此循环。 这样做的效果要比从头到尾，从A功能到B功能的演示方式好的多。 如何体现咨询的价值在售前的过程中，最重要的是要让客户信任你，对你有信赖感。 要做到这一点，就必须站在客户的角度，去帮着客户解决问题，要能体现出咨询的“价值”。 什么是咨询？什么是咨询顾问？我个人觉得这并神秘，并不是只有麦肯锡那样的才能做咨询和咨询顾问。 日常生活中，只要存在我们不熟悉的领域，我们问对方，都是咨询，都存在着咨询顾问。 例如我们想买房，我们去已经买过房子的朋友那里了解情况，这就是咨询，朋友就是咨询顾问；我们想买个数码照相机，到处考察，了解情况，这就是咨询，就存在咨询顾问；应聘人员打电话到公司，询问公司的地址，做什么车可以到，这也是咨询。 所以，咨询无处不在，人人都是咨询顾问。 在企业的商业行为中，只要是和客户打交道的人，都是顾问，因为客户有从你身上了解你所代表的公司、所代表的产品的信息的需求和行为，所以，这时候你就是顾问。 那么，如何体现顾问的价值呢？实际上，你在和客户交往的过程中，已经无时无刻不在解答客户的“咨询”，但是可能客户和你都没有意识到。 为什么呢？因为回答问题的方式不对！一般人在和客户的交往中，往往是先听完客户的问题，接着就开始滔滔不绝的讲我们怎么怎么样，同时阐明我们的观点，但是这种方式并不是最好的，因为客户往往不喜欢你把自己的观点强加给他。 所以，改变交流的方式，将一问一答式的方式改为“探讨”的方式。 这样，不是你在回答客户的问题，而是在和客户商讨解决问题的方法，慢慢的将自己的观点通过一种柔性的方式展现出来。 “润物细无声”，才能达到活跃讨论气氛、引发共鸣的。 其次，在和客户交流的过程中，要体现出“咨询”的价值，还要在交流的过程中，做到对客户的业务的理解和尊重，同时结合以前项目中的经验、教训，真诚的给客户一些建议，帮助客户规避一些风险。 最后，最重要的是，要能针对客户的提议，提出一些有益的建议。 如果客户的需求没有超出你的预期，可以针对这个需求，提出一些如何更好的实现的建议；如果客户提出了超出你预期的需求，可以委婉的和客户一起分析这样做存在的问题。 总之，软件销售过程中，对售前团队成员的培训和管理就显得尤为重要。 客户在与软件公司不同人员的接触过程中，会逐渐形成对软件公司的一种具象的认识，而这些认识是好是坏，与每个售前参与者都有直接的关系。 而这些认识很可能与客户经理和售前技术支持所要展现的公司形象是交叉的，即客户可能通过客户经理来认识软件公司的技术水平和产品，又可能通过技术支持工程师来认识软件公司的服务。 所以，做好售前工作，需要每个参与售前的人员都有相同的工作原则和方法。 这样通过不同层次人员和客户的交流、沟通，会逐渐加深客户对公司的信心如何写售前解决方案业务解决方案成为功能列表解决方案图快、图省事的另一种常见编写方法，就是将产品功能描述作为技术方案内容进行罗列，或者参照软件功能手册进行罗列，这种解决方案不是按照客户业务去准备的，对客户而言没有实质的意义。 如果解决方案中业务思路部分写得清晰简明，倒是可以把功能列表作为解决方案附件，或者在解决方案中提供一份软件全功能列表给用户参考。 口语书面语混杂，遣词造句不严谨有的人写方案时顺着思路走，口语化成分很多。 方案是代表公司正式对外的文档，行文一定不要出现口语和书面语混杂的情况。 有的人写方案比较喜欢表现自己对客户问题认识的深度，喜欢指出客户的不足，而且采用激烈的语言。 例如出现“企业缺少管理”、“业务失控”、“后果很严重”之类词语，这些内容很容易让用户反感。 方案用语不要追求“语不惊人誓不休”，而要注重理性分析，认真推导，句句讲逻辑。 确实需要用一些事实说明客户的问题，不要用刺激性强的语言。 例如说客户业务存在问题，可以说业务有可改进的地方；说企业管理失控，可以说管理上存在难以受控的环节。 这样的表达客户比较容易接受，不容易出问题。 有些客户内部关系比较复杂，一些提法，特别是一些有新意的提法可能对某些人比较敏感，在方案中可以中性化表达，是否合适要仔细斟酌，并询问电子商务人员的意见。 没有认真检查，存在大量硬伤很多解决方案的制作过程往往是找一个同类方案，然后通过“Ctrl+C”+“Ctrl+V”制作成一个新的方案。 利用范本复制的方案如果不经过仔细的核对，往往容易出现如下几种错误第一，替换不完整，在方案中出现了其他客户的名称。 第二，替换过度，把一些典型案例中典型客户名称也替换成为本方案客户名称，闹出笑话。 第三，只注意正文的文字替换，不注意插人图片文字中客户名称或其他内容的替换。 第四，只注意正文替换，忽视页眉页脚的替换，特别是在首页或目录和正文不同的情况下。 第五，目录不对，忘记刷新，出现页码或者标题名称错误。 第六，案例不对，没有查找本行业案例，案例全部都是其他行业的。 第七，联系方式不对，给不同地区的方案要注意更正服务机构联系方式。 第八，文件电子属性没有更改，导致在资源管理器中浏览时显示其他客户的方案名称。 第九，存在大量技术硬伤，堆砌非本行业的专用词汇和概念，和正文内容无关。 过于突出自我很多人写方案大量出现“*软件公司”字样，甚至每个产品都恨不得加上自家标识，行文造句都是“我能”、“我行”、“我有”等语气。 这种方案很容易给客户过度营销的感觉。 给客户写售前方案时，建议尽量用客户作前缀，例如说某企业PDM项目，给客户一种相对的针对性，感觉这个方案的确是为客户准备的。 在售后实施方案中软件公司的名字只需要出现一次，后面就尽量不要反复出现，我们更应该让客户把注意力集中到产品支撑业务的能力上。 没有体现公司产品最新进展很多时候解决方案的编制者都是一抄再抄几年前的模板，没有反映产品功能最新进步，自然缺少竞争力和说服力。 提交解决方案往往离正式实施需要半年甚至更长的周期，不充分利用公司最新产品进展，就好比有大马力的法拉利赛车，但偏要拿奥迪去比速度。 因此写解决方案一定要根据公司最新产品功能，认真组合实现企业业务流，甚至可以考虑利用未来半年内会发布的产品功能认真组合客户业务解决思路。 所以咨询顾问还要随时收集、学习软件规划，以推动解决方案的技术水准不断完善和提高。 文字太多，图表很少凑解决方案的字数不难，难在让客户把这些文字都看完。 文字陈列太多，方案可读性就会降低。 软件解决方案中文字的概念比较多，理解难度比较大，因此要想办法设计一些简明清晰的图表，把写Word方案当作PPT一样来书写，减少文字的比例，把大段的解释变成图表式直观表达。 从没看过软件方案的人，判断某个方案写得好坏关键是看方案图表质量。 售前解决方案中应该多用一些描述理念和逻辑的框图，少用OA软件界面图。 有的方案图表不少，但一看就是不同文章风格的拼凑之作，应该把所有图表风格统一成一种。 没有评审方案提交给客户之前，一定要经过内部评审。 没有个性化定制内容的方案，一般经过自评和互评即可。 自评时，要重新审视整个方案的结构、问题描述、遣词造句等方面，特别要注意关注替换修改的企业名称和产品名称等方面的内容，尽量减少低级错误。 自己评审过的方案一定要给其他人评审，帮助发现一些自己行文习惯下难以发现的问题。 对于有个性化定制内容的方案，要经过公司的评审。 提交给公司评审的方案，一定是已经过自评和互评的方案，而且要注明主要看哪些部分，以及编写这些部分的业务知识，便于加快评审速度。 售前如何写解决方案分析售前如何写解决方案解决方案难写在哪里很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。 作为一个公认的方案打手，意思是写方案就象打字员一样，我觉得我在这方面确实是有绝活。 我基本上都是在方案提交前一两天接到写方案的任务，而我自己的事情一般又比别人多一点，也不能不做，只好心里大骂一句，骂完后就打电话搞清楚别人的要求，边问就边构思整个方案的推导思路和结构提纲。 因为你不敢让你的同事知道你只能用很少的一点时间写方案(基本上我真正动笔写方案的时间都在个小时以内，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。 所以我其实也特别紧张，注意力也特别集中，大脑也高速反应，基本上几分钟电话或面谈完思路基本就有了，然后该干嘛干嘛，找一些零散的小时间把思路不断推导一下，然后到了一个比较安静和完整的时间段前才开始写，这个时候基本上要写的话都想清楚了，只需要不断敲字，敲字的时候也是注意力也特别集中，大脑也高速反应，越写思路越开，很快也就完工了。 写方案不难，知道怎么写才难。 关于写方案我只总结一点，结构化地去组织你的思想。 有结构就有思路，有思路就有方案。 另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。 当然我曾经问过很多人，你到底为什么写不出好的方案呢？基本上原因可以归为四类第一种是没有体系一旦用户要求提供关于的方案，很多人大脑是一片空白，完全不知道从哪里下手。 很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。 这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。 因为我们这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。 所以一下子去驾驭一个整体方案是很痛苦的。 只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。 所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。 第二种是没有思路有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就速手无策了。 这种情况从根本上讲还是写方案者不熟悉企业业务造成的，写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。 所以一个人要写好方案，还需要了解下游客户的业务，了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户关注重难点问题，自然可以比较好的确定方案的个性化内容思路。 解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。 第三种是没有素材一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。 很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。 这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。 所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。 第四种是没有层次很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。 结果拍胸脯容易，写方案难，自己写不出来只好求公司，公司没有安排专人了解情况，只好按模板制作一个，用户一看几个供应商内容都差不多，觉得不好，又总结出一些个性化要求，于是大家有开始折腾第二轮方案。 其实方案编制在不同阶段有不同策略，不要轻易提供方案。 刚开始接触是可以提供项目合作建议书，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。 过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。 想急就又能解决问题的事情，本来就是一般人做不来的。 方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。 如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。 写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。 容易犯错误只有论点，没有论证不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。 不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。 我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。 如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。 写方案是一种技巧性工作，有个金字塔式的写做原理，也就是说文章一定是有结构的。 所以真正好的方案，不一定厚，但能看出你用心，你认真。 现在的解决方案一个不好的倾向是长、厚、全，看起来面面俱到，其实对决策者没有帮助。 所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。 结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。 其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。 通观这个方案并没有研究为什么企业会产生这么多问题？问题是这些问题是什么产生的？为什么出这么多问题？而是不断说我能！我能！选我，选我！如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。 这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难不好的解决方案最大的问题就象写一篇议论文，能够发现问题(这个也是模板化的，可惜中国企业大部分没有意识到自己很多问题并不少见，总以为自己是特殊的一类企业，提出答案(搞信息化，但没有论证(为什么搞信息化和企业管理进步有联系呢？。 没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。 看到方案时候，其实很多用户下不决心，他会感觉每家都差不多。 如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。 但对内容认可程度并不高，实际上没看懂。 业务解决方案成为功能列表解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。 大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。 而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是销售人员，还缺少(顾问式销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案售