一位云架构师用服务打动客户的故事之八「顾问式销售的三把武器」

今天接着上一次文章接着聊,开始之前了也聊聊上一篇文章的反馈情况,自从上一次对话方式的文章发布后,有非常多的正在前线的作战的销售伙伴们加我好友了,并通过邮件联系到我,表达了很多正在遇到的‘困境’,比如;我不懂技术,怎么能跟客户互动好?、我是个技术,但是我就是跟别人不来电,不知道怎么开场?


文章收益人员:销售、售前、正在转型做销售的技术(售前)


其实有的人看性格,有的人看心情,也有的人看经验,但不得不说售前是一个急各种综合素质能力于一体的岗位,需要不断修炼自己,强行让自己走出舒适区的工种。
包括我坚持写这个的心态也是一样,希望分享一些工作经验给大家。

笔者联系方式:[email protected]



此次交流,侧重与业务线的交流和沟通,这里不会分享技术原理。文章已通过内部团队脱敏审核,请大家放心阅读:)



分享形式将会使用‘对话形式’,最大化的还原我作为偏业务线(架构师)临场与客户沟通时候的心理变化以及应对策略

本次交流重点简述
? 一次奇妙的沟通际遇
? 顾问式销售的三把‘武器’「此篇分享主要内容」


上篇分享概要


还记得上一篇我们是如何临场‘见招拆招’的情境否?化被动为主动的技巧其实并没有想象中的需要技术很强等等,只需深刻的理解我们客户业务场景,有一定的技术底蕴。将一个相对专业的技术术语解读为用户听得懂的语言,这才是一个尽责的‘售前’工程师最应该先理解的问题,而不是讲最好的方案,吹最牛的皮。


上部分,我们从对方老总携各个事业部经理、主管来拜访我们的一次会议说起,一直到会议结束的两个小时后,我们拜别对方各位总。
今天要复盘的部分就是促成用户签合同的第二次关键里程碑事件。
我把这部分的内容叫做为‘顾问式销售的三把武器’,今天也详细的给大家讲讲这个难得的经历和笔者内心世界的独白。


一、武器其一‘换位思考’


1.1在业务线的工程师,需要把自己当别人,把别人当自己
? 要把客户的痛解读为自己的痛



在会议结束后的那一周,我和我的同事整理好了技术细节的方案说明、成本设计方案、项目实施交付文档以及项目管理推进文档以及更多文件。
销售同事如愿约到了客户的boss在下一周的周三下午2:00我们在客户现场见面并交谈更细节的内容(也就是我上面说了各种细节文档),这里也稍微提一嘴,客户是国有企业,一家做人力资源服务。


☆场景复原1(对话方式)



Allen:哎呀,终于在这边见到领导了,真的是感觉上次会议就在昨天发生,时间太快,太快。



C-Boss:上次说要早点来,也没见你早点过来,硬是要到这周才过来。



Allen:嗯哈哈,,,我这上周不是临危受命,给您唠叨了俩小时,你不嫌我话痨,我都有点嫌弃自己话多了,加上当晚飞去深圳,这也是相逢恨晚,无奈之举,领导多体谅体谅我



Customer:你终于来了,Allen。来来来,我先带你逛逛咱们公司,我们老板这会要去面试一位高管稍后过来,上次参观了你们公司,这次来看看我们的公司。
Allen:得勒,领导,那我和同事先转转,我们一会在会议室等您过来。



C-Boss:成,别光顾着看美女,我们这美女很多的~~~



Allen:哈哈哈….

(此处省略参观中间的言谈细节)
Customer:我们在这里先谈一会,方案细节呢一会等老板回来后我们开始。



Allen:好的,好的。这一次来,准备了好几份文档:项目交付实施文档、成本设计方案、技术细节方案说明、项目管理文档等等,一会等老板一起review。



Selina:Allen,你最近忙什么呢?到处飞,也没见歇着



Colleague:allen是大忙人啊,公司很重要的人物,必须支持全国的业务,所以这不就变成现在的‘空中飞人’了嘛。



