为什么 SaaS 客户真的取消（以及如何找出原因）

以下是一位真实测试者在取消流程中说的一句话。

“价格确实是我们的问题所在，我们是一个三人团队，而下一个等级的费用超过了我们整个季度的工具预算。”

现在来看一下下拉菜单会从同一个人那里记录下什么。太贵。 两个词，一行电子表格，所有可操作的细节都消失了。

这句话并不是在抱怨你的价格。它是在抱怨你的两个等级之间的跳跃幅度，从一个三人团队的角度来看，他们不适合更高的等级。这是一个定价页面的问题。下拉菜单的答案，“太贵”，反而指向了折扣，这是错误且昂贵的解决方案。同一个客户，同一个原因代码，却得出了相反的结论。

本文围绕Outro将取消分类为的七个原因类别进行组织。分类法故意保持小而固定，因为小而固定的集合才使计数成为可能。论点是，只有当它们下面的某些东西保留了客户实际说的话时，这些类别才变得有用。

七个原因，以及每个原因实际隐藏的内容

Outro 将每个取消归类为七个原因之一。这个集合不会改变，你也无法配置它。

• 太贵 : 客户告诉你的是关于价格的事情，但几乎从来不是绝对数字。通常是层级之间的差距、被削减的预算，或是使用量下降后感觉合适的价格。记录为一个类别时，它看起来像是一个问题。记录为一句话时，它分裂成三个，且有三个不同的负责人。
• 缺少功能 : 关键字是哪些。一个阻碍整个工作流程的缺失集成是一个路线图决策。一次出现的可有可无的功能是噪音。类别将它们视为相同。
• 不使用 : 没有人因你的产品受到伤害，他们只是从未将其融入他们的每周计划中。这是客户最没有动机主动提供的原因，也是最有动机报告为“太贵”的原因，因为为从未打开的东西付费确实感觉过高。
• 太难使用 : 在客户获得价值之前就被阻碍的摩擦。设置、配置、你的用户界面中的概念与他们头脑中的概念不匹配。与“不使用”不同，因为这里他们尝试过。
• 技术问题 : 错误、故障、破坏信任的事情。最容易修复的类别，也是最值得逐字阅读的，因为你需要的是重现路径，而不是数量。
• 切换 : 他们去了别的地方。这个类别本身几乎没有用。他们去了哪里，是什么吸引了他们，是整个信号。
• 其他 : 没有明确的产品原因，包括无法理解的答案或确实不属于其他六个的事情，例如业务关闭。一个没有这个桶的分类法比有这个桶的更糟糕，因为被迫选择的分类器会将噪音归入最不合适的真实原因。

底层值存储为标识符而不是上面的显示标签，它们并不总是与标签的读法一致。完整集合是 too_expensive，missing_features，not_using，too_complex，technical_issues，switching 和 other，所以“太难使用”作为 too_complex 出现，“不使用”作为 not_using 出现。在你基于 CSV 导出构建报告之前值得了解。

注意，六个真实原因中的四个可以合理地被客户报告为第一个。这种不对称是下拉菜单的整个问题，它预测了复选框调查会因为与价格无关的原因而偏向价格。

为什么“太贵”涵盖了其他所有问题

一个下拉菜单要求客户为你翻译。他们有一个具体的情况，而你给他们五个预定义的选项，并要求他们选择最接近的一个。这是一个有损压缩步骤，客户没有动力仔细去做，因为他们要离开了。

他们选择的选项是社会上可以接受的。说“太贵”对客户没有任何成本，因为这不意味着对产品的批评，也不承认他们从未设置过，也没有解释的义务。与点击“太难用”相比，这听起来像是一种指责，或者“没有使用它”，这听起来像是一种承认。在有选择的情况下，人们会绕过那些尴尬的选项。

因此，“太贵”悄然涵盖了至少三个不相关的情况，包括“我从未设置过”，“我需要的那个功能缺失”，以及“我的预算被削减”。这三种情况需要你完全不同的回应。合并到一个类别中，它们平均成一个建议：降低价格，而这对它们中的任何一个都没有帮助。

Outro 的取消页面保留了单选按钮，并在旁边添加了语音选项，这是一个故意的妥协，而不是纯粹主义的立场。按钮为每个取消提供了一个类别，包括那些不愿意说话的客户。语音回答为那些愿意说话的客户提供了类别背后的句子。

