越来越多SaaS企业开始重视起了客户成功部门，然而由于业内可借鉴的模式相对较少，以及部门定位模糊等原因，部分SaaS企业的客户成功部门运行并不如预期。那么，客户成功究竟要如何做好，并实现“准快狠”？一起来看看作者的分析和总结。
很多互联网公司都开始意识到，“小而轻”的SaaS产品，似乎更符合“后疫情时代”的互联网市场。
一来客户的消费能力降低，并且经过三年的疫情，消费也变得更加谨慎；二来作为公司层面，“小而轻”的SaaS产品，似乎能够让自己快速进场、快速离场，变得更加主动了。
所以说，越来越多的SaaS公司，开始重视客户成功这个部门。但根据笔者三年的从业经历，以及对其他公司客户成功部门的了解，大部分公司的客户成功部门，似乎做得并不好。
不好的地方主要体现在以下三个方面：
所以这篇文章，笔者就浅谈一下关于客户成功部门，如何把工作做到“准快狠”。
可以给大家分享一个在职场中比较实用的思维模式，尤其是在从0到1搭建一个部门或者一套体系，笔者会觉得非常实用：
部门（某个任务）的定位（目的）是什么——想要达到的关键指标是什么——想到达成关键指标，需要什么样的核心动作。
当然，这套思路还可以继续往下延伸。比如对应的核心动作要怎样考核、考核的指标和绩效占比应该怎样设置。这就涉及到岗位的绩效考核问题了，本文就不多做赘述。
回到客户成功部门上面来，笔者聊聊自己的看法：
只有当这些最底层的问题想清楚了，后面的工作才能更好的开展。
在详细说明客户成功应该如何把工作做实之前，笔者还想再聊两个问题：一是客户成功的四个层次；二是大多数SaaS公司存在的误区。
怎么样才算一个优秀的客户成功经理？首先要搞清楚，究竟该怎么分阶段去进阶。
在笔者看来，客户成功的四个层次分别是：售后——需求管理——业务流程梳理——行业顾问。
很多客户成功经理，其实会在很长一段时间内，都被困在这个阶段。
当然，初次与客户建联，帮客户解决售后问题，无疑是一个非常好的机会。但同一个客户成功经理，往往对接的是好几百家客户，当所有的售后都集中在你身上时，你会觉得疲倦。一来售后量太大，二来你无法真正体会到客户成功的价值。
所以当与客户建联到一定周期，一定要学会把售后问题推给公司真正的线上售后部门。当然笔者也能够理解，很多客户成功经理不愿意把售后交出去的原因，很大部分是因为客户的转介绍，希望能够牢牢拽在自己手里
这个其实涉及到部门利益划分的问题。理想状态当然是希望售后全交出去，然后客户的转介绍全部给到自己。当然这是不现实的，我们应该要做好会有部分客户转介绍到其他人手里的准备。
当然，如果你把客户成功做到更高层次，给客户带来更高的价值，客户肯定还是更倾向把转介绍给你。
关于客户的需求管理，可能大部分人觉得这是产研部门负责的事。但真正要做好客户成功，想要给客户带来更大的价值，需求管理必须得做好。
客户成功是更贴近客户的，对于客户的需求、场景能够了解得更清楚。尤其是对于有相同需求的客户，可以着重把这些需求拎出来给到产研部门，一般涉及客户比较多的需求，产研都会放在更高优先级去做。
还有一点优势在于，客户成功可以快速找到产研，了解客户需求的进度，然后再反过来同步给客户。对客户而言，只要不影响他正常基本的使用，需求做不做不重要，重要的是得实时向客户同步。这个体验客户成功往往很容易忽略掉。
客户刚开始使用软件，往往只是使用最基础的功能。即使在最初实施培训过程中，我们严格按照流程给客户做培训，但绝大部分客户还是会自然而然地先使用最基础的功能。
这其实和培训的人没有太大关系。只是在实施交付的时候，公司往往会制定一个实施交付的周期。周期拖的太长，在效率、成本上都是一个负担。
而对于客户而言，能够按软件流程使用绝大部分功能，周期往往至少在三个月。公司的实施人员不可能寸步不离地跟着客户三个月，所以这个时候客户成功的价值就该体现出来了。
在前1~2个月，确保客户的基本使用没有问题之后，再根据客户的实际业务，去针对性地做其他功能的引导和培训。
但是切忌，不要一味地“强迫”客户全部功能都使用，只引导和培训对客户有价值的功能。
当客户成功真正做好上面三点之后，客户自然而然地有业务上的问题就找你咨询。
到了这个阶段，往往不需要你花太多的精力去找客户聊软件了，更多的应该去丰富自己的行业知识储备。充分了解行业的各个流程、潜规则，并且还要真正地去思考如何通过软件去实现。
客户在选择产品时，往往就是出于“降本增效”。只要这两点价值真正让客户体会到，粘性、续约都是水到渠成的事情。
在笔者看来，客户成功的误区（或者说是SaaS公司的误区），往往都是他们长期围绕执行且不自知的。
不管是创业型公司还是大型公司，其实往往都会陷入一个误区，盲目抓“增长”。
创业型公司好理解，为了尽快争夺市场占有率、更快生存，所以把资源全部倾斜在业务部门；而大型公司，尤其是手握巨头融资的，在“增长”的同时，还会打“价格仗”撬竞品。
当然并不是说不应该去抓“增长”，只是有些矫枉过正了。打个最简单的比喻：一个底部破烂的袋子，不断地往里面装东西，不管你装东西的速度再快、装的东西再多，还是会在底部源源不断地漏下来。
客户成功的本身就是一个漏斗模型：客户新签——培训交付——全生命周期管理——续费/流失。
新签的入口，这个交给公司的业务团队。而客户成功真正要做的，就是把流失这个出口不断缩紧。
“让客户把软件全流程使用起来。”这句话想必各位客户成功经理并不陌生。
因为在我们常规的认知里面，客户把软件全流程使用起来，意味着客户的粘性增加、后期的迁移成本升高，所以会一直续约。
乍一听，好像听起来是那么回事，完全没有问题。而且想必大多数公司也是这么做的，并且客户的健康度也是通过不同功能的使用占比进行计算的。
同样打个比方。学生时期的“五好学生”是哪“五好”，大家应该都知道吧。“德”、“智”、“体”、“美”、“劳”。但是大家回想一下，期末能够拿到这个荣誉的，是否这五个方面都是出众的？
想必绝大部分还是看最后的期末成绩吧，也就是“智”这一个方面。而且好多“五好学生”获得者，往往有一两项是完全缺失的，但这并不妨碍他们对于这项荣誉的强有力竞争。
所以说，如何判断客户是否健康，往往还是看是否满足了最日常、最基本的需要。
前两天和一位前辈吃饭，他以前是产品总监，现在辞职开起了饭店。当时就聊到了SaaS产品相关的话题。他现在的饭店也在用一款SaaS收银系统，我当时问他，在什么情况下，你会一直续约这款产品？或者换句话说，什么情况下，你会选择弃用这款产品？
我记得前辈的原话是这样的，“我现在的需求只有两个：一是点餐出票；二是扫码付款。只要它能够满足我日常的需要，并且年费的价格不超出我的预期，我就会一直用下去，并且可以做到永远不找他们的售后。”
发现没有，从前辈的这段话里面，可以提炼出两个核心点——“满足日常需要”、“年费价格不超出预期”。
当然，后面前辈也提到了另一个核心点——“品牌”。就是在上面两个点都符合的前提下，肯定会选择相对有名的产品。
后面前辈补充说，“当然，它还有什么会员、报表这些功能，其实对我来说并不核心，它如果免费开放，我就偶尔使用。当然，没有也无所谓。”
所以，在我们成交客户的时候，就应该提前了解他目前最核心、最日常的点，然后前期就针对这些点做功能培训。
后期再通过了解，是否有些线下的业务流程没有实现线上化，那就再做引导。如果没有，就不用强迫。“强迫感”对于客户来说，也是一种不好的使用体验。
不管什么规模、哪个行业的SaaS公司，回归到本质，都是做产品的公司。而产品最重要的三个点：成本、质量、服务。
产品“成本”其实涉及到了公司的定价策略，这个客户成功部门无法给出太好的建议。但是“质量”和“服务”客户成功就有很大的话语权了。
“质量”其实就是关系到是否满足客户日常的需要。如果不满足（产品设计逻辑错误、使用体验不好），那就直接反馈给产研部门，迅速做出调整和优化。
“服务”分为线上和线下两部分。线上的售后客服，要做到快速响应、精准答疑；线下的客户成功，要做到深度建联、引导使用。这部分其实又涉及到售后部门、客户成功部门搭建和日常SOP了，这个先不展开聊。
笔者很多时候都在想，客户成功的核心竞争力究竟在哪里？
续费？似乎大部分客户只要使用得还行，就会自主续费了；培训？似乎销售也能做；客户分层管理？这个东西太虚了，而且该怎么管理，似乎一直处于摸索阶段。
也是和前辈吃饭的时候，突然讨论到一个点，不一定对，但是至少可以展示客户成功的核心竞争力，那就是“流失激活”。
一家SaaS公司，一定会有一批已经流失的客户，并且体量还不小。这些客户就像一个烂摊子，大家都不愿意碰，偶尔有流失客户找上门来，那就再去做激活动作。
不可否认，流失激活往往比新签更难。因为弃用的客户，可能受到过“伤害”，不管是主观还是客观原因。所以再去做重启激活，难度是呈指数增长的。
但这就是最能体现客户成功核心竞争力的地方。产品层面有比销售人员更专业的视角，沟通层面有比产研人员更强的业务能力。
很多人可能会担心，死磕“流失激活”会不会影响其他的工作？其实不会。做过客户成功的应该都清楚，正常在使用的客户，往往占了大部分，这部分客户，做好平时的售后基本就可以了。剩下的新签客户、到期续费客户可能需要费点心，但绝对还有足够的时间和精力去顾及到流失客户。
当然，公司层面对于“流失激活”的奖励政策也应该给足，“重赏之下，必有勇夫”，说的就是这个道理。
至于“流失激活”的方法论，就是一家一家死磕，碰到相同原因流失的客户，用相同的方法激活。
如果一个有难度且没人愿意做的工作，员工一上来就要方法论，要么就是不愿意去做的说辞，要么就是对应的激励没给到位。
讲了这么多，那么客户成功究竟如何做到“准快狠”呢？
所以，客户成功就是在保证客户全生命周期、公司营收的前提下，对“留存”和“激活”快速响应并执行，死磕到底。
本文由 @温艾沃 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。