Allen:你可别埋汰我了,这哪是革命人物,这是鞠躬尽瘁死而后已的节奏。。



Selina:是吧,我们最近可头疼了,关于这个APP上线的事情。



Allen:方便聊聊这头疼的事情不?



Selina:开发商那边一直托着进度,你也知道我们的情况,我们根本不懂,只是个协调人盯着这个事情。没法从技术角度思考到底哪里出了问题?这是第一个问题。其次呢,是我们对接的那个银行,进度也特别慢,偶尔要这个材料,不时又要我们提供其他纸质材料,弄得我烦都烦死了。还有就是,我们老板盯得紧,今年业务能不能做起来就靠着APP了,所以压力挺大的。


旁白:
第一个话题潜台词:‘你们要帮我站个台,出出主意’
第二个话题潜台词:‘其他人不想管,我也不想管’
第三个话题潜台词:‘这个项目很重要,别搞砸了’



Allen:正常的,因为这个协调看似是个可具象的工作,但它其实是个比较偏集成的活,要考虑很多。不仅仅只是眼下的云服务器这么容易。况且咱们和开发商有些合作不愉快的地方,并不代表是对方的问题,可能我们确实有些语言对方第一时间没有办法明白,造成沟通低效影响项目进度。这类事件在圈子里是经常发生的事情,压力别太大。



Allen:一会领导过来,我会帮咱们从客观的角度说明下,这个不能一蹴而就,是个慢工出细活的事项。您这边列出一些现在的问题,我们呢帮忙侧面分析下。这样或许能让大家的压力没之前那么大,而且今天既然来了,我相信领导会愿意多听一些我们这些‘久经沙场’的人一些声音的。



Allen:况且我们是过来帮助咱们更好的完成这个项目的,除了态度要诚恳,技术服务要细致之外,更重要的是减轻大家的压力,帮助咱们更好的对接各方,这就是我们应该做的,不用客气。



Customer:那太好了,非常感谢,这就是我们现在的痛。


二、武器其二‘切勿自嗨’

? 客户不一定不懂,或许只是试探你懂不懂
? 不要陷入到自己的状态里面一发不可收拾


☆场景复原2(对话方式)



C-BOSS:各位,不好意思,前面那个会耽误了一会。



Colleague:不耽误不耽误,您进来的正是时候,现在属于民主生活会的状态



C-BOSS:哈哈,是吗?,挺好挺好。



Allen:可不是嘛,领导,很显然,我的气质很贴近咱们这里的风格



Allen:领导,各位,那我们就正式开始过今天主题:1、方案的详细细节 2、部分交付材料的演示 3、下一步跟进计划建议。我们先从第一个开始
(此时,同事已经在分享屏幕的地方准备好了,我示意同事可以开始了)



Colleague:各位领导,根据上周我们沟通的请,我将方案进行了更加细致的标注,现在我来带着大家过一下这个方案的细节。



Colleague:第一部分是整体云上业务架构的分层设计详细描述。第二部分是在设计框架中会交付给您这边的材料演示。第三部分是基于目前情况我们的下一步推进计划


(此时,大家稍微脑补下这个画面,‘我的同事在讲台上讲的很自信,几乎每个细节都讲到了,非常开心尤为自信’,起初我因为手机有个信息要回复,就过多注意用户的状态),后来发现用户在开始后的二十分钟后,不停的解锁看手机,回复消息。我立刻意识这是个危险的信号)
(倒不是说我的同事讲的不好,而是用户他跟之前来的那个状态是一样的,听不懂。更关键的是用户的领导的表情也比较严肃,相对进来坐下前的状态紧张了很多)



Allen:john,你先停一下……..各位领导,这个地方主要讲述的重点是‘数据安全’,因为目前我们的APP中有涉及到银行交易数据,故在这个地方进行了加固处理。不知道这个环节,各位是否明白?



Customer:这个明白的,john设计的很好



Allen:嗯嗯,这个也是方案中很关键的地方之一,john你继续吧。