在机械上，它是一个替代取消按钮的简短口头问题。答案在到达时被转录和分类，并在取消完成之前出现匹配的报价。录音是即时转录的，而不是作为可播放的音频文件保存，尽管转录和从中得出的分析像任何其他客户记录一样被存储，页面在录音前显示“您的语音将由 AI 转录”这行字。该同意行是固定的，不可配置，这是捕捉客户在关系中最不慷慨时刻的声音的正确默认设置。有关格式的更广泛的看法，请参见AI 退出面谈。

实际输出中的原因是什么样的

下面是一次实际运行中的“需要注意”面板。每个摘要都是从实际的口头响应中生成的。

将这三个摘要视为分类法的实例，而不是散文。

“用户表达了对定价的担忧，认为这是他们小团队的一个重大问题”是从本文开头的口头句子生成的摘要。它属于价格类别，并带有重要的限定词，即对于他们的小团队。下拉菜单会给出删除限定词后的类别。

“用户遇到了仪表板无法加载的错误和支持响应缓慢的问题，影响了他们的信心”是一个technical issues案例，指出了两个独立的故障。一个是错误，一个是支持延迟问题，它们属于你团队中的不同人员。单一的原因代码会迫使客户放弃其中一个。

“用户在设置过程中感到困惑，并在小部件嵌入和优惠配置上遇到了困难”是一个too-hard-to-use案例，固定在特定步骤上。不是“产品令人困惑”，而是在设置过程中，特别是在嵌入和优惠配置方面的困惑。这是你今天下午可以打开的工单。

这三者都无法从一个复选框中重构出来，而这三者之间的区别在于了解你的流失率和知道需要改变什么。

原因分类和反馈分类是两回事

这常常让人困惑，所以要将两者分开。Outro 对每个响应运行两个独立的分类系统。

第一个是上面提到的七值流失分类法，用于回答订阅为何结束。第二个是反馈分类，包括 Bug report, Feature request, Praise, Question 和 Other，用于回答这是什么类型的信息。此外，每个响应还带有 Positive, Neutral 或 Negative 的情感。

这两个系统不会相互合并。Bug report 自然与 technical issues 相关，但如果这个 bug 是他们两个月前停止使用产品的原因，它也可以归入 "not using it"。Feature request 可能会与价格原因一起出现，因为 "我需要的功能所在的层级太贵了" 确实是两者兼有。

最近响应表是这两个系统并排展示的地方。一起查看情感和分类标签，而不是逐个查看，因为组合信息比单独的列更具信息量。带有 Neutral 情感的 Feature request 是路线图的输入。带有 Negative 情感的相同请求则是一个感到被忽视的客户，这是一个不同的对话，通常是可以挽回的。

主题将类别转化为优先级列表

类别告诉你客户流失的分布情况。主题告诉你周一该做什么。Outro 提取各个响应中的主题并进行计数。

这些是该运行的实际计数，取消为 7，定价为 6，成本为 3，预算为 2，团队规模为 2，产品质量为 2，missing features 为 2，用户反馈为 2。

要明确这是什么以及不是什么。这是一个测试账户上的十六个响应，九个口述和七个键入。计数是真实的，主题提取也是真实的，但十六个响应无法告诉你定价投诉是否在增加，而图表仍会自信地画出一条斜线。明确说明这一点比斜线更有用，如果你正在评估任何客户流失工具，样本量是需要最严格审查的声明。

计数所展示的是机制。定价、成本、预算和团队规模作为四个独立的主题出现，而不是一个。下拉菜单会将这四个合并为“too expensive”。分开后，它们读起来像是关于小团队面临陡峭层级跳跃的连贯故事，这正是原始口述句子所说的。主题恢复了类别所破坏的结构。一旦你有了这个，减少流失就变成了一个修复的优先级列表，而不是猜测，你可以用churn calculator为每个修复的价值量化。

将优惠与原因匹配而不是与点击匹配

在取消时了解原因，而不是一周后在报告中得知，这意味着优惠可以对此作出响应。在上面的运行中，价格异议后提供的优惠是“3个月50%折扣”。

