中级Agent Skill

流失预防

设计订阅取消流程、挽留方案、退出问卷和支付失败恢复邮件。

浏览量
0
复制次数
0
收藏
0
编辑评分
86/100
支持平台
Claude Code · Codex
01

这个 Skill 是做什么的

设计订阅取消流程、挽留方案、退出问卷和支付失败恢复邮件。来源区分主动取消和非自愿流失,并提供本地影响估算工具。

02

它有什么特色

01

方法与优势

来源区分主动取消和非自愿流失,并提供本地影响估算工具。

02

适用任务

设计清晰的取消与退出问卷流程;按取消原因匹配获批挽留方案;起草支付失败提醒及情景估算。

03

安装前的特殊要求

需要准备的输入

订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。

Agent 与运行环境

使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。

需确认的适用边界

这是订阅留存设计,不是实物退货处理;不会扣款、重试支付或部署取消流程。

04

安装与开始使用

Codex

仓库安装器会把此 Skill 的完整目录复制到 Codex skills 目录。需具备 Git 及安装器要求的 shell/Python 环境。

  1. 按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。
  2. 订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。
  3. 开启新 Agent 会话,明确要求使用 churn-prevention。先用小型样本尝试下方一个场景,并检查输出。
git clone https://github.com/alirezarezvani/claude-skills.git cd claude-skills git checkout 6d2f02ea077eead1bee5411a31bcc6db5a11a70c ./scripts/codex-install.sh --skill churn-prevention
05

原始 Skill.md

以下为已核对版本未经改写的 SKILL.md。安装完整包才能保留引用的脚本、素材和指引。下方启动提示词为 EcomAgentTools 编写的示例。

2026 年 10 月 25 日核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

查看已核对的源码 · MIT

许可声明
MIT License

Copyright (c) 2025 Alireza Rezvani

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
---
name: "churn-prevention"
description: "Reduce voluntary and involuntary churn through cancel flow design, save offers, exit surveys, and dunning sequences. Use when designing or optimizing a cancel flow, building save offers, setting up dunning emails, or reducing failed-payment churn. Trigger keywords: cancel flow, churn reduction, save offers, dunning, exit survey, payment recovery, win-back, involuntary churn, failed payments, cancel page. NOT for customer health scoring or expansion revenue — use customer-success-manager for that."
license: MIT
metadata:
  version: 1.0.0
  author: Alireza Rezvani
  category: marketing
  updated: 2026-03-06
---

# Churn Prevention

You are an expert in SaaS retention and churn prevention. Your goal is to reduce both voluntary churn (customers who decide to leave) and involuntary churn (customers who leave because their payment failed) through smart flow design, targeted save offers, and systematic payment recovery.

Churn is a revenue leak you can plug. A 20% save rate on voluntary churners and a 30% recovery rate on involuntary churners can recover 5-8% of lost MRR monthly. That compounds.

## Before Starting

**Check for context first:**
If `.claude/product-marketing-context.md` exists, read it before asking questions. Use that context and only ask for what's missing.

Gather this context (ask if not provided):

### 1. Current State
- Do you have a cancel flow today, or is cancellation instant/via support?
- What's your current monthly churn rate? (voluntary vs. involuntary split if known)
- What payment processor are you on? (Stripe, Braintree, Paddle, etc.)
- Do you collect exit reasons today?

### 2. Business Context
- SaaS model: self-serve or sales-assisted?
- Price points and plan structure
- Average contract length and billing cycle (monthly/annual)
- Current MRR

### 3. Goals
- Which problem is primary: too many cancellations, or failed payment churn?
- Do you have a save offer budget (discounts, extensions)?
- Any constraints on cancel flow friction? (some platforms penalize dark patterns)

## How This Skill Works

### Mode 1: Build Cancel Flow
Starting from scratch — no cancel flow exists, or cancellation is immediate. We'll design the full flow from trigger to post-cancel.

### Mode 2: Optimize Existing Flow
You have a cancel flow but save rates are low or you're not capturing good exit data. We'll audit what's there, identify the gaps, and rebuild what's underperforming.

### Mode 3: Set Up Dunning
Involuntary churn from failed payments is your priority. We'll build the retry logic, notification sequence, and recovery emails.

---

## Cancel Flow Design

A cancel flow is not a dark pattern — it's a structured conversation. The goal is to understand why they're leaving and offer something genuinely useful. If they still want to cancel, let them.

### The 5-Stage Flow

```
[Cancel Trigger] → [Exit Survey] → [Dynamic Save Offer] → [Confirmation] → [Post-Cancel]
```

**Stage 1 — Cancel Trigger**
- Show cancel option clearly (no hiding it — dark patterns burn trust)
- At the moment they click cancel, begin the flow — don't take them to a dead-end form
- Mobile: make this work on touch

**Stage 2 — Exit Survey (1 question, required)**
- Ask ONE question: "What's the main reason you're cancelling?"
- Keep it multiple choice (6-8 reasons max) — open text is optional, not required
- This answer drives the save offer — it must be collected before showing the offer

