目录
一、需求识别
通用型需求识别可以大致分为政策驱动、业务驱动、风险驱动三类。
1.1政策驱动
政策驱动的核心要选对行业，简单来说是要选择有监管部门、主管部门的行业，通过解读监管部门、主管部门下发的政策性文件识别可能存在的业务需求，垂直性越强的行业识别到的业务需求就越明确，这种情况在金融、电力等行业较为突出，其他行业如细分政府、医疗、教育等也比较通用。
政策需要我们持续关注监管部门、主管部门的动态，主动参与试点试行单位的规划。如果行业有持续投入的话，配合监管部门、主管部门写材料就更舒服了。
大政策驱动（等保、关保等）过于通用，落地起来不如行业型政策舒服，而且存在明显的行业特色，所以建议关注监管部门、主管部门对大政策的解读、落地，不要上来就轮大政策的“三板斧”。
1.2业务驱动
业务驱动分为两类，包括政策型业务驱动、场景型业务驱动。
1.2.1政策型驱动
政策型业务驱动不管是新建还是改造，都是基于监管部门、主管部门下发的业务要求来落地，通过业务要求中对于安全部分的描述进行细化、解读，进而发现可靠商机。政策型业务驱动主要是依赖政府的发文，需要有高度的敏感性，安全都是藏在业务文件里面的，不具备一定的敏感性可能就与需求擦肩而过。
政策型驱动有两类场景，细分政府要求建设细分业务，比如早一点的应急、市场监督管理局等政府机构改革，比如林长制、河湖长制、国土一张图等委办局的业务创新；细分政府要求的外部单位建设新业务，比如应急的危化品及非煤矿山科室、环保的污染源监测等，比如医保要求的互联网医院等。前者应该关注业务是否上云、是否要求安全，后者应该关注是否需要预算哪里来、安全要求有没有、上级要不要查安全。
1.2.2场景型业务驱动
场景型业务驱动需要考虑两个维度，行业属性明不明确、场景需求强不强烈，行业属性强烈意味着有复制的基础，场景需求强烈意味着可以批量复制值得大量投入，实际操作过程中二者有其一这活就能干，两个维度都具备了就能投入大量人来干。
比如跨国公司的CDN加速业务、多分支用户的SD-WAN组网等，实际操作过程中行业属性识别比场景需求总结更为重要一点，因为行业属性可以直接框定目标用户，场景需求多少会存在差异化。
1.3风险驱动
风险驱动相对比较明确，通过总结、沉淀公司整体型解决方案、单产品功能特色，整理形成风险应对的核心措施，基本就可以完成一定的市场需求的沉淀，比如最近肆虐的勒索病毒、托管安全服务等。如果风险驱动想要批量复制，最终还是要识别到具体的行业，整理出具体行业的特点，点对点输出。对于市场一线来说的话，所有人都可以卖=无人可卖，所以最后还是要总结行业的打法沉淀，让一线有的放矢。
还有一部分需求不好定义但是又极具特色的，集团型需求、圈子型需求（XX行业协会、行业组织）等，集团型需求依赖集团的资金拨付情况、集团领导的重视情况、分布领导的业务需求，圈子型需求高度依赖组织者及参与者的关系、组织者圈子内的影响力、参与者自身的业务情况。实际操作过程中要优先关注集团公司的要求，这些要求高度对内，只有持续接近客户的人才能拿到。
最后，需求识别不一定完全依赖运营对政策要求、业务文件的第一时间的发现、解读，一线的商机反馈也能总结出通用需求，前提是项目名称准确、运营高度敏感。
二、需求验证
需求识别做得好不好跟需求验证的关联度不大，但是需求识别完能不能实现价值就全靠需求验证（趟雷）这一步了。
2.1需求验证一定是有准备的
找到销售的时候，一定不是画大饼，一定是告诉销售客户在哪里、客户要做什么、客户为什么要这么多、客户什么时候要做完，有能力的还要告诉销售集成商在哪里、设计院在哪里、总包方在哪里，能力富裕的还要告诉销售运营能做什么、已经做了什么、还能做什么。
找到售前的时候，一定不是全靠你了，一定要协助售前整理交流材料、编写汇报材料、输出总结材料，一定要协助售前准备产品测试、协调高层资源、做好项目交付、申请项目奖励。
当然了，毕竟前期的时候运营本身也不一定会了解这么多，但还是要多参与、多考虑、多验证、多动手，没有实践也就没有后面的有效运营。
2.2需求验证一定是有目的的
在开展需求验证的过程中一定要带着目的去验证，可以是梳理整个项目的流程及关键节点、梳理不同角色在项目流程里面的话语权，也可以是验证需求的落地程度、验证材料的可靠程度，更是总结形成弹药库的最好时机，通过少数项目形成多数项目的弹药库。
2.3需求验证一定是有结论的
需求验证完成后一定要有结论的，一是对需求验证的过程材料进行总结，二是对自己需求识别的过程进行复盘，不管成与不成都是一次成长。只要行业属性明确，基本上都能成。
2.4需求验证不是打攻坚战
需求验证的目的是为了确认需求是否通用、是否与政策要求一致、是否与业务规划一致、是否与风险处置目标一致。
需求验证的目的是为了摸清需求落地的一般路径、总结形成通用打法、整理输出一般销售话术、逐步形成体系化弹药库。
需求验证不是打攻坚战，越是难打的仗敌情就越复杂，一是不容易验证需求、产生结果，辛辛苦苦总结的需求可能因为单个头部客户无法产生有效结果而胎死腹中；而是攻坚战达成路径较多、调动资源较多，不具备通用性，无法形成一般项目操作思路，影响批量复制的效果。
2.5需求验证=我干我也行
有条件的需求验证一定是一场富裕仗，可以适当的点到为止。拉通内部资源，找到行业内有一定客户资源的销售，传递需求详情、制定覆盖计划，运营跟着售前一起打仗，整理客户、集成商、设计院、总包方等各个角色对我们定义的需求的不同的反应，找到整个链条内部的所有人的关注点。
如果项目落地困难，可以选择点到为止，这场仗我不一定要打，我只是想让大家看到这条路是行的通的，我干我也行。
三、需求运营
- 最终目的：提升产品/行业的产出
- 核心方法：缩短销售学习路径，降低售前学习成本
- 重要手段：进行合理的过程检视、结果复盘、氛围营造
3.1缩短销售学习路径
我认为这是运营很重要的一个环节，通过提炼产品功能、梳理销售场景、总结销售话术、提供回复思路来缩短销售学习路径，让销售在短时间内能够了解到客户的基本情况，判断客户更适合哪类销售场景，有针对性的向客户提供解决方案、解答客户疑问。这样可以提升销售的商机获取效率，效率高销售就更愿意去执行。
注：但是，大型客户不适用于这样开展工作，中大型客户需求标准化产品不一定能满足，需要更好的去理解客户业务、需求，基于业务、需求进行拓展。
3.2降低售前学习成本
这一步应该有两个思路，一个是降低售前获取资料的时间成本，另一个是扩展售前的学习深度与广度。应该为售前准备好售前工具包，包括但不限于客户业务流程学习材料、场景化解决方案、解决方案小故事、渠道/销售培训材料、友商相关的材料。通过客户业务学习材料、友商材料也可以有限的增加售前的学习广度，深度的话就需要对材料质量提出更高的要求了。
3.3进行合理的过程检视、结果复盘、氛围营造、样板点营销
运营最重要的应该是过程检视，通过过程检视可以了解现在的推进过程，做好下一步工作的安排；也可以去维护、更新销售工具，提高工具的可用性；也可以去了解覆盖过程中产生的新商机；也可以作为需求更多资源支持的基础。
结果复盘同样重要，通过成功项目的分享，将运营缺失的销售故事能力进行补充，进一步梳理客户决策链条；通过失败项目的分享，去了解销售工具的缺陷，进一步完善销售工具。
氛围营造也是很重要的一环，让大家感觉这个项目你不做马上就有别人做，这个项目别人做着简单，你做起来也很简单。
充分利用样板点标杆效应，做好区域的沙龙、参观等活动。
人都喜欢做简单的事情，运营应该就是把产品销售、方案销售简化的那个人。
1863
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
