专栏首页Forrest随想录谈谈公有云的客户服务和技术支持问题

谈谈公有云的客户服务和技术支持问题

我之前写过一篇Google CRE的文章,这是Google云上面向客户的一个技术服务和支持岗位。具体可以看《Google SRE之后的CRE,一起来看看吧

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

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

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

先说说背景是什么

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

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

我们也是如此。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

提点建议

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

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

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

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

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

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

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

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

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

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

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

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

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

第六,对产品形成共性的可服务约束要求。

技术上,产品必须要具备容灾和快速快速切换能力,方便的可运维能力等等,这种toB平台类的产品,如果这个能力都不具备,我认为都不应该上线。

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

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

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

最后

说个标杆,单从客户服务和技术支持的角度,华为原有的那套服务体系还是最为完善的,我从进华为办公区开始,看到的标语,经过的培训,周围人的言传身教,都是“客户第一”。

我离开华为3年多,到目前我都敢说,在国内和全球,这个理念下的服务和技术体系,当前都还是最先进的。

不过,在面对新业务场景的时候,这套体系也不是十全十美,这一点我之前也是深有体会,但这个更多是机制上的问题,这或许也是华为未来面对新型的toB市场的一大挑战。

国内目前的云,至少从我接触的情况感受下来,要改进的地方还很多,仍然在建设初期的路上,我们也期望这个步子能在大一点。

本文分享自微信公众号 - Forrest随想录(forrest_thinking),作者:Cheng哥

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-07-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 搞专业,还是转管理?

    我的一个同事毕业后到目前,4年左右,做的不是技术岗位,是偏产品运营类的岗位,因为个人能力比较突出,再加上他负责的业务发展比较快,所以主管让他去带一个10人左右的...

    赵成
  • 大规模微服务场景下的性能问题定位与优化

    今天我的主题是在微服务场景下的一个性能问题的定位优化,那么今天会讲一个我们其实出现的一个真实的一个场景,然后其实还是花了蛮长时间,然后把这个东西才定位到一个具体...

    赵成
  • 云架构师进阶攻略

    第一个是IT架构,其实就是计算,网络,存储。这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻...

    赵成
  • 麦肯锡教我的思考武器

    这篇文章不是关于金工-量投-机学的,为什么跨度这么大写这篇文章,原因是硬实力 (比如专业) 和软实力 (比如管理) 两手都要抓,而当你职位越来越高时,软实力也就...

    用户5753894
  • 业界 | 如何像程序员一样思考

    即使你的运气一向很好,这种方法也并不值得使用。事实上,它可能是最糟糕的解决方法,因为会浪费大量的时间。

    大数据文摘
  • 尾部的0和小老鼠喝药

    因此就有解法1: 1.对每个数字依次除以5,如果余数为0则+1,如果得到的商除以5余数仍为0则再加一,直到余数不为0再继续下一数字。 实例:

    呼延十
  • 研究调用链跟踪技术之jaeger

    最近在做微服务构架里有关调用链跟踪(也有叫分布式追踪)的部分,有一些心得,这里总结一些。

    jeremyxu
  • Centos安装Python3

    从上面可以看出我们可以安装 python3,python34,python36。那么我以安装python36为例子,下面是安装python36和其对应pip的脚...

    hankleo
  • 【答疑解惑第二十三讲】C语言main函数那点事

    疑惑一 C语言函数的参数问题 在C语言中main函数大家见到的基本有两种:一种是带参数的如int main(char * argc,char *argv[])...

    程序员互动联盟
  • 【漏洞赏析】安全运维那些洞

    aerfa

扫码关注云+社区

领取腾讯云代金券