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

2019-03-21 09:34:04分类:云服务端开发10830

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

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

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

公有云技术服务
 

  先说说背景是什么

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

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

  我们也是如此。

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

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

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

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

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

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

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

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

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

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

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

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

公有云技术服务
 

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

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

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

  提点建议

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

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

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

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

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

公有云技术服务
 

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

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

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

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

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

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

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

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

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

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

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

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

上一篇:下一篇: