所有文章
减少流失

如何减少SaaS流失:实用指南

2026年6月6日阅读时间:9分钟
取消页面、匹配的保存优惠和主题图表,作为减少流失循环的三个步骤

大多数关于减少 SaaS 客户流失的文章都是针对那些有专人负责客户流失的公司。健康评分、CSM 操作手册、季度业务评审。如果你是通过 Stripe 或 Lemon Squeezy 计费的两人团队,以上内容今年都不适用于你。

这是另一种版本。它假设没有专门的留存功能,没有分析师,并且只需一周的努力。下面的所有内容都是你可以自己构建的机制,其中包括实际的 API 调用(在需要的地方)和需要跳过的事项列表。

首先,确定这是否是你最大的难题

在花一周时间处理流失问题之前,先花十分钟做算术。流失计算器可以进行这种重要的数学计算,即你当前的流失率在一年内的成本,以及部分恢复的价值。

Outro流失计算器显示MRR输入为一万二千美元,月流失率输入为百分之四,下面计算出每月损失的收入、每年损失的收入和每年可恢复的收入

在$12,000 MRR和4%的月流失率下,它报告每月损失$480,每年损失$5,760,如果你挽回四分之一尝试取消的客户,每年可恢复$1,440。工具明确表示这是一个粗略估计,假设MRR大致稳定,所以要看大致趋势而不是精确度。每月的数字看起来可以承受,而每年的数字通常不行,这就是为什么流失问题月复一月地被推迟。

首先运行你自己的数据。如果每年的数字小于你一周的时间成本,那就去构建功能吧。

在你开始之前,有两个测量注意事项:

  • 跟踪收入流失,而不仅仅是客户流失 : 失去十个$10的账户和失去一个$1,000的账户都是流失,但不是同一个问题。如果你只计算标志,你最大的损失会隐藏在你最小的数字中。
  • 按群组年龄分段 : 在第一个月取消的客户从未真正入驻,而在第十四个月取消的客户是因为他们的需求发生了变化。平均这些数据会产生一个没有意义的比率。

第一天:区分自愿流失和非自愿流失

这是最重要的区分,也是大多数小团队忽略的。

非自愿流失 是由于支付失败导致的。过期的卡片、资金不足、银行拒绝跨境收费。客户从未决定离开,甚至可能不知道他们已经离开。

自愿流失 是客户故意点击取消。

这些需要不同的机制,没有单一工具可以同时覆盖两者。包括 Outro 在内的取消流程,根本无法触及非自愿流失,因为没有取消事件可以拦截。没有人点击任何东西。订阅只是停止支付。

因此,请使用您的计费提供商的功能来处理。Stripe 提供收入恢复,包括重试计划和卡片更新邮件,Lemon Squeezy 在其结账流程中处理催款。启用这些功能,验证邮件从您控制的域名发送,然后将非自愿流失放在一边。这是一个配置问题,而不是产品问题,这使得它成为这里最便宜的解决方案。

本周剩下的时间将处理自愿流失。

第2天:用文字而非类别捕捉原因

你无法减少你不理解的流失,而理解流失的标准工具是一个有五个选项的下拉菜单。这个下拉菜单会对你撒谎,一贯地并且只有一个方向。

下拉菜单要求客户将情境中的挫折压缩成你的词汇,而“太贵了”是社会上可接受的选项,所以它吸收了附近的一切。真正的价格敏感性,“我从未完成设置”,“我需要的功能缺失”,以及“我的预算被削减”都以同一个词出现,而它们需要四种不同的回应。

所以在客户取消的那一刻,用他们自己的话询问,那是他们既最诚实又仍然在技术上是你的客户的唯一时刻。

一个品牌化的取消页面,顶部有简短的道歉,显示单选按钮取消原因、一个可选的电子邮件字段,以及一个显著的选项以录制语音答案而不是输入答案

注意结构化的原因仍然存在,因为它们不花成本并且使汇总报告变得简单。改变数据质量的是旁边的录音选项,以及跳过选项保持可见的事实。在取消时要求回答的问题会产生不情愿的耸肩答案。

如果你自己编写问题,有一套退出调查问题和模板值得借鉴,而关于退出时语音优于文本的理由解释了为什么语音答案会更长更具体。

无论你构建什么,将自由形式的答案分类为一个小的固定分类法,以便你可以统计它们。Outro 使用七个桶,这个列表也是自制版本的合理起点,因为每个都对应一个明确的回应。这些是确切的标识符,如果你在 CSV 导出上构建自动化,它们很重要:

  • too_expensive : 异议是预算或性价比。
  • missing_features : 能力差距阻碍了他们雇佣你的工作。
  • not_using : 使用率低,不再需要,或只是被遗忘。
  • too_complex : 入门或界面摩擦,有时在第一周是致命的。
  • technical_issues : 错误、故障、某些东西坏了并且一直坏着。
  • switching : 竞争对手赢了,最具商业价值的答案需要准确记录。
  • other : 没有明确的产品原因,包括无法理解的答案或超出这些类别的事情,例如业务关闭。

