惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

有赞技术团队
有赞技术团队
H
Hackread – Cybersecurity News, Data Breaches, AI and More
I
InfoQ
J
Java Code Geeks
Microsoft Security Blog
Microsoft Security Blog
G
Google Developers Blog
D
DataBreaches.Net
Recent Announcements
Recent Announcements
Microsoft Azure Blog
Microsoft Azure Blog
B
Blog RSS Feed
Y
Y Combinator Blog
博客园 - 【当耐特】
博客园 - 聂微东
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
大猫的无限游戏
大猫的无限游戏
P
Proofpoint News Feed
量子位
C
Check Point Blog
F
Fortinet All Blogs
罗磊的独立博客
Last Week in AI
Last Week in AI
GbyAI
GbyAI
L
LangChain Blog
博客园 - 司徒正美

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
改善SaaS企业的收入,是客户成功存在的唯一理由
ToBeSaaS · 2023-07-07 · via 人人都是产品经理

客户成功对一个公司而言,意味着什么?客户成功经理该如何拿下客户,而不仅仅是跟客户打好关系?本篇文章就此类问题展开谈论,希望你能对SaaS企业的CS岗位有更深的了解。

群里有一位CSM私信我,说他们公司最近裁掉了一部分CSM,他也在其中。他说裁员能理解,毕竟公司经营情况不好,压缩成本也是必须的。但是作为每年受到客户表扬的CSM,被裁员还是感到非常委屈。

我向他公司CS负责人了解情况时,这位负责人说:裁掉的这些CSM,是因为他们没有业绩。他们工作确实很努力,还收到过客户发来的感谢信,但恰恰是这些客户,最后都没有续费。

我理解这位负责人所说的“业绩”,其实就是客户成功的量化收入。这位CS负责人说的没错,如果CSM的工作不能为公司增加营收,那公司为什么还要花这么大的成本留用他们?

一、无法改善营收的CS组织,没有存在的必要

对于这个原则,很多CSM难以接受。帮助客户使用好产品、让客户高兴、提高他们的满意度,难道这些工作不能提高续费率?

这还真不好说。退一步讲,即使这些工作提升了续费率,但也没法证明是CSM的功劳。如果深究CSM的每项工作和动作,就会发现它们与收入并没有直接对应的因果关系。

很多CS组织的作用,就是这样说不清、也道不明。很多CSM习以为常地认为:只要服务好客户,就可以心安理得地在公司待下去。

实际上,这样的CS时代早就过去了。除了“改善营收”这个理由之外,其它的都不能称其为CS存在的理由。

不管你是否同意这个观点,公司最后都会做出这样的决策。

二、大多数公司因CS,每年至少损失30%的收入

在上一次“客户成功,改善营收”主题分享会上,有人问我:为什么不使用“增加营收”,而要说“改善营收”呢。

的确,海外SaaS企业的客户成功,都使用“增加”或“增长”一词来描述营收。但对于国内大部分SaaS公司来说,用“改善”来描述可能更符合逻辑。也就是客户成功先把该做的事做对,阻止不该发生的流失。然后再谈增加和增长的问题。

实际上,国内很大一部分SaaS公司,就是因为客户成功的低效能,每年流失掉至少30%的续费和增购的收入。

这个推断其实很简单,如果一家公司的ARR与前一年持平或者略有增长,粗略估算也能算清楚,流失掉的留存收入其实远不止30%。这个损失其实很大,因为留存和增购收入,几乎是净利。

它们本不该发生的。

三、“服务好客户”的说法,在SaaS行业可能是错的

我参加过无数次的CS团队内部会议,大部分都是围绕“怎样服务好客户”这个主题。为什么一定要服务好客户呢?最诚实的回答是:催收续费时才可能要来钱。

这个逻辑在消费服务领域绝对正确,比如海底捞。投入全部热情、用尽一切办法,因服务好而感动客户,毫不犹豫地买买买。

然而不幸的是,这个逻辑在SaaS行业基本不成立。也就是说,如果没有帮助客户实现预期的成果(Required Outcomes,RO),客户并不会因为“服务好”就买单。

不过也请不要误会,我这样说的目的,也不是让你与客户对着干。热情和专业服务,本身就是CSM的基本职业素养,但是这跟收入没太大关系。

实际上,除了热情服务以外,在客户成功领域,还有很多改善营收的业务方法。比如:销售-CSM的客户转交、Onboarding、Adoption、TTV(Time to Value)等业务环节和节点,都有防止流失和发现增购机会的措施和方法。

不过,所有的措施和行动,以及要做的每一件事,都必须围绕收入设计;而续费和增购只是这些行动的结果。

衡量CS的绩效也离不开KPI,但CS的KPI同样也必须围绕改善收入机会设置。除了NRR、续约率和增购等常规指标以外,像采用率、发现增购机会数、挽留率等,也可以作为考量的行为指标。以使CSM的所有行为,都指向“改善营收”这一目的。

如果说CSM有一件事是必须做的,那就是帮助客户获得预期的业务成果。这件事其实也不简单,因为你得知道客户的预期成果是什么。

四、如何让CS组织,成为公司的利润中心

由于SaaS业务的订阅特点,客户的生命周期可以很长,也可以很短(这里指的是客户自然的生命周期,不包括多年合同、买一年送一年的人为延长)。

这基本取决于对客户的成功旅程设计和CS的执行。

尽管客户行业不同、产品种类不同、业务的复杂度不同,但对于CS业务来说,有一个基本的准则,即:在旅程中恰当的触点,配置正确的CS资源,以最经济的方式,提供最合适体验,最终达成客户最想要的成果。

这个原则看起来很简单,其实不然。其中的每一项内容,都需要精细化的设计、搭建和管理。也只有这样做,客户成功部门才可能成为公司的利润中心。

作者:戴珂;公众号:ToBeSaaS

本文由@ToBeSaaS 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。