云客户需求引导管理--实战型IT太极拳

前言

 

多年之前，我要搜集云平台技术运营数据，就主动了解客户云平台的运行状况。然后我就发现来到了暴怒战场，客户的需求同事们都承诺下来了，但一年半载都没人做。我闲不住就开始救火，客户有十个要求我会拒绝七个，两个慢慢做，一个承诺立刻解决。客户并没有投诉我，倒是离职的时候多个客户邀请面谈并发出了Offer。

 

这几年我一直把“客户提十个需求我会拒掉七个”当做招牌技能，今天就聊聊客户需求为什么要引导，该如何引导。

 

云平台卖的都是服务，靠销售体系打下单子来只是万里长征第一步。如果云厂商做不好服务，公有云没有消费额，私有云可以换别人家的软件授权；如果云厂商做好大客户的技术服务服务，完全可以从备胎公有云变为主力公有云，私有云群集也月月有扩容。各位投标中标的CDN厂商已经领教过客户的切量神功了，而云主机等资源的切换也会越来越简单方便。

 

过去的案例

 

我们先看四个生产环境案例。

 

案例1.有外售型私有云客户要把虚拟机的内网带宽从1G扩充到4G，沟通后发现是最终用户要在单虚拟机上跑大流量应用。我就劝客户技术工程师，网卡改QoS不难，但宿主机网卡才10G，你们是愿意一台物理机只跑两台虚拟机，还是愿意停机扩容物理网卡。客户技术工程师认同让最终用户学采用LB加多台虚拟机，比改QoS和停机加网卡更可靠。但最终用户宁愿纠缠客户技术人员也懒得学如何用LB，我给支招说我们的操作人日免费送，但硬件改造成本有20万，问这用户只是想试试还是改完网卡就能付费。最后该用户果然只是想试试，我们和客户技术部门都躲过一场折腾。

 

案例2.有个IDC新上线一套外售型私有云，运营负责人第一次操盘公有云心里痒痒，总是提需求但总被我拒绝。他想开放注册并给新用户大量赠额，而我跟他聊运营数据，让他同意赠送小用户并不能带来多大收益。他说在主机和网络性能测试没友商好，我跟他说明权威测试方法和意义，让他相信友商性能比他好就是作弊或者烧钱。他想不同客户不同产品给不同折扣，我们研发人员半年内没这个排期；我们已经有充分的信任，我就直接告诉他我做不过来，给用户充值后赠送同样可以达到折扣效果；给云资源做独立折扣我们要收开发费用，而且这不是强需求。（这些运营问题都是2015年的，可能略有老化）

 

案例3.客户被同集团的云计算子公司服务的欲哭无泪，找我们接盘时提了一大堆需求，我同样是拒的比接的多。客户问能利旧设备么，我认为利旧设备的配置都太高啦，还不如租我们的廉价服务器。客户要我们按照旧接口去定制开发，我指出用我们的SDK对接只有半个人日，而旧接口连文档都没有只能猜。客户要我们派几个高工长期驻场，我说明所有故障都可控且已演练，远程排障我们有10个高工主程，但长期驻场我们高工得抑郁离职了。客户担心日常无事可做了，我们就帮客户做了月度巡检流程，但整个流程我们全程不参与，他们巡检成功就是双保险，忘了巡检也有我们的监控兜底。

 

案例4.有公有云客户说要买最便宜的带宽，但最终沟通发现对方是要做非核心日志上传。云平台默认的计费规则是上行带宽免费，但免费不限流的上行带宽不承诺SLA。最终结果是建议客户短期内买几十台低配云主机，同时做好客户端容错，长期看建议这些日志直接上传至对象存储，还能配合我方大数据服务做MR。

 

案例解析

 

云计算主要服务企业客户，企业客户内部分为采购、技术、业务、管理等多个角色，在本案例中服务的技术和运营团队是非常讲道理的。通过上面四个案例，我们可以看到客户需要云厂商提供“问题分析能力”“承担责任的能力”“协助内部沟通的能力”“推进业务的能力”。

 