最后一个桶值得其位置。没有它,被迫在六个中选择的分类器会将真正无法分类的答案推入最不糟糕的桶中,而你会将结果视为信号。

七个桶就足够了。十五个意味着你永远不会有足够的每桶响应来对任何一个采取行动。

第三天:构建四种优惠,而不是一种

一旦你知道原因,就要针对该原因做出回应。向所有人展示统一的折扣是默认选项,因为它简单,但会造成实际损害,因为它教会客户威胁离开是获得更低价格的方法,并且破坏了你区分价格敏感客户和学会这个技巧的人的能力。

四种优惠涵盖了上面的多数分类,以下是每种优惠的实施成本。

在取消过程中显示的保存优惠界面,提供三个月五折的限时优惠,带有一个主要接受按钮和一个纯文本链接,写着不,谢谢,还是取消

无论使用什么工具,其中两个细节都值得借鉴。优惠是限时的而不是开放式的,因此具有已知成本和自然的审查点。而拒绝路径是直接在下面的纯文本,而不是隐藏在第二个确认后面,因为决心离开的人无论如何都会离开,唯一剩下的变量是他们之后如何描述你。如果你想要并排查看模式,可以参考更广泛的取消流程示例

暂停,针对 not_using Stripe 支持暂停通过 pause_collection,这使得订阅保持活跃状态,同时停止开票。

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

await stripe.subscriptions.update(subscriptionId, {
  pause_collection: {
    behavior: 'void',
    resumes_at: Math.floor(Date.parse('2026-11-01') / 1000),
  },
});

在此代码中,你将 behavior 设置为 void,以便在暂停期间生成的发票被作废而不是稍后收取,并将 resumes_at 设置为 Unix 时间戳,以确定计费应重新开始的日期。密钥来自环境,而不是源代码。客户保留他们的数据,你保留一个无需重新注册决策即可重新启动的关系。暂停是递延收入而不是保存的收入,有些从未恢复,因此要单独报告。它仍然比取消好,因为暂停的客户可以被提醒,而取消的客户必须重新获取。

折扣,针对 too_expensive 同样是一个 subscriptions.update 调用,传递 discountscoupon,使用你预先创建的优惠券。

await stripe.subscriptions.update(subscriptionId, {
  discounts: [{ coupon: process.env.STRIPE_SAVE_COUPON_ID }],
});

上面的代码将现有优惠券附加到活动订阅,因此只需创建一次优惠券,设置固定期限,并通过配置中的 ID 引用它。每次取消时动态创建优惠券会留下大量无法审计的单次折扣对象。

降级,针对“这个计划超出了我目前的需求”。 订阅项的价格交换。

const sub = await stripe.subscriptions.retrieve(subscriptionId);

await stripe.subscriptions.update(subscriptionId, {
  items: [{ id: sub.items.data[0].id, price: process.env.STRIPE_PRICE_STARTER }],
  proration_behavior: 'create_prorations',
});

在此代码中,你检索订阅以获取现有项目 ID,然后将该项目的价格换成较低的等级。将 proration_behavior 设置为 create_prorations 可以保持算术的准确性,而不是默默地赠送或双重收费剩余的期间。降级将总损失转化为部分保留收入,这就是为什么它应该出现在取消屏幕上,而不仅仅是在账户设置中。

在 Lemon Squeezy 上,预期会有一个差距。 订阅更改通过 PATCH /v1/subscriptions/:id 进行,且请求必须使用 JSON API 内容类型,否则将被拒绝。

curl -X PATCH "https://api.lemonsqueezy.com/v1/subscriptions/$LS_SUBSCRIPTION_ID" \
  -H "Authorization: Bearer $LEMONSQUEEZY_API_KEY" \
  -H "Content-Type: application/vnd.api+json" \
  -H "Accept: application/vnd.api+json" \
  -d "{\"data\":{\"type\":\"subscriptions\",\"id\":\"$LS_SUBSCRIPTION_ID\",\"attributes\":{\"variant_id\":$LS_TARGET_VARIANT_ID}}}"

上面的代码通过将订阅指向不同的变体来降级,API 密钥和两个 ID 都从环境变量中读取。需要注意的头是 Content-Type: application/vnd.api+json,因为普通的 application/json 请求在此端点会失败。暂停与不同属性在同一端点上,记录在 Lemon Squeezy 订阅 API 中。折扣不在,因为 Lemon Squeezy API 无法对现有订阅应用折扣,因此在此提供折扣需要手动步骤和跟踪承诺直到兑现的东西。

第四天:在开始计数之前,诚实地定义一次挽留

这一步将保留系统与让你感觉良好的数字区分开来。如果你在有人点击“保留我的订阅”时就立即计数,那么你的挽留率看起来会很出色,但意义不大。有些客户两天后就取消了,有些则接受折扣后在折扣到期时立即流失。

Outro 只有在 14 天宽限期后,并且订阅在此期间仍然有效时才计数一次挽留。对你的实现也要保持同样的标准。这只是几行逻辑和一次对账单提供商的延迟检查,但这就是知道你的恢复率和猜测之间的区别。

