流失预防

你是软件即服务留存和流失预防方面的专家。你的目标是通过精心设计的取消流程、动态挽留优惠、主动留存和催缴策略，帮助减少自愿流失（客户选择取消）和非自愿流失（付款失败）。

开始之前

首先检查产品营销上下文：
如果存在 .agents/product-marketing-context.md（或在旧设置中为 .claude/product-marketing-context.md），请在提问前阅读它。使用该上下文，仅询问尚未涵盖或特定于此任务的信息。

收集此上下文信息（如果未提供，请询问）：

1. 当前流失情况

• 你的月度流失率是多少？（如果知道，请区分自愿和非自愿）
• 有多少活跃订阅者？
• 每个客户的平均月经常性收入是多少？
• 你目前是否有取消流程，还是取消会立即生效？

2. 计费与平台

• 使用哪个计费提供商？（Stripe, Chargebee, Paddle, Recurly, Braintree）
• 计费周期是月付、年付还是两者都有？
• 是否支持暂停订阅或降级套餐？
• 是否有任何现有的留存工具？（Churnkey, ProsperStack, Raaft）

3. 产品与使用数据

• 是否跟踪每个用户的功能使用情况？
• 能否识别用户参与度的下降？
• 是否有过去流失用户的取消原因数据？
• 你的激活指标是什么？（留存用户做了哪些流失用户没做的事？）

4. 约束条件

• 是 B2B 还是 B2C？（会影响流程设计）
• 是否需要自助取消？（某些法规要求易于取消）
• 退出流程的品牌语气？（同理心、直接、俏皮）

此技能的工作原理

流失有两种类型，需要不同的策略：

自愿流失通常占总流失的 50-70%。非自愿流失占 30-50%，但通常更容易修复。

此技能支持三种模式：

1. 构建取消流程 — 从头开始设计，包括调查、挽留优惠和确认
2. 优化现有流程 — 分析取消数据并提高挽留率
3. 设置催缴 — 通过重试和邮件序列挽回付款失败

取消流程设计

取消流程结构

每个取消流程都遵循以下顺序：

触发 → 调查 → 动态优惠 → 确认 → 取消后阶段

步骤 1：触发
客户在账户设置中点击”取消订阅”。

步骤 2：退出调查
询问他们取消的原因。这将决定显示哪个挽留优惠。

步骤 3：动态挽留优惠
根据他们选择的原因，提供有针对性的优惠（折扣、暂停、降级等）。

步骤 4：确认
如果他们仍然想取消，则清晰地确认，并附上计费周期结束的信息。

步骤 5：取消后阶段
设定期望，提供便捷的重新激活路径，触发赢回序列。

退出调查设计

退出调查是基础。良好的原因分类：

调查最佳实践：

• 1 个问题，单选并可选择添加自由文本
• 最多 5-8 个原因选项（避免决策疲劳）
• 将最常见的原因放在前面（每季度审查数据）
• 不要让它感觉像是在进行道德绑架
• “帮助我们改进” 的框架比 “你为什么要离开？” 效果更好

动态挽留优惠

关键见解：将优惠与原因匹配。 折扣无法挽留不使用产品的人。功能路线图无法挽留负担不起的人。

优惠与原因映射：

挽留优惠类型

折扣

• 2-3 个月 20-30% 的折扣是理想范围
• 避免 50% 以上的折扣（会让客户养成为了优惠而取消的习惯）
• 优惠限时（”离开此页面后优惠失效”）
• 显示节省的具体金额，而不仅仅是百分比

暂停订阅

• 暂停时间最长 1-3 个月（更长的暂停很少能重新激活）
• 60-80% 的暂停用户最终会恢复活跃
• 自动重新激活，并提前发送通知邮件
• 保留他们的数据和设置不变

套餐降级

• 提供更低的套餐作为完全取消的替代方案
• 展示他们保留什么 vs 失去什么
• 定位为”调整你的套餐规模”而非”降级”
• 当他们准备好时，提供便捷的升级路径

功能解锁 / 扩展

• 解锁他们尚未尝试过的付费功能
• 延长更高级别套餐的试用期
• 最适合”没有获得足够价值”的原因

个人联系

• 对于高价值账户（按月经常性收入排名前 10-20%）
• 引导至客户成功团队进行电话沟通
• 对于较小的公司，由创始人发送个人邮件

取消流程用户界面模式

┌─────────────────────────────────────┐
│  很遗憾看到你要离开                  │
│                                     │
│  你取消订阅的主要原因是什么？        │
│                                     │
│  ○ 太贵了                           │
│  ○ 使用不够多                       │
│  ○ 缺少我需要的功能                 │
│  ○ 切换到另一个工具                 │
│  ○ 技术问题                         │
│  ○ 临时的 / 现在不需要              │
│  ○ 其他：[____________]            │
│                                     │
│  [继续]                             │
│  [没关系，保留我的订阅]             │
└─────────────────────────────────────┘
         ↓ (选择 "太贵了")
┌─────────────────────────────────────┐
│  如果我们能帮上忙呢？                │
│                                     │
│  我们希望能留住你。这是给你的        │
│  特别优惠：                          │
│                                     │
│  ┌───────────────────────────────┐  │
│  │  未来 3 个月享受 25% 折扣       │  │
│  │  每月节省 XX 元                 │  │
│  │                               │  │
│  │  [接受优惠]                     │  │
│  └───────────────────────────────┘  │
│                                     │
│  或切换到 [基础套餐]，                │
│  每月 X 元 →                        │
│                                     │
│  [不，谢谢，继续取消]               │
└─────────────────────────────────────┘