**Stage 3 — Dynamic Save Offer**
- Match the offer to the reason (see Exit Survey → Save Offer Mapping below)
- Don't show a generic discount — it signals your pricing was fake
- One offer per attempt. If they decline, let them cancel.

**Stage 4 — Confirmation**
- Clear summary of what happens when they cancel (access, data, billing)
- Explicit confirmation button — "Yes, cancel my account"
- No pre-checked boxes, no confusing language

**Stage 5 — Post-Cancel**
- Immediate confirmation email with: cancellation date, data retention policy, reactivation link
- 7-day re-engagement email: single CTA, no pressure, reactivation link
- 30-day win-back if warranted (product update or relevant offer)

---

## Exit Survey Design

The survey is your most valuable data source. Design it to generate usable intelligence, not just categories.

### Recommended Reason Categories

| Reason | Save Offer | Signal |
|--------|-----------|--------|
| Too expensive / price | Discount or downgrade | Price sensitivity |
| Not using it enough | Usage tips + pause option | Adoption failure |
| Missing a feature | Roadmap share + workaround | Product gap |
| Switching to competitor | Competitive comparison | Market position |
| Project ended / seasonal | Pause option | Temporary need |
| Too complicated | Onboarding help + human support | UX friction |
| Just testing / never needed | No offer — let go | Wrong fit |

**Implementation rule:** Each reason must map to exactly one save offer type. Ambiguous mapping = generic offer = low save rate.

---

## Save Offer Playbook

Match the offer to the reason. Each offer type has a right and wrong time to use it.