在该界面上有两点需要注意。优惠出现在取消完成之前，此时离开的意图仍然不强。而“不了，谢谢，仍然取消”保持可见且简单。通过隐藏退出获得的任何提升都会以退款、支持负担和公开投诉的形式回归。取消流程示例涵盖了该行在实践中的位置。

恢复是保守计算的。只有在14天宽限期过后，并且订阅在那时仍然有效的情况下，才算作一次挽救。接受折扣并在一周后取消的客户不算作挽救，数字也不会假装如此。另一种方法是计算优惠的点击，这会产生一个看似令人印象深刻但毫无预测意义的挽救率。

无法看到取消流程的流失类别

还有第七个原因，它完全不在分类体系内，因为它从未进入流程。非自愿流失是指由于信用卡过期、支付失败或银行拒绝扣款而终止的订阅。客户并没有决定离开。他们从未点击取消，因此从未看到取消页面，从未回答问题，也从未出现在上述任何截图中。

Outro 不解决这个问题。它不进行支付失败恢复，也不进行催款。这是一个明确的界限，而不是可以从中读出路线图的项目。如果非自愿流失是您的问题，解决方案属于计费层，Stripe 的收入恢复工具 是正确的选择。单独解决它，不要让一个自愿流失工具让您误以为您的流失问题已被理解，而实际上有一部分从未进入流程。

常见错误

• 将原因分布视为事实 : 如果分布来自下拉菜单，价格被高估是结构性问题。应将其视为哪个标签最不尴尬地被点击的衡量标准，而不是人们离开的原因。
• 针对价格类别进行折扣 : 本文中的口头句子看似是折扣案例，实际上是分层结构案例。在更改价格之前，请阅读一些逐字记录的反馈。
• 将流失原因与反馈类型混为一谈 : Bug 报告与 technical issues 不同，这两个系统回答不同的问题，因此将它们合并会丢失信号。
• 从稀薄数据中得出趋势 : 十六个反馈只是机制演示，不是趋势。在对图表形状采取行动之前，请等待真实的量，包括上面的图表。
• 将点击优惠视为挽留 : 如果没有宽限期和实时订阅检查，挽留率衡量的是按钮点击而不是保留的收入。
• 隐藏取消链接以提高挽留率 : 这会将取消转化为退款和投诉，这是使取消流程成为负担的最快方式。
• 期望取消流程涵盖非自愿流失 : 失败的付款需要账单端重试，没有退出调查会看到它们。
• 编写超过少数选项的调查 : 每个额外选项都会为客户增加一个翻译步骤，并且是一个你永远不会采取行动的桶。出于这个原因，退出调查问题模板 比大多数团队预期的要短。

从仪表板获取答案

一个需要计划的实际限制。Outro 目前的出口是每周一到达的每周摘要电子邮件，以及 CSV 导出。没有公共 REST API，没有 webhooks，没有 npm 包，没有 Zapier、n8n 或 Make 连接器，也没有 Slack 集成。

这决定了工作流程。你不能将取消操作自动传输到自己的警报系统或将响应自动发送到 Slack 频道。你可以做的是将周一的摘要作为固定议程项目阅读，并在需要将响应与自己的账单数据结合时提取 CSV。对于一个小团队来说，这通常已经足够。如果你的流程依赖于事件驱动的自动化，最好现在就知道这一点，而不是在你已经围绕它设计之后才发现。

这对你的意义

这些类别不是洞察，它们是索引。它们的作用是使取消变得可计数，而计数确实有用，因为你无法优先考虑你无法比较的东西。但这六个类别中的每一个都是多个不同情况的容器，其中“too expensive”是最大且最具误导性的。工作是将句子附加到类别上，这样当价格类别填满时，你可以判断你是在看折扣问题、层级结构问题、入门问题，还是一个从未使用过你的产品的人的预算被削减的客户。

Outro 是一种带有语音退出访谈的取消流程软件，专为 Stripe 或 Lemon Squeezy 上的自助服务 SaaS 计费而构建。它用一个简短的口头问题替换取消按钮，转录并分类原因，并在取消进行之前显示匹配的挽留优惠。它有一个免费的 $0 级别，然后是每月 $29 的 Starter，$79 的 Pro 和 $199 的 Scale。本文中的每个截图都是产品的真实输出而不是模型，包括主题计数和随附的单日警告。