新书预览-技术服务工作的呼吁和推演
目录介绍
本文6000字，目录如下：
本文其实是书籍预览
为什么分析技术服务工作
云厂商需要重视技术服务
谁来和客户技术部门交朋友
扛起客户流失的责任
“产研滚刀肉”的克星
此岗位的延伸收费方式
行业内有成功先例
意犹未尽的结束语
1. 本文其实是书籍预览
我写了一本云计算的书，已经进入了编校出版的阶段了，预计能在春节前后问世。
本书的目标读者是云计算从业者和想转岗做云计算的高级IT工程师，内容分布是：30%谈行业趋势和宏观逻辑，50%谈产品分析，20%谈各岗位的认知和经验。本书的书名预计叫《云计算行业进阶指南》，虽然“进阶指南”看起来很狂傲，但我对书籍的内容有信心，本书能够帮助工作数年的从业者“开悟”和“复盘”。
本文里大部分内容，和我的书稿内容重度神似，因此这篇文章算是对部分书籍内容的预览导读。只是编辑不让我在书稿里大放阙词，书稿内写类似的知识点更有条理，但也更含蓄。
2. 为什么分析技术服务工作
我在书中虽然分享了多个云计算岗位的经验心得，但是我最看重的是资源运营和客户技术服务工作。这两类工作的个人努力大于平台价值，职业技能非常稀缺。
虽然云厂商很重视产品设计和市场营销工作，我在书中对这些岗位也做了深度分析，但是行业发展至今，各个云厂商的产销工作已经差距不大。云厂商之间的产销竞争像是“组合版田忌赛马”，云厂商需要用自家的“上等马”淘汰友商的“中等马”和“下等马”，优秀产品需要匹配优质资源，精英销售需要申请到定制特批政策。
资源运营是个涉密内敛的工作，本书介绍此岗位的章节中，我会先提醒各个云厂商，赶紧把此岗位列入机密岗位，不要随意辱骂和辞退从业者，因为资源运营从业者最了解公司的真实经营情况。但是资源运营的工作范围很窄，并不适合做公开宣传分享，我在书里面也只能谈到浅显的方法论。
技术服务是我非常看重的另一份工作。这个工作在云厂商内部存在严重的缺位，绝大部分从业者根本无法区分“收费专家技术服务”和“免费售前售后建议”有什么区别。我早年间在类IOE“传统IT外企”里，给一些工业和金融企业做系统集成方案设计和技术支持。靠着这类工作养成的工作习惯，至今让我做云计算工作游刃有余。
在我看来，技术服务是一个“客户有需求”+“认知很神秘”+“技能要求高”+“云上有革新”的专家技术支持工作，这种工作的分析介绍，适合写成公开宣发的文章。
我对于该工作的定义分析，是面向未来发展趋势的呼吁畅想。信任我的读者，能从我的呼吁中看到对现存问题的深刻分析，能从我的畅想中找到属于自己的创新机遇。
3. 云厂商需要重视技术服务
在本书的第一章节我就会介绍，云计算即是云产品（技术），也是云资源，还是云服务。我们可以将产品资源和服务三者频繁互换，读者感知几乎没什么影响。比如说：
客户选择买你的云服务，是因为信任你们的产品质量；这次云资源出了故障，直接导致我们无法服务客户。
强调“云服务、云产品、云资源”三者可以平移互换，并不是为了玩文字游戏，而是在灌输一种行业认知。因为云厂商需要同时提供产品、资源和服务，而不同的客户不同的项目对产品、资源和服务的侧重点也不同，这导致云计算行业很难出现垄断，每个大订单都有“田忌赛马”式差异化竞争的空间。
在国内云厂商的职场环境下，虽然三者概念相同相通，但是现阶段“云服务”近乎绝迹。产研体系很容易把“做服务”和“产品标准化”当做对立概念，而且产品研发在做服务过程中有过多次被客户痛殴的悲惨经历。销售为了多签署几个大订单更关注云资源的投入，销售主张的服务就是让同事帮客户免费干活。整个公司里就云高管呼吁要“服务好客户”，但他们自己都说不清楚服务好客户有什么用。
4. 谁来和客户技术部门交朋友
我的书和公众号中，每次介绍云产品的定义时，就明确提出“以工程是为操作者的企业采购IT服务”。客户的技术部门会影响到云产品的设计和云资源的采购，就算销售签了单，客户的技术部门不满意，也有的是办法折腾云厂商。
云厂商实际工作中，销售、售前、售后，产品经理都可以对接客户。这些角色关注的都是客户采购部门的需求，实际上没人愿意和客户的技术部门交朋友。云厂商只有新增一个技术服务专家的角色，才能维护好客户技术部门的关系，让云厂商除了价格之外，和客户有一些能谈的交情。
我在书中和过往公众号文章都有分析介绍，销售主动找客户技术部门，不是套消息就是催进度，客户技术部门主动找销售就是投诉。产品经理虽然关注所有的客户需求，但是他们并不关注单独一个客户的状态感受。售前也经常接触客户，但是售前在项目签单以后，就和销售一起逐渐从客户现场消失了。
售后历来是个弱势部门，根本吸引不到优秀人才，没有优秀人才就不能强势的“服务客户”，只能唯唯诺诺的“安抚客户”。每次看到售后部门问客户“尚（你）能（满）饭（意）否（吗）？”，我都非常难过，这种问候有什么意义吗？客户因为不满意骂云厂商，那说明客户还想留下来；客户有故障但不骂云厂商了，那才是客户要流失了。
云厂商需要仿效传统IT企业，设置“技术服务专家”或者其他类似的岗位。这是个专业技术岗位，但不要求应聘者精通云计算技术，而是要求从业者精通客户侧IT技能，最好直接就是客户的技术工程师跳槽过来。该岗位不在销售体系内，而是位于售后或者产研体系内，通过“承担流失责任”，这个岗位能够和客户的技术部门做朋友。
5. 此岗位要扛起客户流失的责任
我浓墨重彩介绍的“技术服务专家”岗位，并不是另一种客服岗位，而是一个能扛起责任、有话语权的强势岗位。
在云厂商内部，一个部门要想有话语权，既需要拥有大量的高薪员工，还需要和公司业绩强关联才能要资源。该岗位需要精通客户侧IT技能，员工人数也不少，必须是一个高薪大团队。此时就有另一个问题摆在台面上了，该岗位凭什么跟公司要钱、要人、要权限？
我的回答是，这个服务岗位的最核心价值就是，为产品技术原因导致的客户流失负责，客户技术部门受伤如同打自己的孩子，客户技术部门受辱如同骂自己的老婆。
我在2020年研究过几个云厂商的营收数据，多家云厂商的客户流失金额能占到全年营收的30%左右。各家云厂商一直在签入新客户，只是旧客户流失的太多了，导致大家的业绩都是在原地踏步。
这些客户流失中，大致可以分为三类原因。第一类是商务原因，销售因为懒惰或者无能，没有说服领导和产品线批准降价。第二类原因是客户自然业务萎缩，确实有些客户业务停摆公司破产了。第三类原因是，因为故障、产品能力、服务态度等原因，客户技术部门决定将业务迁走。
过去的经验已经证明，销售并不能阻止第三类客户流失，甚至销售会故意放任客户因产品技术原因而流失。我在两年前写过一篇文章《从友商丢单看佛系生活》，介绍的就是上海某云的销售，很开心的把RDS事故和客户不满都瞒下不报，继续拿业绩提成。半年后客户迁离了，销售也换人了，黑锅由产研来背，损失由公司承担。
如果客户技术部门对云厂商不满意，最终导致客户流失，新成立的“技术服务专家”岗位可以负担主要责任。这个岗位不用去向客户做增收推销，他们专注于维护客户技术团队的利益和感受，并为客户做一些技术支持和咨询工作。如果客户技术部门有不满意，包括但不限于平台故障、产品能力差，最终导致客户流失，云厂商可以对“技术服务专家”扣发绩效，必要时可以直接辞退员工甚至解散部门。
一旦推行相关责任制，“技术服务专家”会和产品研发为客户故障打得刀刀见血流，也会和销售为客户流失的定性而争得头破血流。但这是云厂商内部生机勃勃的表现，现在云厂商看客户流失就是在沉默中混吃等死，聪明的销售都知道提前把流失客户转派给萌新销售顶缸了。
6. “产研滚刀肉”的克星
本文介绍“技术服务专家”角色，在一些外资云已经有类似的“客户成功工程师”“技术专家”等岗位，但该岗位和我的规划设想还是有个明显的硬性区别。该岗位不仅能够为客户提供技术服务，更是唯一能够克制“产研滚刀肉”的岗位。
前文提到过，产品经理不关注单独一个客户，这是科学分工的必然规律，但是也因此姑息了大量恶心的“产研滚刀肉”。这些滚刀肉创造了那么多故障、浪费了那么多资源、随意向客户承诺但就不兑现、拖累了很多好销售甚至耽误了很多好领导。但现行的云产销研分工规范中，确实没人能收拾这群混蛋。
如果国内云厂商设置了技术服务专家的岗位，该岗位要求员工技能上“精通客户侧IT技术+掌握常见云产品的能力水平”，该岗位的核心KPI是“客户不能因产品技术问题迁离本云”。这个岗位天生的克制“产研滚刀肉”，就像大公鸡天克蝎子精一样。技术服务专家为了自己不被辞退，也要制止“产研滚刀肉”的尸位素餐；“产研滚刀肉”扯各种技术原因，技术服务专家也能扯出一大堆技术原因。
技术服务专家可以属于售后体系，也可以属于泛技术体系，但不能属于销售体系内，这里主要有两个原因。第一是销售体系的业绩增长KPI和“同客户技术部门交朋友”有互斥关系。另一个原因就是，销售体系和产研体系存在结构性矛盾，而“产研滚刀肉”的一大保命秘籍就是把水搅浑，然后躲在产研体系的保护伞下。技术服务专家只有位于泛技术体系内部，“产研滚刀肉”就不能拉整个产研体系同仇敌忾了，技术服务专家还能高效率的和常规产品研发协同工作。
那俩个外资云都见识过正经卖钱的技术服务工作，他们很容易在云上照搬出了类似的工作岗位。但那俩外资云的营收增速很快，没有“产研滚刀肉”导致客户大量降价和流失的尖锐问题。因此国内云厂商做技术服务专家的权限，比在外企云做客户成功工程师的权限更大、责任更大，收益应该也会更大。
附记：AWS和AZure都是历史悠久的IT技术企业，但他们并不是那种“互联网基因”的企业，他们的“客户—产品—技术—销售—运营”之间的关系很专业也很稳固。而国内的云厂商都充斥着“互联网精神”，过分重视产品研发体系的发言权，结果招来一帮在toC圈子混不下去的投机分子，他们把客户当做羊群甚至韭菜，把销售当背锅侠和业绩耗材，这才会产生“产研滚刀肉”。
7. 此岗位的延伸收费方式
技术服务专家除了承担客户流失的责任，还能从三个层面收费或者抬价，为公司创造经济收益。
第一，面对政企金融和工业客户，云厂商可以报价出售原厂技术支持。而且云厂商的服务范围覆盖大批中后台软件和硬件，云厂商能售卖的原厂支持范围更大。
政企金融和工业客户在采购IOE类软件时会采购技术支持服务，采购硬件时也会购买4小时上门维保。客户一直有付费采购服务的习惯，云厂商不提供技术服务反而是客户采购云产品的一层阻碍。从甲方来看，自己付费购买的才是奉为圭臬的原厂技术方案，云厂商免费赠送的那叫“提建议和做推销”。
互联网云厂商肯定会有人反驳，说实际情况是“送服务都送不出去”。我就反问一句，云厂商派到客户现场的是做技术服务的吗？销售、售前、售后、产品经理，这些员工能帮客户干什么技术工作哪？本文介绍的技术服务专家，必须精通客户所需的IT技术，这样的专家能够帮助甚至指导客户技术部门的工作。
第二，面对年消费额数百万到数千万的中型客户，云厂商可以通过控制产品价格的方式间接收取技术服务费用。
这些客户没有养成直接采购技术服务的习惯，但这些客户也养不起太豪华的技术团队，而云厂商之间对这种体量的客户争夺的也不算激烈。在这个前提下，云厂商可以向产品毛利率尚可的客户，免费配置技术服务专家。
云厂商向客户分配技术服务专家以后，目标就是客户不会因为友商降价1%-10%的蝇头小利，直接放弃本云选择更便宜的供应商。当然了，如果友商的报价比本云便宜30%以上，这就是销售负责的商务问题了，我们和客户搞关系并不能让客户吃大亏。
第三，面对年消费额过亿的互联网大客户，云厂商可以通过“挑肥拣瘦”的方式，只承接最适合本云的优质负载。
互联网大客户自己有豪华的技术团队，云厂商敢涨价就快速迁移业务到其他云平台。但事情也就妙在这个“多云快速切换”，客户的采购部门只定义总体价格，而具体的切换决策，可是客户的技术部门来执行的。
云厂商如果能让客户优先使用自己想卖的云资源，或者客户稍微配合本云的维护和迁移需求，云厂商就能大幅度降低很多产品成本。云厂商如果派出了技术支持专家，诚心实意和客户技术部门交朋友，这个需求就是能谈的。
8. 行业内有成功先例
前文介绍了技术服务专家岗位能给云厂商创造的种种收益，肯定还是会有人说我在自娱自乐，我就介绍几个“半实名”的成功案例。这些岗位名称确实不叫“技术服务专家”，工作权责也没本文介绍的这么清晰，但云计算时代了，什么东西都要有发展创新啊？
上文第二段我就提过，我本人2010年之前，就在类似于IOE的企业里做技术支持。当时我的月薪六千左右，我们向汽车、精密仪器等制造业客户做人日报价时，一天能卖四千到八千元。
我曾经呆过的某云，他们的技术支持工程师可以替客户写Demo甚至写生产代码。此云的客户忠诚度比较高，如果产品价格只比友商贵10%以内的话，客户根本就不会跑。我刚入职没多久就看到一个通告：因为研发部门挖了他们好几个技术支持工程师，导致技术支持部门严重人力短缺，后续禁止产品研发从此部门挖人……其他云的售后部门，根本就没有这个脸面、能力和跳槽机会。
我曾经呆过的某云，他们的销售、售前和产品经理都很弱势，两三个技术支持高手彻底把握好了客户关系。运维部要发版上线、销售部要协调客户、产品经理想请客户站台，都要找这两三个高手来排板决策。他们就经常站在客户的立场上，质疑吊打技术部门，偶尔也会质疑销售部门，我想做客户访谈都是请他们帮忙安排的。
9. 意犹未尽的结束语
这篇文章已经写了很长了，确实意犹未尽，但我书稿里有一个章节一万多字都是在介绍技术服务专家岗位的，只是书稿内容没有公众号这么奔放自然而已。
我知道云厂商内部很难推进这项工作，但是客户有需求、友商做不到、岗位能兑现收益，这事就应该做。我去年就写过一篇文章，介绍只有30%的机柜被云厂商用了，今年IDC发报告说中国只有28%的服务器在公有云上，这么大的潜在蓝海市场里，大部分客户都需要技术服务来承接。
前文提到过，产研体系很容易把“做服务”和“产品标准化”当做对立概念。很多云厂商做服务的体验就是，没有边界、无限堆人、没有收益。但是服务本身也可以产品化、标准化流程化，你们该反思的是为什么自己的工作能力这么烂。
技术服务专家岗位在具体执行过程，可以记录详细的客户业务架构、技术需求文档等文档。这些文档主要用途是内控、以及和产品销售部门打架甩锅。但是这些详细的客户文档，也能够为产品设计和销售方案提供大量高价值参考资料。
下图出自《1492征服天堂》Conquest of Paradise