Colleague:嗯好的,我继续讲下一个关于主机安全的设计细节……..
(再一次又出现了这种情况,老板是不是看看手机,其他几位也是时不时回复下信息,此时我在同事讲完第二个比较关键的技术点后,示意同事‘我要插嘴’了)



Allen:领导,这个地方呢,是此次项目云资源采购中在安全部分占主要支出的资源-主机安全资源。



Customer:噢,是吗?



Colleague:嗯呢,是的,这个安全产品占了接近总资源的30%。



C-BOSS:能不要吗?这么贵。



Allen:这个要慎重,您看您APP都花了两百多万了,因为这个安全产品没买,导致数据泄露,影响公司形象了这就略有些‘因小失大’了。相对于开发投入,这些费用都是毛毛雨,最重要的它解决的是安全问题,如果是性能负载的增强,我是认同先不要购买这个思路的。



C-BOSS:行,你们继续。我接着看你们下面的内容



Allen:好的,领导您有疑问随时打断john,这一次来就是要更加详细的结束工作细节,您可要多提意见。
(我示意John,继续,并注意时间,别讲太久)


武器其三‘云淡风轻技术,重点关注商务’


? 顾问型销售,要从技术聊到商务,从商务回归技术
? 在适当的传递技术服务价值后,引出对公商务的重视和规范操作必要性



在我的同事讲完技术细节后,我们与用户进行了一个简短的交流,把当时产生出来的疑问和不解逐一进行详细解释,并告知处于什么考虑来执行。
随后我示意同事,最后一部分-项目管理这部分交给我来沟通。
(john走下来,把翻页笔交给了我)


☆场景复原3(对话方式)



Customer:allen你来讲啊?



Allen:是啊是啊,同事john需要喝口水,还有一些不重要的部分,我来给大家做个简短的汇报。



C-BOSS:哈哈哈,可以可以。



Allen:项目的整体方案细节设计,各位觉得是否还有不清晰的地方?



Customer:我们没有其他疑问了,很不错



C-BOSS:你们这个付款,商务的细节怎么操作的?



Allen:领导,这正是我要在这个部分跟大家汇报的。我们先看下此次方案丰富后的报价的变化。
(我打开了整体的资源服务的报价单,分别介绍了这些资源服务的价格)



Allen:我们这边的项目交付 流程是这样的,从咨询、设计、出方案、合同、进入交付、到完成交付进入稳定运维阶段后就结束了。现在呢我们处于-出方案末的阶段,下一个阶段是合同阶段。



C-BOSS:能同步进行吗?比如,你们先做,我这边安排人同步进行合同对接



Sales:可以的,老板。但有个地方需要您注意一下,我们合同阶段完了后打款的账期不能超过15天(假设时间,非真实时间),所以您这个要注意下。



C-BOSS:30天账期是否可以?



Sales:可以是可以,就是需要申请下。



Allen:是这样,领导。签完合同后,我们尽可以‘进场’开始干活了,但因为里面有资源的费用也有服务的费用。在我们这边资源和服务的合同是一起签。如果您延后账期,那资源的钱就需要我们垫付了。因为金额比较大,这个申请流程比较繁琐,而且时间不一定能在这周完成。所以我们还是建议您在这个事情上,按照正常的时间来,比如七天内等等。



Sales:对的,包括目前john给您做的这些方案和实施交付,都需要内部订单来作为前置条件,如果提前进场,我这边就需要一些流程要走。



Customer:我们理解,因为还有一台服务器和一台网络设备需要购买,这一点确实需要我们加速下打款流程(面对老板说),还有就是他们的人要来现场做,我们能理解你们这个请求。



C-BOSS:好的,还有就是上次我说的,那个关于跟你们签,公有云厂商会不会认然后出现故障出现不赔付的问题。你们现在能做承诺吗?



Allen:当然可以的,上次有提到我们属于服务商跟您这边发生合同关系,公有云厂商对外的SLA服务等级不会因为‘不直签’出现其他情况。我们可以在合同最后以补充协议的方式附上公有云厂商关于出现SLA等级不达标的赔付协议文件的。



