客户成功团队的定义可大可小,大客户成功团队泛指客服、实施人员、客户成功经理、客户运营等岗位,小客户成功团队仅指客户成功经理、客户运营等岗位。
从客户成功战略落地实操来看,笔者更倾向于大客户成功团队的概念,即将客服、实施人员、客户成功经理、客户运营等岗位全部纳入客户成功部门或客户成功中心,因为不管是客服还是实施人员,最终是要一起拿到客户成功的结果的。
而且客户成功的“先利他后利己”的用户思维及价值观,能够帮助团队统一价值观,真正全面落地客户成功战略。
根据产品不同的客单价、复杂度及客户成功所处阶段,客户成功团队组织架构可以分为4种模式:全栈式客户成功、主被动客户成功、精细化客户成功及一体化客户成功,如图2-1所示,其中CSM代表客户成功经理。
图2-1 客户成功团队的组织架构
一般来说,产品单价越高、产品越复杂,客户成功团队组织架构越复杂。
● 从客单价来看,客单价较低的产品,能够投入的资源有限,所以一般就配客服或客户成功经理就行了;客单价较高的产品,能够投入的资源空间较大,为了更好地服务好客户,以期带来客户成功价值产出,会配备单独的客服、实施、客户运营等岗位。
● 从产品复杂度来看,产品复杂度通常和客单价成正比。产品简单易上手,产品实施的工作就可以交由客户成功经理来完成;产品复杂、实施周期长,就需要设立单独的实施岗位来完成产品上线(Onboarding)的工作。
技术支持通常会放在研发部门,但为了更好地践行服务一体化,更好地协调技术资源来快速解决客户问题,部分SaaS企业也会选择将技术支持放到客户成功架构内。
其中客户成功据职责分工不同可能会涉及两个岗位:一个是客户成功经理(CSM),另一个是续费经理(AM)。如果客户成功经理直接负责续费,那么只需要一个岗位;如果客户成功经理不直接做续费,由销售来做或者是单独的续费经理来做,那么续费经理这个岗位有可能在客户成功部门,也有可能放在销售部门,这部分职责的划分在第6章中会详细讲解。
下面我们来详细看一下这几种不同架构下各个团队的职责及目标。
全栈式客户成功是指产品实施、客户成果交付、客户续费及增购以及基础的客户服务全部由一个人来完成。当然,说好听点叫全栈式客户成功,说不好听点就是“客户成功经理既当爹又当妈,啥都要干”。
一般是客单价比较低且产品相对简单的业务,或者业务早期资源相对匮乏的时候,会按照这样的方式来设置。
这种架构方式的优势是成本低、人效可能较高,一个人干了好几个人的活,在业务早期的时候确实能够节约成本,但这种模式对于客户成功经理能力的全面性、抗压能力、工作效率等要求较高。
缺点是各个板块的专业度可能不够,客户服务及时性很难保障,客户运营的深度也不够,因为当客户成功经理一个人需要同时服务这么多客户的时候,是很难做到客户的深度服务及沟通的,且客户成功经理在给客户做产品培训的时候,比较难做到对其他客户消息的及时回复。
所以针对这几个缺点,解决方案有两个:
● 一是通过设计相对体系化的客户服务及运营SOP(Standard Operating Procedure,标准作业程序),并配套对应的工具来降低客户成功经理的执行难度,来确保基础服务质量及客户服务深度,这需要一位客户成功操盘手来完成。
● 二是客户成功经理之间相互补位,形成搭档制度,比如客户成功经理两两搭档,当其中一人没法及时回复客户时,另外一个人能够补上,至少保障基础服务质量。
在业务规模及业务复杂度提升后,就有必要进一步分工,来提升被动服务的专业度及主动服务的深度。
主被动客户成功体系是指将客户成功服务一分为二,将客户主动找我们所做的服务归为“被动服务”,这部分工作主要由客服负责;将我们主动找客户所做的服务归为“主动服务”,这部分工作主要由客户成功经理负责。
● 被动服务的内容包括但不限于客户问题解答、客户投诉处理、客户技术支持等内容,不管是何种渠道产生的这部分内容,都应该由客服来负责。
● 主动服务的内容包括但不限于客户主动跟进及回访、客户实施培训(视情况)、客户方案输出、客户案例打造等。
通过上述定义,就能很清楚地界定双方的工作边界:在线及400电话等被动咨询由客服负责处理,微信或企业微信等IM工具内的被动咨询也可由客服来处理;客户成功经理主要负责主动服务和运营。
这种分工方案的优势在于能够让各自聚焦自己的专业领域,客服部门专注于提升被动服务体验,及时响应、及时解决客户问题,客户成功经理专注于主动服务及提升体验,主动跟进客户使用情况,帮助客户拿到业务结果。
而且当客户规模到一定体量时,分工能够提升人效。客服相对好招聘一些,且人力成本要比客户成功经理便宜。
精细化客户成功体系中,增加了实施和服务中台的角色,分工进一步细化。其中实施岗位一般适用于以下两种情况:
● 一是产品相对复杂或者有一定的技术门槛,如果是客户成功经理来做,那么会占用客户成功经理大量的精力,或者客户成功经理不具备技术等相关能力,这种情况下可以考虑设定单独的实施岗位来负责交付工作,完成实施工作后再交接给客户成功经理。
● 二是产品虽然不复杂,但是客户数量较多,统一安排实施岗位或者培训岗位来做,效率更高,这种情况一般适用于线上运营为主的客户成功体系,通过线上的直播课程或者训练营的方式来做统一的产品交付,能够大幅提升交付效率。
服务中台岗位是指服务运营、客户运营等岗位。一般是到一定体量的客户规模或者产品线后,才会考虑设立服务中台来提效,或者业务复杂且量足够大,需要分工,分工后能比分工前提升效率和质量。
如果服务中台能够推动这些系统的完善,将会大幅提升整个团队的工作效率,也会间接提升客户的体验。
综上,服务中台能做的事情很多,如果能够充分发挥服务中台的价值,就能大大加速客户成功精细化运营的能力,同时降低一线执行要求,降低一线人才要求。
一体化客户成功是服务一体化价值导向下的组织架构,服务一体化是指将客户成功、专业服务、服务支持、客户学习等打包到一起,作为一个整体来给客户提供服务。
当客户有需求或者问题时,客户成功经理能够随时调用相关资源形成合作小组,快速解决客户的问题。
这个组织架构的核心是解决协同效率的问题。在传统模式下,技术支持一般会放在技术部门,而技术部门距离用户太远,不一定能够充分了解客户的应用场景,且技术团队的考核目标和价值导向都不太能够将响应率、解决率等技术服务指标优先级排得很高。
而且技术支持放在技术部门,客户碰到Bug等问题需要技术支持时,客户成功经理需要做跨部门的协同,一旦涉及跨部门,大概率就会存在更高的沟通成本。
因此,将技术支持放到以客户服务体验为考核导向的客户成功体系当中,更能够提升客户问题的响应效率及解决效率,这个是一体化客户成功体系架构的价值所在。
客户成功团队在不同的业务背景及不同的职责目标下,在SaaS公司中会有不同的架构设计。
客户成功团队负责人直接向CEO或者COO汇报,如图2-2所示,这个是比较常见的一种架构设计,也是笔者建议的架构设计。
图2-2 客户成功部门在企业中的架构1
因为客户成功是一把手工程,客户成功战略的落地需要较长的周期才能看到效果,且过程中需要调配产品、研发、销售、市场等部门资源做大量的协同工作,这些工作如果没有CEO或者COO的支持(小公司就必须是CEO的支持),仅仅靠部门负责人是很难有效落地的。
而且这种架构的设计,能够保障客户成功团队和销售团队、市场团队及产研团队平等对话,能够获得更多的话语权,以推动客户成功相关项目的落地。
客户成功团队向销售VP/销售负责人汇报,也是一种相对常见的架构设计,一般在销售驱动型的公司出现较多,如图2-3所示。
图2-3 客户成功部门在企业中的架构2
以下两种情况会采用这种架构设计:
一是客户成功团队和销售团队需要有很强的协同,比如在区域直销团队中,销售人员和客户成功经理需要协同做上门服务,销售人员需要协同客户成功经理做好系统上线工作以便要到更多的转介绍,这个时候区域内的客户成功经理向区域销售负责人汇报(或者双线汇报给区域销售负责人和总部客户成功负责人),能够在一定程度上推进协同工作的落地。
二是在客户成功团队需要自己做续费,且收入压力比较大的情况下,为了让销售VP对总体业绩负责,通常也会考虑让销售VP管理客户成功团队。
在这种架构下,对于销售VP的要求比较高,既需要平衡好售前售后的关系,也需要懂客户成功。
除了以上两种常见的组织架构,也有少部分客户成功团队向运营VP/运营负责人汇报,通过“强运营”来发挥客户成功的价值,如图2-4所示。
图2-4 客户成功部门在企业中的架构3
C端公司基本都配有运营团队,用户运营、产品运营、增长运营等,但SaaS公司很少有运营岗位,最多也就是销售运营,其实从运营的目标来看,按照“AARRR模型”,SaaS的运营和C端增长运营有许多相似之处,如图2-5所示。
图2-5 C端增长运营与SaaS客户成功运营模型
从客户成功的角度来看,新签的收入和自己关系不大,如果把新签获客当作一批初始用户,那么:
● 新签获客就等同于“AARRR模型”中的Acquisition(用户获取),这是客户基数。
● 实施上线(Onboarding)等同于Activation(用户激活),让客户能够开始上手使用系统。
● 北极星指标活跃等同于Retention(用户留存),代表客户活跃使用系统,开始留存下来。
● 续费留存等同于Revenue(用户转化),开始获得收入。
● 转介绍和增购就等同于Referral(用户裂变),转介绍和增购做得好,就有机会做到客户数量多及金额的负流失。
实际上国外不少产品也是通过大量upsales(拓展销售)实现金额负流失,即NDR大于100%的。
因此笔者认为客户成功就相当于SaaS体系中的运营,或者说客户成功部门需要承担起运营的职责,将客户成功工作当作一个产品来运营和设计,能够更高效、更广泛地传递到客户及市场。
所以将客户成功部门放到运营的架构下,或者客户成功部门承担产品运营、用户运营等职责,也是一种相对合理的选择,尤其是针对标准化、轻量化、客单价较低的产品,需要较强的线上运营能力来做批量运营。