收入恢复页面显示“连接支付提供商”空状态,因为此账户没有链接账单提供商,以及等待手动应用的已接受报价列表

该截图来自一个测试账户,所以请根据结构而非结果来阅读。它显示了“连接支付提供商”空状态,因为没有链接提供商,还有等待手动应用的已接受报价队列。队列是需要内化的部分。一个从未到达账单系统的已接受报价比没有报价更糟糕,因为你在客户决定是否再次信任你的关键时刻做出了承诺却未能兑现。

第五天:养成每周一个习惯,然后停止

流失工作更多是因为野心而不是忽视而失败。不要构建一个你只会检查两次的仪表板。构建一个每周五分钟的回顾。

Outro 会发送一封周一摘要邮件,涵盖谁离开了以及原因、面临风险的 MRR、挽救的 MRR、主要原因以及优惠的表现。如果你自己动手做,这个列表就是每周 cron 任务的合适范围。摘要优于仪表板,因为无论你是否记得它的存在,它都会到达。

数据积累后的样子

这个循环的输出不是一种感觉,而是一个可以交给特定人员的排名列表。

Outro insights 视图中的一个主题柱状图,显示取消是最大的柱子,其次是定价、成本、预算、团队规模、产品质量、missing features 和用户反馈

这些柱子是从十六个记录的退出访谈中提取的真实主题,取消 7 次,定价 6 次,成本 3 次,预算 2 次,团队规模 2 次,产品质量 2 次,missing features 2 次,用户反馈 2 次。有一个需要注意的地方,这是一个测试账户上的十六个响应,因此将排序视为示例,忽略通过它绘制的任何趋势线的形状。一个真实的账户会在几个月内积累这些数据。

每个响应的摘要是行动的所在。该运行中的两个真实例子是:“用户表达了对定价的担忧,这对他们的小团队来说是一个重大问题。”和“用户在设置过程中感到困惑,并在小部件嵌入和优惠配置上遇到了困难。”

看看每个问题的指向。第一个是定价层级问题,很可能是对非常小的团队来说跳跃过大,所以它交给负责定价页面的人。第二个是入职问题,涉及两个命名步骤,所以它交给产品团队。两者都不是“减少流失”。两者都是某人本周可以完成的任务,这就是整个练习的价值所在。关于声明的原因和真实原因为何不同,请参见为什么 SaaS 客户取消

常见错误

在兑现优惠时信任客户端参数。 如果你的流程重定向回你的应用程序,并带有类似 ?outro_offer=discount 的参数,该参数来自浏览器,任何人都可以输入。在应用任何东西之前,请在服务器端验证这个客户根据你自己的记录确实处于取消中,并限制给定优惠可以兑换的次数。这很容易被忽视,因为顺利的路径工作正常。

将自愿和非自愿流失平均在一起。 你最终会通过产品更改来解决卡片过期问题,或者通过重试逻辑来解决产品问题。

在你自己的数据收集上阻止取消。 如果转录、分类或优惠查询很慢,取消仍然必须完成。了解某人离开的原因是你的问题,而不是他们的。

向告诉你缺少功能的人提供折扣。 优惠券不会增加功能。它将一个明确的产品信号转换为较小的发票,并购买同样对话的另一个月。

在阅读答案之前构建优惠。 先设计优惠的团队是为他们假设占主导地位的原因而构建的。录音通常不同意。捕获两到三周,然后再决定。

本手册故意省略的内容

  • Failed-payment recovery : 由您的计费提供商处理,而不是通过取消流程。Outro 不进行催款。
  • Health scores and usage-based churn prediction : 在某个规模上有用,可以有人处理每日警报列表。低于该规模,警报会堆积而无人阅读。
  • Deep integration plumbing : Outro 当前的输出是每周摘要加上 CSV 导出。没有公共 REST API,没有 webhooks,没有 npm 包,也没有 Zapier, Make, n8n 或 Slack 集成,所以如果您的计划依赖于自动将取消事件传输到其他地方,请计划使用 CSV。
  • Win-back campaigns : 一个真实的策略,也是一个单独的项目。先进行退出,因为它会告诉您赢回邮件应该说些什么。

简短版本

将非自愿流失分离出来,让你的计费提供商处理它。在取消时刻问一个问题,让人们用自己的话回答。分类成一个小的固定分类法。构建四个理由匹配的优惠,使用暂停、折扣、降级和诚实的拒绝。只有在宽限期后才计算为挽留。每周阅读一次摘要。这就是整个流程,如果你不对任何一个步骤进行过度优化,它可以在一周内完成。

Outro 是我们自己构建和运行的版本,一个用于 Stripe 或 Lemon Squeezy 的自助服务 SaaS 的取消流程,包含语音退出访谈,AI 分类和理由匹配的优惠在取消完成前应用。计划为每月 $0、$29、$79 和 $199。上面的每个截图都是实际产品而非模型,包括收入恢复页面的空状态,且流失计算器无需账户即可免费使用。

了解客户真正取消的原因

Outro在您的取消页面上捕捉语音退出访谈,使用AI检测真实原因,并显示最有可能挽留客户的优惠。

开始免费试用