C-BOSS:好的,这个不错。另外关于如果在今年我们的服务器进行扩容,价格以今天你的报价单里面的内容为准,如果出现了涨价情况,涨价溢出的部分你们负责。



Allen:这个我这样回答您,您看是否OK?现在我们是用的一个相对合理的服务器的工作负载来评估资源的购买量级。但后期您上次有提到过,APP本身有比较的潜力,尤其体现在用户量上,所以未来比较有可能会扩容。但关于涨价这一点上,我给您解释下,云上的服务器价格每个阶段都不一样,因为云上的服务也会出现这种类似‘购物节’采购季节的活动。您看我在合同上补充一条说明,新增服务器以官网实际价格为准。您看可以吗?



C-BOSS:我接受。



Allen:而且云只会越来越便宜,现在各种公有云厂商主动降价的活动也挺多,我认为您不必过多担心这个。



Customer:那你配套的服务会涨价或者降价吗?



Allen:这是个好问题,这样回答您吗?服务其实背后是人和体系还有工具的组合输出,每一年续签,服务费用不涨价就是变相的‘降价’,这一点我可以承诺给您,在合约期内,比如今年是按一年一签的。服务费用完全以目前协商的价格为准,包括新增的资源所配套的服务费用都是按照这个规则测算。



Allen:还有,我们既然来了,那也一定要有些诚意,您年付的话,我给您减免一个月费用,只需要支付11个月即可。



C-BOSS:不错,挺会谈项目的。其他的没问题了。
(接着就在很融洽的一些闲聊中结束了会议,值得一提的是在接下来一周,客户签完合同后不到两天,就将一年的服务合同打款了)


# 关于方案细节,汇报细节我这里暂时不展开,未来会更新在另外的博文中


回顾下今天三个‘武器’

思考今天故事中的三个武器。你觉得哪些对你有用?又回想起哪些曾经作为售前去客户现场的场景?


这类客户的赢单关键是什么?
? 把换位思考当成习惯
? 不要自嗨
? 技术是基本功不是不重要,商务是加分项懂一点更专业



☆贵在坚持,请努力!
谢谢各位的阅读,又进步了一些,每天进步一点点,下一次

Allen人生格言:越努力,越幸运~~

原文地址:https://blog.51cto.com/allen686/2423275

时间: 2024-11-09 12:18:39

一位云架构师用服务打动客户的故事之八「顾问式销售的三把武器」的相关文章

一位云架构师用服务打动客户的故事之七「腾讯云·如何在临场用服务拿下甲方Boss认可?」

距离上一篇文章有很久了,确实一直想保持这种节奏,但一直出现'脱更'的情况实属无奈.除个人工作的调整之外更多是因为到处出差'飞'的状态. 时间越久,越是发现技术和沟通的两把武器,技术在技术人员身上是没有问题的,但是在沟通上问题极大.虽然说'自古套路得人心',但初心总归是好的.在国内,目前有非常的做云计算服务的公司,今年格外多.尤其是伴随华为云发力.AWS发力和各类公有云在基础架构上的'白菜价'上,对'迁移.上云服务.对持续运维服务'上有简单而又粗暴的需求.因为信息敏感问题,最终用户以"用户&quo

一位云架构师用服务打动客户的故事之六(阿里云上的MSP最佳实践项目分享)

最近找了一个典型的云服务客户的案例对内进行分享,今天把核心内容脱敏后分享出来.希望能给目前在路上(做云服务MSP)的同行,有一些借鉴意义或者帮助. 该用户据全年跟进情况,目前该客户距正式启用我们公司云服务(运维服务)的日子已经有半年有余了,目前整体趋于稳定,故将目前用户进行深度复盘剖析,让各位伙伴更好的从该客户案例中提取一些有用的"武器"."售前技巧". 云产商:阿里云 企业背景-日企上来的终极三问~ > 为什么选择我们做云服务商?PS:此云服务并非指的是阿里