1.问题分析能力

 

我们要倾听客户但不能照搬客户要求，客户没我们懂云计算，拿着客户的话当金口玉言，却不深究背后原因，这个云平台就是不够专业。

 

客户技术团队的需求被合理的拒绝和引导，对于懂行的客户技术，是借着外来的和尚帮自己念经，对于不懂云计算的客户，我们像明灯一样避免他们采坑了。

 

如果客户技术团队随口建议就被云供应商拿去简单照做，在客户看这个供应商很蠢，自己拍大腿都能想到的事情，云厂商却拍屁股都搞不定。

 

2.承担责任的能力

 

客户技术团队找云供应商要方案，就是要规避自己的选型责任，云厂商最值钱的就是承担下这个责任，搞IT咨询的含金量远大于超卖CPU。客户对自己的很多提议也并没太大信心，所以被我们拒了也不会伤心生气，专业供应商都表态某事做不了，客户内部也就不再异想天开了。

 

倒是云厂商某些从业人员对内滑头滑出经验了，当他们遇到来自客户和售前的需求时，照本宣科照方抓药，是腹黑的把选型责任甩出去了；医生按照护士和病人的建议来开药，治不好病也不负责任，这种小伎俩能瞒得住谁哪？

 

3.协助内部沟通的能力

 

我给很多客户都写过正式公函邮件，既是在公函表态承担责任，又是帮客户技术和运营团队制作对内交代的工具。

 

我们帮客户技术和运营团队解决难题，他们难题解决后会促进我方的消费。其他客户内部部门会挤兑欺压这两个部门，而已经入围的云供应商不会太介意这些部门的态度。

 

我举个偏点的例子，一个造纸厂的IT说，虽然开源社区的邮箱方案简单又免费，但他还是会买商业邮箱。他自己搭出来的免费邮箱会天天有人挑刺说不满意，而他买商业方案以后，谁有意见谁就去找老板请款买新模块，反而落个清静。

 

我们并不介入用户内部管理问题，但我们要把客户变成朋友，而不是做一个冷脸旁观的衙门。

 

4.推进业务的能力

 

无论是个人技术革新业绩，团队节省成本业绩，还是内部工作流改善，甚至对外服务能力优化，都是帮推进客户的业务，帮客户出政绩。

 

客户很容易会异想天开，我现在更多是说服他们的想法达不到出政绩的目的，大鸣大放后黯然收场，对客户也不是好事。

 

传统IT企业在198X年成功崛起，是因为他们的技术帮客户延伸了业务能力，比如用ATM机帮银行拓展柜台、用更好的技术算账和转账；最近十几年则只能靠拿软硬件升级来从客户手里套钱，上那些IT系统只是保命续命却诞生不了新生命。

 

希望云厂商能够引以为鉴，我也在摸索如何帮客户真正意义上推进业务。

 

人员需求

 

客户需求不能靠谦卑的态度来引导，而是可靠IT技能方案的输出。这对方案推进者，也就是解决方案架构师的个人素质要求非常高。技术上要可以取信于客户技术团队，又要非常了解云产品，还要认可企业级IT服务模式，这才有可能胜任这项工作，让客户的消费额上千万甚至上亿。

 

只了解产品说明书的业售前是完不成这种工作的，从云技术后台转售前的同样也搞不定该工作。解决方案架构师必须是离职后能胜任客户侧技术经理角色，对客户侧的技术环境、业务流程非常懂行才行。按照懂云技术的售前、或懂售前的云技术的标准去选拔都方向不对，解决方案架构师应该是供应商替客户技术运营团队招聘的顾问。

 

附录参考

 

我以前写的文章，解决方案架构师职位定义；

 

我以前写的中国云计算系列文章文章，不同客户的不同部门的不同诉求，在03采购篇和06客户篇中有类似的观点展示。