基于公有云技术服务客户支持的问题论述

　　CRE，你可以说他是一个岗位，也可以是一套技术体系，也可以是一种管理模式，但是最重要的，对于客户来说，它是一种具备更优体验的服务模式。也可以看到云厂商是多么重视客户服务体验和质量。

　　我认为，客户的感受和体验，才是决定一家云厂商口碑的最关键因素，不重视客户服务，就等于砸自己的口碑和招牌，产品做的再好也没用。

　　今天，我把这个话题重新拿出来说，是因为最近经历的一些问题，让我深刻的感受到，时代在发展，技术在进步，合作在深入，但是我们公有云的服务模式明显滞后了。
 

 

　　先说说背景是什么

　　当前，我们打开任何一家公有云的网站，他们所能提供的服务都是极大丰富的，对于很多通用产品，从满足一般功能、性能以及稳定性的角度，都没有问题。

　　还有基于大规模计算能力的AI产品，无论是从人力投入，还是资源投入，一般的公司都极少再花费巨大的成本从头建设，从零做起。

　　我们也是如此。

　　所以，我们现在说的业务上云，已经是业务技术架构与丰富的云产品服务全面融合的模式，这早已远远超出原来基础设施上云的范畴。

　　这样的变化带来的挑战是什么呢？

　　我们知道，基础设施很重要，但是它的维护形态相对固定，就是设备和配置问题，一般出现问题，这个事情一般就由双方的系统运维对接完成即可，无需业务关注。

　　但是，一旦涉及到业务架构层面，就必然会涌现出大量技术细节上的对接需求，这个事情的处理就得上升到业务和技术层面去沟通，而不是运维对接就能解决的。同时，会涉及不同的产品线的N多产品，甚至会交叉产生大量的需求和问题。

　　无论是技术层面和是沟通协作层面，已经从原来仅仅是双方运维点对点协作模式，演变成了业务技术和云产品技术的多对多网状协作模式。

　　很显然，原来的技术支持模式也需要跟着改变。

　　当前，通常的售后支持，接口统一，你问什么问题，我就回答什么问题，能马上解决的就马上解决，不能解决的就转到后端处理，承诺多长时间内给出答复。

　　一般问题还好，但要是大问题，业务挂了，我都火烧眉毛了，你还跟个机器人一样，我问啥你说啥，或者还要催着后端处理，你先等着，这个体验就非常差了。

　　现在大家已经意识到这个问题，在沟通时也会同步拉上产品进行交流，但是这样做很多情况下只是解决表面问题，并没有解决根本问题。

　　这里所说的根本问题就是，客户服务意识，简单来讲，早期的售后支持人员，也就是基础设施的售后，大多具备很好服务意识，也有严格的流程标准约束，同时对其的考核很大程度上也取决于客户满意度。

　　但是在后端的产品技术，大多数研发出身，技术功底好，解决技术问题一流，但他们不对客户服务负责，不对客户问题负责，也不对客户满意度负责，在绝大多数后端产品技术意识里，我只对内部对我的要求负责，只对我负责的技术问题负责。

　　技术问题≠客户问题，这个Gap还是很大的，仔细体会，不细讲。
 

 

　　这就会造成，有时候在解决问题或者需求沟通时，产品技术虽然在线，虽然在客户现场，但是沟通完就沟通完了，离开现场后，后续的计划、Action以及反馈，很难得到后续的有效反馈。

　　所以，我为什么说，把人拉到一个群里，拉到客户现场，其实是治标不治本的，没形成意识，没有完善的服务标准遵从，没有考核机制约束，没有长期的培训和宣贯，我只能说，路还长着呢。

　　上面算是问题场景的分享，说是吐槽也可以，但是只提问题，不讲解决方案就是瞎BB，也不符合我的风格，所以建议还是得提。

　　提点建议

　　其实，如果上面那些问题能看明白，解决方案正常都可以想的到。

　　第一，客户第一的服务意识，以及文化建设，这个问题，不是点上的问题，不是说售后支持不到位，也不能单纯说产品缺少客户服务意识，这是个面上的问题。

　　所以，要自上而下建立客户服务意识，以客户为中心，对客户满意度负责，然后不断的宣传，不断改进，不断从问题中反思和总结。

　　做toB的产品，从产品设计之初，到产品交付给客户，再到后续的持续运营，都要体现出这种服务意识。

　　千万不要脚痛医脚，头疼医头，问题在售后这里暴露出来，就逮住售后这个点做整改，或者哪个产品出问题，就逮着哪个产品做整改，这些手段可能短期有效，但是长期仍然不解决问题，甚至产品技术人员从客户群里退出来，从客户现场回到研发环境中，原来是什么样，还是什么样子。
 

 

　　第二，产品服务体系要建立，至少原来那种单一接口，问题逐层传递的方式要打破，如果上面客户意识宣传和培训到位，这时就可以在产品技术团队中，成立产品售后支持，当然安排专职人员也好，或者研发内部轮岗也好，必须要有这样的角色和岗位，他的作用就是快速响应支持，直接面对客户，同时，至少要对这个产品的客户满意度负责。

　　研发经过内部轮转之后，真切的感受到客户的诉求是什么，有了客户意识的感觉，再去做产品，做出来的体验可能也是不一样的。

　　第三，反向考核体系的建立，客户问题的SLA响应和解决，客户需求反馈的效率，客户满意度的反馈，等等，要形成反向考核机制，不能只考核一线的人。

　　意识的加强，再加上合理的考核机制，前后端就更容易齐心协力，朝着一个目标走。

　　第四，原有售后岗位的角色转变，一方面，这批售后都有很好的服务意识和经验，他们的客户服务经验要固化和提炼，然后作为火花去燎原。

　　同时，这部分角色的能力要拓展，不能仅仅停留在原来基础设施的服务支持方面，产品知识面要更广，这样面对客户常见问题，才不至于一问就懵逼。

　　第五，服务经理岗位设定，角色提升，对于沟通协作能力比较强售后人员，可以培训提升为服务经理这样的角色，不对某一具体产品负责，但是对客户满意度负责，贴着客户走，深切的了解和理解客户的痛点和需求。当然，要有足够的授权，能够调动后端资源。

　　服务经理要专职一对一，贴着客户走，产品服务团队，可以一对多，他们的角色更多的解决问题，但是解决问题的层面要提升，意识要提升，这个就要靠前面第一、二条讲的机制来保证。两个体系中的人员形成虚拟团队，服务经理对虚拟团队成员的绩效有足够的建议权，甚至是否定权。

　　第六，对产品形成共性的可服务约束要求。技术上，产品必须要具备容灾和快速快速切换能力，方便的可运维能力等等，这种toB平台类的产品，如果这个能力都不具备，我认为都不应该上线。

　　管理上，要求产品与客户一起，必须制定各类事件的应急响应预案，SLA响应机制，同时要与客户定期进行演练，没有演练的预案就是耍流氓，无论是谁，都是流氓。

　　沟通机制上，每周、每月、每Q，每半年的定期沟通，短期的问题和需求跟进，中期的改进措施落地，长期的产品技术方向规划，这些都需要有例行、高效且目标一致的沟通来保障。

　　第七，重视客户感受，跟解决问题一样重要，问题解决了，需求完成了，不代表客户就一定满意。感受这个事情比较感性，我摆在这里，不多说，能理解的自然会理解，不理解的说再多也没有，如果真重视感受了，这个问题也就不是问题了。