云客户需求引导管理--实战型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客户篇中有类似的观点展示。

 

收藏 评论(2)
分享到:
共2条回复 最后由代开深圳票 回复于2019-08-06 22:34
#2 Q1058204131 回复于2019-08-05

棒棒哒

0
#3 代开深圳票 回复于2019-08-06

棒棒哒

0