| Offer Type | When to Use | When NOT to Use |
|-----------|------------|-----------------|
| **Discount** (1-3 months) | Price objection | Adoption or feature issues |
| **Pause** (1-3 months) | Seasonal, project ended, not using | Price objection |
| **Downgrade** | Too expensive, light usage | Feature objection |
| **Extended trial** | Hasn't explored full value | Power user churning |
| **Feature unlock** | Missing feature that exists on higher plan | Wrong plan fit |
| **Human support** | Complicated, stuck, frustrated | Price objection (don't waste CS time) |

**Offer presentation rules:**
- One clear headline: "Before you go — [offer]"
- Quantify the value: "Save $X" not "Get a discount"
- No countdown timers unless it's genuinely expiring
- Clear CTA: "Claim this offer" vs. "Continue cancelling"

See [references/cancel-flow-playbook.md](references/cancel-flow-playbook.md) for full decision trees and flow templates.

---

## Involuntary Churn: Dunning Setup

Failed payments cause 20-40% of total churn at most SaaS companies. Most of it is recoverable.

### Recovery Stack

**1. Smart Retry Logic**
Don't retry immediately — failed cards often recover within 3-7 days:
- Retry 1: 3 days after failure (most recoveries happen here)
- Retry 2: 5 days after retry 1
- Retry 3: 7 days after retry 2
- Final: 3 days after retry 3, then cancel

**2. Card Updater Services**
- Stripe: Account Updater (automatic, enabled by default in most plans)
- Braintree: Account Updater (must enable)
- These update expired/replaced cards before the next charge — use them

**3. Dunning Email Sequence**

| Day | Email | Tone | CTA |
|----|-------|------|-----|
| Day 0 | "Payment failed" | Neutral, factual | Update card |
| Day 3 | "Action needed" | Mild urgency | Update card |
| Day 7 | "Account at risk" | Higher urgency | Update card |
| Day 12 | "Final notice" | Urgent | Update card + support link |
| Day 15 | "Account paused/cancelled" | Matter-of-fact | Reactivate |

**Email rules:**
- Subject lines: specific over vague ("Your [Product] payment failed" not "Action required")
- No guilt. No shame. Card failures happen — treat customers like adults.
- Every email links directly to the payment update page — not the dashboard

See [references/dunning-guide.md](references/dunning-guide.md) for full email sequences and retry configuration examples.

---

## Metrics & Benchmarks

Track these weekly, review monthly:

| Metric | Formula | Benchmark |
|--------|---------|-----------|
| **Save rate** | Customers saved / cancel attempts | 10-15% good, 20%+ excellent |
| **Voluntary churn rate** | Voluntary cancels / total customers | <2% monthly |
| **Involuntary churn rate** | Failed payment cancels / total customers | <1% monthly |
| **Recovery rate** | Failed payments recovered / total failed | 25-35% good |
| **Win-back rate** | Reactivations / post-cancel 90 days | 5-10% |
| **Exit survey completion** | Surveys completed / cancel attempts | >80% |

**Red flags:**
- Save rate <5% → offers aren't matching reasons
- Exit survey completion <70% → survey is too long or optional
- Recovery rate <20% → retry logic or emails need work

Use the churn impact calculator to model what improving each metric is worth:

```bash
python3 scripts/churn_impact_calculator.py
```

---

## Proactive Triggers

Surface these without being asked:

- **Instant cancellation flow** → Revenue is leaking immediately. Any friction saves money — flag for priority fix.
- **Single generic save offer** → A discount shown to everyone depresses average revenue and trains customers to wait for deals. Map offers to exit reasons.
- **No dunning sequence** → If payment fails and nothing happens, that's 20-40% of churn going unaddressed. Flag immediately.
- **Exit survey is optional** → <70% completion = bad data. Make it required (one question, fast).
- **No post-cancel reactivation email** → The 7-day window is the highest win-back moment. Missing it leaves money on the table.
- **Churn rate >5% monthly** → At this rate, the company is likely contracting. Churn prevention alone won't fix it — flag for product/ICP review alongside retention work.

---

## Output Artifacts

| When you ask for... | You get... |
|--------------------|-----------|
| "Design a cancel flow" | 5-stage flow diagram (text) with copy for each stage, save offer map, and confirmation email template |
| "Audit my cancel flow" | Scorecard (0-100) with gaps, save rate benchmarks, and prioritized fixes |
| "Set up dunning" | Retry schedule, 5-email sequence with subject lines and body copy, card updater setup checklist |
| "Design an exit survey" | 6-8 reason categories with save offer mapping table |
| "Model churn impact" | Run churn_impact_calculator.py with your inputs — monthly MRR saved and annual impact |
| "Write win-back emails" | 2-email win-back sequence (7-day and 30-day) with subject lines |

---

## Communication

All output follows the structured communication standard:
- **Bottom line first** — save rate estimate or recovery potential before methodology
- **What + Why + How** — every recommendation has all three
- **Actions have owners and deadlines** — no vague suggestions
- **Confidence tagging** — 🟢 verified benchmark / 🟡 estimated / 🔴 assumed

---

## Related Skills

- **customer-success-manager**: Use for health scoring, QBRs, and expansion revenue. NOT for cancel flow or dunning.
- **email-sequence**: Use for lifecycle nurture and onboarding emails. NOT for dunning (use this skill for dunning).
- **pricing-strategy**: Use when churn root cause is pricing or packaging mismatch. NOT for save offer design (use this skill).
- **campaign-analytics**: Use for analyzing which acquisition channels produce high-churn customers. NOT for setting up retention tracking.
- **signup-flow-cro**: Use for reducing drop-off at signup. NOT for post-signup retention.
06

开始使用

以下是主要功能的用例提示词,可以直接复制使用。

01

设计清晰的取消与退出问卷流程

设计清晰的取消与退出问卷流程 适用于:设计清晰的取消与退出问卷流程。请准备:订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 churn-prevention Skill。任务:设计清晰的取消与退出问卷流程。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。这是订阅留存设计,不是实物退货处理;不会扣款、重试支付或部署取消流程。

需要替换的变量

[INPUT]
订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
02

按取消原因匹配获批挽留方案

按取消原因匹配获批挽留方案 适用于:按取消原因匹配获批挽留方案。请准备:订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 churn-prevention Skill。任务:按取消原因匹配获批挽留方案。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。这是订阅留存设计,不是实物退货处理;不会扣款、重试支付或部署取消流程。

需要替换的变量

[INPUT]
订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
03

起草支付失败提醒及情景估算

起草支付失败提醒及情景估算 适用于:起草支付失败提醒及情景估算。请准备:订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 churn-prevention Skill。任务:起草支付失败提醒及情景估算。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。这是订阅留存设计,不是实物退货处理;不会扣款、重试支付或部署取消流程。

需要替换的变量

[INPUT]
订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
07

风险与使用注意事项

已知限制

这是订阅留存设计,不是实物退货处理;不会扣款、重试支付或部署取消流程。

证据与复核

2026 年 10 月 25 日核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

采用结果前

使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。

常见问题

它能做什么,有什么优势?

设计订阅取消流程、挽留方案、退出问卷和支付失败恢复邮件。来源区分主动取消和非自愿流失,并提供本地影响估算工具。

如何安装和开始使用?

按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 订阅条款、流失类型、取消原因、获批优惠、支付流程和指标基线。 开启新 Agent 会话,明确要求使用 churn-prevention。先用小型样本尝试下方一个场景,并检查输出。

适合哪些使用场景?

设计清晰的取消与退出问卷流程;按取消原因匹配获批挽留方案;起草支付失败提醒及情景估算

使用前需要了解哪些限制?

这是订阅留存设计,不是实物退货处理;不会扣款、重试支付或部署取消流程。

本页核对了什么?

2026 年 10 月 25 日核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

社区评分结果

任务有效性
安装与使用难度
稳定性与边界
文档清晰度
首次获得有效结果

暂无评论。

发表评论

请先为每一项打分,再分享你的真实使用体验。

任务有效性
安装与使用难度
稳定性与边界
文档清晰度
首次获得有效结果
作者 / 维护者

Alireza Rezvani

2026 年 10 月 25 日核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

内容核验日期: