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