服务组织:如何减少被客户要求击穿?

发现SaaS企业中有这样一个普遍困扰的问题:客服或CSM无法解决客户的问题,经常需要找研发同学帮助。因此研发干部同学不得不分心留意众多微信群里的紧急情况(否则客诉时会被领导批评),不同研发同学也会花很多时间解决重复或类似的问题。而客户大大小小的问题解决得慢、体验也很差。这个问题在咱们企业是如何困扰、解决或思考的?

总结起来,破解这个“被击穿”问题,有一个条关键思路:①客户问题分类分级 → ②技术专家常驻或轮流值班→ ③知识沉淀 ④提升服务岗位能力。

同时,要求大家不断学习新知识毕竟是一个违背人性(懒惰/节约能量)的事,⑤我们也需要设计出产品-服务的联动运营,并形成闭环。

具体内容如下:

一、对客户要求和岗位分类分级

我们可以设法将客户问题分类:A. 应用问题(解决方案、配置可解)与B. 技术问题(代码bug、设计缺陷)。

也可将客户问题和服务岗位都进行分级:P1~P4级问题,T1~T3级服务顾问。

T1(群客服等)解决不了的问题,拉上T2(二线技术支持)或T3(技术专家)一起处理。

重大、紧急的问题,设置特殊处理通道“爆灯流程”,爆灯问题优先级最高,同时指定技术负责人协调资源、透明进度、事后复盘。

同时,面对客户坚持“首问负责制”。尽量不“转交”客户给技术岗位,服务全程由首问客服专员或专属CSM(客户成功经理)作为第一责任人。服务岗位的同学要设法全程跟进问题,帮助客户解决问题;同时,自己也学会处理方法、沉淀到知识库;对于自己不能掌握的技术手段,至少厘清来龙去脉和寻求帮助的路径。

二、组织结构及流程升级

在组织方面,有这样一些措施保障问题处理的组织效率。各家根据自身情况做出不同选择。

  • 【优先服务部门内部消化】将客户要求提交给技术部门前,服务部门内部先做一遍过滤。同时,每个区域一线客户成功团队(或在线客服团队)都培养服务专家(/讲师),能及时给自己内部团队答疑解惑。
  • 【设置服务部门内的技术专家岗】这样可以更好地将遇到的问题沉淀在服务部门内部。作为一线与后端的桥梁,可以解决85%-90%的问题。
  • 【技术团队值班制】轮流派遣产品及技术专家到服务部门值班。

三、知识沉淀方法

把每次对客户要求/提问的应对沉淀到知识库中,我们客服/客户成功的工作才能不断提效。这里也有一些实践方法:

  1. 在内部知识库中沉淀培训资料、解决方案(配置方案)。
  2. 服务部门内部输出常见问题操作手册,内部赋能,算在客服团队的组织绩效和同学个人的职级答辩内。
  3. 知识库可以找资源自己开发,或者用其他第三方软件。需要有指定人来运营。

四、服务岗位能力提升

笔者在使用一些SaaS时,可以明确感受到,客户的很多问题解决得很慢、令客户不满意,最大短板还是出在首问客服/CSM的能力不足上:不懂客户的业务、不了解自家产品如何配置能帮客户解决问题、不懂合作产品(例如企业微信)的基本操作……

我把这个问题发到朋友圈,咱们圈里的大神阿朱回复到:“记得20年前的实施顾问和客服支持人员都会写SQL……”

也许到了今天,不是每个产品都要求服务岗位的同学会写SQL(Structured Query Language,数据库结构化查询语言),但“技能越高越能帮助客户”这个道理是没错的。这也令SaaS产品客服、CSM岗位的同学有更长远的专业发展机会。

作为第一责任部门,服务部门需要在各个服务岗位的多个阶段做好培训和激励。

这里有以下做法供大家参考:

  1. 在新员工时期就增加客户业务培训、产品使用场景。
  2. 参与项目工作后,区域内月度组织专题解决方案培训。
  3. 产研部门针对CSM季度开展常规问题处理的培训,定义各种业务支持流程等;
  4. 产品运营负责迭代需求承接、跟进、产品运营培训、落地方案制作等。

五、服务与产研协作的运营

“运营”是高级话题。当公司已经将服务的基础工作做到位,如果想更进一步,就需要思考如何“运营”了。“客户成功共创营”的专家和学员们提供了这样一些运营的好思路:

  • 建立一个虚线团队“数据团队”,针对所有日常问题、需求、bug、发版问题进行整理分析,产出相应报告,帮助、推进产品稳定;
  • 研发团队内部设置「产品运营」岗位,除了面向研发做记录,优化研发的质量、提升问题解决效率之外,研发也会标记哪些问题是CSM应该掌握但是直接拉了技术资源的“坏案例”,反向提升CSM对产品的掌握能力;
  • 根据公司的组织架构情况,制定一些运营指标进行管理,包括:需求上线率,bug修复率,问题故障率,发版影响率。根据指标来给技术团队提要求。同时在做整理分析的时候,甄别需要业务掌握的知识,要求问题流转的时候“自闭环”。
  • 每个季度找一些TOP疑难/高频问题,定向主动攻坚或者培训。想办法把“成果”量化。

另外还有一些很优秀的实践,由于上下文信息量大,这里就不一一叙述了。

总结:产研-服务协作设计的原则

作为本共创营的引导者,我也不能只罗列大家的最佳实践.

在此,我基于以前的认知和这次非常有价值的探讨,总结一下产研-服务的组织协作设计原则:

  • 在创业团队早期,岗位越混合越好,从创始人到产研都去一线接触客户,以最快速度获得第一手客户反馈,快速迭代产品。
  • 在上规模后(例如超过50人),专业才能专注,专注才能解决长远、深度的问题。

因此,对上规模的SaaS团队,产研岗位、实施岗位在工作性质上不能随时打断手头工作去响应客户,所以我们需要设置隔离带:

  • T1客服:快速响应、跟进客户的单次咨询
  • T2技术支持:同时支持多个T1
  • CSM客户成功经理:专注有限个数客户(一般是200~400万ARR)的长期使用和续费、增购
  • 专职/轮值在服务部门驻场的技术专家:及时解决客户问题、判断是否需要已交技术团队、沉淀知识

这样设计的目的有三:

  1. 快速响应客户;
  2. 在服务部门沉淀知识;
  3. 保障产研专注工作又能有效率地深度接触客户。

特邀作者

吴昊,微信公众号:SaaS白夜行,SaaS领域知识沉淀者,《SaaS创业路线图》作者。每年与100位SaaS创始人深度交流,结合实战不断在公众号及视频号做内容输出。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部