<delect id="xdj5x"><menu id="xdj5x"></menu></delect>
<sup id="xdj5x"><label id="xdj5x"><nav id="xdj5x"></nav></label></sup>

    <em id="xdj5x"><tr id="xdj5x"></tr></em>

    <dd id="xdj5x"><tr id="xdj5x"><kbd id="xdj5x"></kbd></tr></dd>
    <div id="xdj5x"><ol id="xdj5x"></ol></div>

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

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

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

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

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

    公有云技术服务
     

      先说说背景是什么

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

      还有基于大规模计算能力的AI产品,无论是从人力投入,还是资源投入,一般的公司?#25216;?#23569;再花费巨大的成本从?#26041;?#35774;,从零做起。

      我们也是如此。

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

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

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

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

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

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

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

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

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

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

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

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

    公有云技术服务
     

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

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

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

      提点建议

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

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

      所以,要自上而下建立客户服务意识,以客户为?#34892;模?#23545;客户满意度负责,然后不断的宣传,不?#32454;?#36827;,不断从问题中?#27492;?#21644;总结。

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

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

    公有云技术服务
     

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

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

      第三,反向?#24049;?#20307;系的建立,客户问题的SLA响应和解决,客户需求反馈的效率,客户满意度的反馈,等等,要形成反向?#24049;?#26426;制,不能只?#24049;?#19968;线的人。

      意识的加强,再加上合理的?#24049;?#26426;制,前后?#21496;?#26356;容易齐心协力,朝着一个目标走。

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

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

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

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

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

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

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

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

    上一篇:下一篇:
    辽宁十一选五技巧