一位架构师用服务打动客户的故事之四

有些日子没有整理案例了,回顾了下上次案例分享的日子,已经有将近四个月了.. ~~~~~~~ 从开始在51CTO上写架构师服务这个系列后,因为留了联系方式后,有不少志同道合的的朋友留言.加好友对一些特定的场景进行交流,其中个人收获并纠正了不少错误的观点.无论如何还是要谢谢有这么个地方,让我去记录并分享个人的一些经验和心得. ~~~ 又脱更这么久了,抱歉抱歉~~~(读者:"信不信我把你按着地上摩擦~~!!") 最近确实忙着很多连续性的工作,但都不是具体配啥了,让各位失望了~~~:),如我前

一位架构师用服务打动客户的故事

自上一篇的文章<记一次完整的安全技术解决方案遭遇成本考验后的"退步与博弈">记录了我作为PM+架构师为客户提供的一次咨询.实施交付.售后运维的整个项目生命周期(除商务)很感谢51CTO这样的平台,能让结实不少志同道合的朋友一起探讨技术,探讨生活(CTO运营人员:时隔一年多,这小子终于讲出来了,,一万吨感动!!!) 在6月12日,我们的交付物得到了客户的高度认可,并顺利进行了项目结项会议的开展,包括接下来即将前往客户现场全面讲解一次我们此次项目所有交付物. 今天发散的聊下在2

云架构师进阶攻略

https://mp.weixin.qq.com/s/tHRl5OQHY2mNXqKwACCVWw?utm_source=tuicool&utm_medium=referral 一.架构的三个维度和六个层面 1.1.三大架构 在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构. 第一个是IT架构,其实就是计算,网络,存储.这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻运维的负担.数据中心,虚拟化,云平台,容器平台都属于I

云架构师的进阶之路

原文:云架构师的进阶之路 一.架构的三个维度和六个层面 1.1.三大架构 在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构. 第一个是IT架构,其实就是计算,网络,存储.这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻运维的负担.数据中心,虚拟化,云平台,容器平台都属于IT架构的范畴. 第二个是应用架构,随着应用从传统应用向互联网应用转型,仅仅搞定资源层面的弹性还不够,常常会出现创建了大批机器,仍然撑不住高并发流量.因而

云架构师进阶攻略(1)

此文已由作者刘超授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 一.架构的三个维度和六个层面 1.1.三大架构 在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构. 第一个是IT架构,其实就是计算,网络,存储.这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻运维的负担.数据中心,虚拟化,云平台,容器平台都属于IT架构的范畴. 第二个是应用架构,随着应用从传统应用向互联网应用转型,仅仅搞定资源层面的

云架构师进阶攻略(2)

此文已由作者刘超授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 八.基于OpenStack了解云平台 当有了虚拟机,并且虚拟机能够上网了之后,接下来就是搭建云平台的时候了. 云是基于计算,网络,存储虚拟化技术的,云和虚拟化的主要区别在于,管理员的管理模式不同,用户的使用模式也不同. 虚拟化平台没有多层次的丰富的租户管理,没有灵活quota配额的限制,没有灵活的QoS的限制,多采用虚拟网络和物理网络打平的桥接模式,虚拟机直接使用机房网络,没有虚拟子网VPC的概念,虚拟网络

学汉语、来云栖、海外布道阿里云……这位印度架构师不一般

阿里云MVP(最有价值专家).印度架构师Sai Sarath Chandra P 最近有了一个新的爱好:学中文. Sai学中文的想法,与一家中国企业有着密切的关系. "当时因为工作需要,开始寻找用于运行机器学习.性价比比较高的云产品.在这个过程中,我偶然发现了阿里云."从使用产品开始,Sai与阿里云开始结缘.随着产品使用的深入和与阿里云团队交流的增多,Sai已经不仅仅是一个用户,而变成了阿里云技术和产品的讲解者.传播者. "在印度,我见证了阿里巴巴的发展,并成为了阿里云MVP