|
解决方案我们每天都在写 但真正 走 我们心里的小算盘是 ↓ 反正客户也不认真看 我又何必认真写 …… 如果你因为这样的过往“经验” 就疏于对解决方案的精雕细琢 那就只能沦为平庸的“文档管理员” 我们看到的大趋势是 ↓ 「鸡肋方案」的旧黄历要翻篇了 如今 客户越来越关注业务价值、重视IT赋能 「有颜有肉的方案」成了取胜的第一步
如果真到了“拼方案”的阶段 ↓ 哪些内容，才是客户眼中的干货？ 我们用当下大热的 私有云产品 来举个例子 假如我是私有云厂商 有料的技术方案，应该怎么写 ▼ 我们先来说说 哪些内容，在客户眼里，不是干货 ↓ × 公司简介，在方案中占用大篇幅 恨不得把公司前世今生都扯清楚 公司简介，更适合销售面对面交流 即便是“陌拜”，一份公司简介印刷品足以 所以，这部分段落 附在方案的最后就好 × 在方案里给客户做基础知识扫盲 这就是找错对象了 拿超融合来说，这几年市场教育充分 绝大多数客户，都不是小白了 这里，选择“me too”即可 不要浪费篇幅 × 如果不在方案里描述一下背景信息 似乎就无法体现方案是为客户定制的 于是我们往往喜欢 从客户网站、百度百科摘抄一些段落 并把这部分放在方案的一开篇 其实，你会比客户更懂自个儿吗 何况，你摘抄的内容，可能已经过时了 so，针对这三大类“非干货” 建议一切从简 接下来，我们再说说 客户眼里的干货是啥 ↓ 客户眼中的干货 你介绍的方案 是否跟客户业务场景相吻合？ 虽然现在私有云建设已经普及 但在不同场景，差异性很明显 ❶ 关键业务场景 打消客户顾虑的，是“干货” 很多企业级客户 想把一些重载应用（比如ERP、HIS） 从传统IT架构迁移到“私有云”上 但又顾虑重重 ↓ 他们能理解云和虚拟化的好处 (易维护丨不锁定丨可扩展) 但又担心这是小马拉大车，扛不住 （毕竟传统架构用了那么多年，踏实） 所以 此时你需要打消客户担忧 从性能和可靠性入手 此时，拿出「实测数据」和「案例」 比任何技术名词和概念都有说服力 比如，来个跑Oracle 数据库的实测数据 ↓ …… 接下来可以再附上一点技术说明 为啥你家能把性能做得这么吊 其实，大部分客户不在乎你怎么做到的 只在乎你能做到什么程度 ❷ 云平台场景 能给客户实锤的，是“干货” 很多企业客户 希望构建内部私有云服务 把IT基础资源池化，按需交付 甚至还会有计费、自助服务的要求 ↓ 在这种场景 更关心「扩展能力」、「平台功能」 需要有明确的容量指标、扩展性指标 同时，平台的功能也要有实锤 这部分，不能光列功能描述 最好配上截图或者SDK附件 甚至，提供demo地址 ❸ 容灾备份场景 切中客户要害的，是“干货” 容灾备份，算不上核心业务 但却是不可忽视的需求，要知道 凡是考虑了容灾备份的客户 都不是一般的客户 对于容灾场景，不管架构如何设计 离不开两个指标：RTO和RPO 价值阐述，需要围绕这两个指标 （在客户预算允许的前提下 让RPO和RTO无限趋近于零） 总之，不同的场景，对应不同的痛点 对症下药，你的方案才有料 客户眼中的干货 成功案例，是最好的背书 在方案中引用成功案例 主要分为两类 ①同行业案例 ②灯塔式标杆案例 前者给客户以很大的参考价值
后者则对品牌形象有很大的拉升
不要迷信公司印刷精美的案例集 印刷品通常时效性不强、言之无物 精选几个案例放到方案里，很有必要 客户眼中的干货 每一个项目，都是多家品牌竞争 你会洗脑，友商也会 在技术层面，客户更希望看到差异性 （你到底比别人好在哪儿） 对比分为两大类 ①可以直接落到方案文字里的 （通常比较温和，多为强调自身优势）
②与客户交流方案时，口头介绍 （通常比较激进，直击对手要害）
要强化自己的优势 狠怼友商的劣势 客户眼中的干货 我们在方案中列了那么多干货 但是客户有时太忙，来不及看 怎么破？ 这时候，你需要准备一份索引 俗称 一纸禅
↓ 把你方案里的“干货” 浓缩到一页纸上 把它放到整个方案的“扉页” 让客户一目十行也能get到精髓 按图索骥还可以找到细节
上面只是通用套路 面对不同的客户对象 我们往往需要准备不同的材料 ↓
不同属性的客户 他们眼里的干货，也是不同的 让经济决策者、一把手觉得 物超所值，组织使命的助推器，行业龙头的首选 让技术决策者、技术主管觉得 满足业务价值、符合技术趋势、成熟稳定有安全感
让使用决策者、一线工程师觉得 简单易用好维护，活好钱多下班早 …… 这样的方案，就是好方案
|
|
|
来自： happyday4978 > 《待分类》
心 