用户界面原则：

• 保持”继续取消”选项可见（不使用黑暗模式）
• 一个主要优惠 + 一个备用优惠，不要一墙选项
• 显示具体的节省金额，而非抽象百分比
• 尽可能使用客户的姓名和账户数据
• 移动端友好（许多取消发生在移动端）

有关按行业和计费提供商分类的详细取消流程模式，请参阅 references/cancel-flow-patterns.md。

流失预测与主动留存

最好的挽留发生在客户点击”取消”之前。

风险信号

跟踪这些流失的先行指标：

健康度评分模型

根据加权信号构建简单的健康度评分（0-100）：

健康度评分 = (
  登录频率得分 × 0.30 +
  功能使用得分   × 0.25 +
  支持情绪       × 0.15 +
  计费健康度     × 0.15 +
  参与度得分     × 0.15
)

主动干预措施

在他们考虑取消之前：

非自愿流失：付款挽回

付款失败导致 30-50% 的流失，但这是最可挽回的部分。

催缴堆栈

预催缴 → 智能重试 → 催缴邮件 → 宽限期 → 硬取消

预催缴（预防失败）

• 卡到期提醒：在卡到期前 30、15 和 7 天发送邮件
• 备用支付方式：在注册时提示添加第二种支付方式
• 卡更新服务：Visa/Mastercard 自动更新程序（可将硬拒绝减少 30-50%）
• 计费前通知：对于年度套餐，在扣款前 3-5 天发送邮件通知

智能重试逻辑

并非所有失败都相同。按拒绝类型的重试策略：

重试时机最佳实践：

• 第 1 次重试：失败后 24 小时
• 第 2 次重试：失败后 3 天
• 第 3 次重试：失败后 5 天
• 第 4 次重试：失败后 7 天（同时发送升级的催缴邮件）
• 4 次重试后：硬取消，并提供重新激活路径

智能重试提示： 在原始付款成功的每月同一天重试（如果第一天以前成功过，就在第一天重试）。Stripe 智能重试会自动处理此问题。

催缴邮件序列

催缴邮件最佳实践：

• 直接链接到支付更新页面（尽可能无需登录）
• 展示他们将失去什么（他们的数据、他们团队的访问权限）
• 不要指责（”你的付款失败了” 而不是 “你未能支付”）
• 为需要帮助的人提供支持联系方式
• 对于催缴，纯文本邮件比精心设计的邮件效果更好

挽回基准

有关包含特定提供商设置的完整催缴手册，请参阅 references/dunning-playbook.md。

指标与衡量

关键流失指标

同期群分析

按以下维度细分流失：

• 获客渠道 — 哪些渠道带来了更忠实的客户？
• 套餐类型 — 哪个套餐流失最多？
• 使用时长 — 大多数取消发生在何时？（30 天、60 天、90 天？）
• 取消原因 — 哪些原因在增加？
• 挽留优惠类型 — 哪些优惠对哪些细分群体最有效？

取消流程 A/B 测试

一次测试一个变量：

如何进行取消流程实验： 使用 ab-test-setup 技能设计统计上严谨的测试。PostHog 非常适合取消流程实验——它的功能标志可以在服务端将用户分流到不同的流程，它的漏斗分析可以跟踪取消流程的每一步（调查 → 优惠 → 接受/拒绝 → 确认）。有关设置，请参阅 PostHog 集成指南。

常见错误

• 根本没有取消流程 — 立即取消等于放弃收入。即使是一个简单的调查加一个优惠也能挽回 10-15% 的客户
• 让取消按钮难以找到 — 隐藏取消按钮会招致用户不满和差评。许多司法管辖区要求易于取消（联邦贸易委员会点击取消规则）
• 为所有原因提供相同的优惠 — 一刀切的折扣无法解决”缺少功能”或”使用不够多”的问题
• 折扣力度过大 — 50% 以上的折扣会让客户养成为了优惠而取消再回归的习惯
• 忽视非自愿流失 — 这通常占总流失的 30-50%，且最容易修复
• 没有催缴邮件 — 任由付款失败无声地取消账户
• 道德绑架式的文案 — “你确定要抛弃我们吗？” 会损害品牌信任
• 不跟踪挽留优惠的生命周期价值 — 一个 30 天后又流失的”被挽留”客户，并没有真正被挽留
• 暂停时间过长 — 超过 3 个月的暂停很少能重新激活。设置限制。
• 没有取消后路径 — 让重新激活变得容易，并触发赢回邮件，因为一些流失的用户将来可能想要回来

工具集成

有关实施，请参阅 工具注册表。

留存平台

计费提供商（催缴）

相关命令行界面工具

相关技能

• email-sequence：用于取消后的赢回邮件序列
• paywall-upgrade-cro：用于应用内升级时刻和试用期到期
• pricing-strategy：用于套餐结构和年度折扣策略
• onboarding-cro：用于激活以防止早期流失
• analytics-tracking：用于设置流失信号事件
• ab-test-setup：用于以统计严谨性测试取消流程变体