churn-prevention
ユーザーがチャーン（解約離脱）の削減、キャンセルフローの構築、引き留めオファーの設定、支払い失敗の回復、またはリテンション戦略の実装を望む場合に使用します。「解約率が高い」「ユーザーが離れていく」「ダニング」「サブスクリプションの一時停止」「ウィンバック」「退会アンケート」など、顧客流出に関するあらゆる場面で活用できます。なお、解約後のウィンバックメールシーケンスは emails スキル、アプリ内アップグレードのペイウォールは paywalls スキルを参照してください。
description の原文を見る
When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers or wants to build systems to prevent it. For post-cancel win-back email sequences, see emails. For in-app upgrade paywalls, see paywalls.
SKILL.md 本文
チャーン防止
SaaS のリテンションとチャーン防止の専門家です。よく設計されたキャンセルフロー、ダイナミックなセーブオファー、プロアクティブなリテンション、ダニング戦略を通じて、自発的チャーン（顧客がキャンセルを選択する）と非自発的チャーン（支払い失敗）の両方を削減することを目標とします。
開始前に
最初にプロダクトマーケティングのコンテキストを確認:
.agents/product-marketing.md が存在する場合（または .claude/product-marketing.md、または古いセットアップでは product-marketing-context.md）、質問をする前にそれを読んでください。そのコンテキストを使用し、すでにカバーされているか、このタスクに固有でない情報についてのみ質問します。
このコンテキストを集めてください（提供されていない場合は質問してください）:
1. 現在のチャーン状況
- 月次チャーン率はどのくらい？（自発的 vs 非自発的がわかれば）
- アクティブな加入者数？
- 顧客あたりの平均 MRR？
- 現在キャンセルフローがありますか、それともキャンセルは即座に行われますか？
2. 請求・プラットフォーム
- 請求プロバイダは？（Stripe、Chargebee、Paddle、Recurly、Braintree）
- 月次、年次、またはその両方の請求周期？
- プラン一時停止またはダウングレードをサポート？
- 既存のリテンションツール？（Churnkey、ProsperStack、Raaft）
3. プロダクト・利用データ
- ユーザーごとの機能利用を追跡していますか？
- エンゲージメント低下を特定できますか？
- 過去のチャーンからキャンセル理由データがありますか？
- アクティベーション指標は？（リテンユーザーがチャーンユーザーがしていないことは何ですか？）
4. 制約
- B2B または B2C？（フロー設計に影響）
- セルフサービスキャンセルが必要？（一部の規制は簡単なキャンセルを義務付け）
- オフボーディングのブランドトーン？（共感的、直接的、遊び心のある）
このスキルの仕組み
チャーンには異なる戦略が必要な 2 つのタイプがあります:
| タイプ | 原因 | ソリューション |
|---|---|---|
| 自発的 | 顧客がキャンセルを選択 | キャンセルフロー、セーブオファー、終了サーベイ |
| 非自発的 | 支払いが失敗 | ダニングメール、スマートリトライ、カード更新 |
自発的チャーンは通常、総チャーンの 50～70% です。非自発的チャーンは 30～50% ですが、修正しやすいことが多いです。
このスキルは 3 つのモードをサポートします:
- キャンセルフローを構築 — サーベイ、セーブオファー、確認画面を含めてゼロから設計
- 既存フローを最適化 — キャンセルデータを分析し、保存率を改善
- ダニングを設定 — リトライとメールシーケンスで支払い失敗を回復
キャンセルフロー設計
キャンセルフロー構造
すべてのキャンセルフローは次のシーケンスに従います:
トリガー → サーベイ → ダイナミックオファー → 確認 → キャンセル後
ステップ 1: トリガー 顧客がアカウント設定で「サブスクリプションをキャンセル」をクリック。
ステップ 2: 終了サーベイ なぜキャンセルするのかを聞く。これにより、どのセーブオファーを表示するかが決まります。
ステップ 3: ダイナミックセーブオファー 理由に基づいて対象となるオファーを提示（割引、一時停止、ダウングレード等）。
ステップ 4: 確認 キャンセルを続行したい場合、請求期間終了のメッセージを明確に確認。
ステップ 5: キャンセル後 期待値を設定し、簡単な再有効化パスを提供し、win-back シーケンスをトリガー。
終了サーベイ設計
終了サーベイは基礎です。良い理由カテゴリ:
| 理由 | 意味すること |
|---|---|
| 高すぎる | 価格に敏感、割引やダウングレードに応じるかもしれない |
| 十分に使用していない | エンゲージメント低い、一時停止またはオンボーディング支援に応じるかもしれない |
| 必要な機能がない | プロダクトギャップ、ロードマップまたは回避策を表示 |
| 競合他社に切り替え | 競争圧力、彼らが何を提供するかを理解 |
| 技術的問題／バグ | プロダクト品質、サポートにエスカレート |
| 一時的／季節的ニーズ | 使用パターン、一時停止を提供 |
| ビジネスが閉業／変更 | 回避不可能、優雅に対応 |
| その他 | キャッチオール、フリーテキストフィールドを含める |
サーベイのベストプラクティス:
- 1 つの質問、オプションの自由回答を含む単一選択
- 最大 5～8 個の理由オプション（決定疲労を避ける）
- 最も一般的な理由を最初に（データを四半期ごとに確認）
- 罪悪感を感じさせるような感覚ではない
- 「なぜ去っているのか」よりも「改善をお手伝いさせてください」というフレーミングがうまくいく
ダイナミックセーブオファー
重要な洞察: オファーを理由に合わせてください。 割引はプロダクトを使用していない人を救いません。機能ロードマップはそれを購入できない人を救いません。
オファーと理由のマッピング:
| キャンセル理由 | プライマリオファー | フォールバックオファー |
|---|---|---|
| 高すぎる | 割引（2～3 ヶ月間 20～30%） | より低いプランへのダウングレード |
| 十分に使用していない | 一時停止（1～3 ヶ月） | 無料オンボーディングセッション |
| 機能がない | ロードマッププレビュー＋タイムライン | 回避策ガイド |
| 競合他社に切り替え | 競争分析＋割引 | フィードバックセッション |
| 技術的問題 | サポートに直ちにエスカレート | クレジット＋優先修正 |
| 一時的／季節的 | サブスクリプションを一時停止 | 一時的にダウングレード |
| ビジネスが閉業 | オファーをスキップ（状況を尊重） | — |
セーブオファータイプ
割引
- 2～3 ヶ月間 20～30% の割引がスイートスポット
- 50% 以上の割引を避ける（顧客がキャンセルしてディールを取得するように訓練）
- オファーの時間制限（「このページを離れるとこのオファーは期限切れになります」）
- パーセンテージだけでなく、節約した金額を表示
サブスクリプション一時停止
- 最大 1～3 ヶ月の一時停止（より長い一時停止はめったに再有効化されない）
- 一時停止者の 60～80% は最終的にアクティブに戻る
- 事前通知メール付きの自動再有効化
- データと設定をそのまま保持
プランダウングレード
- 完全なキャンセルの代わりに、より低いティアを提供
- 失うもの vs 保持するものを表示
- 「ダウングレード」ではなく「プランを適正規模に」として位置付け
- 準備ができたら簡単にアップグレードする パス
機能ロック解除／延長
- 試していない プレミアム機能のロック解除
- より高いティアの試用延長
- 「十分な価値を得ていない」理由に最適
個人的なアウトリーチ
- 高価値アカウント（MRR 上位 10～20%）向け
- カスタマーサクセスへのルーティング
- より小さい企業向けの創業者からの個人メール
キャンセルフロー UI パターン
┌─────────────────────────────────────┐
│ ご利用ありがとうございます │
│ │
│ キャンセルの主な理由は？ │
│ │
│ ○ 高すぎる │
│ ○ 十分に使用していない │
│ ○ 必要な機能がない │
│ ○ 別のツールに切り替え │
│ ○ 技術的な問題 │
│ ○ 一時的／今は必要ない │
│ ○ その他: [____________] │
│ │
│ [続ける] │
│ [キャンセル、サブスクリプションを維持] │
└─────────────────────────────────────┘
↓ (「高すぎる」を選択)
┌─────────────────────────────────────┐
│ お役立てできることがあるかも │
│ │
│ 続行したいです。特別なオファーです: │
│ │
│ ┌───────────────────────────────┐ │
│ │ 次の 3 ヶ月間 25% 割引 │ │
│ │ 毎月 $XX 節約 │ │
│ │ │ │
│ │ [オファーを承認] │ │
│ └───────────────────────────────┘ │
│ │
│ またはプランを [基本プラン] に切り替え │
│ $X/月 → │
│ │
│ [結構です、キャンセルを続ける] │
└─────────────────────────────────────┘
UI の原則:
- 「キャンセルを続ける」オプションを表示（ダークパターンなし）
- プライマリオファー 1 つ＋フォールバック 1 つ、オプションの壁ではない
- 抽象的なパーセンテージではなく、具体的なドル節約を表示
- 可能な場合は、顧客の名前とアカウント データを使用
- モバイルフレンドリー（多くのキャンセルはモバイルで行われます）
業界と請求プロバイダ別のキャンセルフロー パターンの詳細については、references/cancel-flow-patterns.md を参照してください。
チャーン予測とプロアクティブリテンション
最良の保存は、顧客が「キャンセル」をクリックする前に行われます。
リスク信号
チャーンの次の先行指標を追跡:
| 信号 | リスクレベル | 時間枠 |
|---|---|---|
| ログイン頻度が 50% 以上低下 | 高 | キャンセルの 2～4 週間前 |
| 主要機能の使用が停止 | 高 | キャンセルの 1～3 週間前 |
| サポートチケットがスパイク、その後停止 | 高 | キャンセルの 1～2 週間前 |
| メール開封率が低下 | 中 | キャンセルの 2～6 週間前 |
| 請求ページの訪問が増加 | 高 | キャンセルの数日前 |
| チームシートが削除 | 高 | キャンセルの 1～2 週間前 |
| データエクスポートが開始 | クリティカル | キャンセルの数日前 |
| NPS スコアが 6 未満に低下 | 中 | キャンセルの 1～3 ヶ月前 |
ヘルススコアモデル
加重信号から簡単なヘルススコア（0～100）を作成:
ヘルススコア = (
ログイン頻度スコア × 0.30 +
機能使用スコア × 0.25 +
サポートセンチメント × 0.15 +
請求ヘルス × 0.15 +
エンゲージメントスコア × 0.15
)
| スコア | ステータス | アクション |
|---|---|---|
| 80-100 | 健全 | アップセル機会 |
| 60-79 | 注意が必要 | プロアクティブなチェックイン |
| 40-59 | リスク中 | インターベンション キャンペーン |
| 0-39 | クリティカル | 個人的なアウトリーチ |
プロアクティブなインターベンション
キャンセルを考える前に:
| トリガー | インターベンション |
|---|---|
| 2 週間の使用量が 50% 以上低下 | 「[機能]を使用していないことに気づきました。ヘルプが必要ですか？」メール |
| プランリミットが近い | アップグレードナッジ（ペイウォールではなく、paywallsを参照） |
| 14 日間ログインなし | 最近のプロダクトアップデートを含む再エンゲージメントメール |
| NPS デトラクター（0～6） | 24 時間以内の個人的なフォローアップ |
| サポートチケット未解決 >48h | エスカレーション＋プロアクティブなステータス更新 |
| 年間更新まで 30 日 | 価値リキャップメール＋更新確認 |
非自発的チャーン: 支払い回復
失敗した支払いは総チャーンの 30～50% を引き起こしますが、最も回復可能です。
ダニング スタック
ダニング前 → スマートリトライ → ダニングメール → グレースピリオド → ハード キャンセル
ダニング前（失敗を防止）
- カード有効期限アラート: カード有効期限の 30、15、7 日前にメール送信
- バックアップ支払い方法: サインアップ時に 2 番目の支払い方法を促す
- カード更新サービス: Visa/Mastercard の自動更新プログラム（ハード拒否を 30～50% 削減）
- 請求前通知: 年間プランの請求の 3～5 日前にメール送信
スマートリトライ ロジック
すべての失敗が同じわけではありません。拒否タイプ別のリトライ戦略:
| 拒否タイプ | 例 | リトライ戦略 |
|---|---|---|
| ソフト拒否（一時的） | 資金不足、プロセッサタイムアウト | 7～10 日間に 3～5 回リトライ |
| ハード拒否（永続的） | カードが盗まれた、アカウント閉鎖 | リトライしない — 新しいカードを要求 |
| 認証が必要 | 3D Secure、SCA | 支払い更新ページに顧客を送信 |
リトライタイミング のベストプラクティス:
- リトライ 1: 失敗から 24 時間後
- リトライ 2: 失敗から 3 日後
- リトライ 3: 失敗から 5 日後
- リトライ 4: 失敗から 7 日後（ダニングメールのエスカレーション付き）
- 4 回のリトライ後: ハードキャンセル（再有効化パス付き）
スマートリトライのヒント: 支払いが元々成功した日の月日にリトライ（1 日目が以前に機能した場合、1 日目にリトライ）。Stripe Smart Retries がこれを自動的に処理します。
ダニング メール シーケンス
| メール | タイミング | トーン | コンテンツ |
|---|---|---|---|
| 1 | 0 日目（失敗） | フレンドリーなアラート | 「お支払いが処理されませんでした。カードを更新してください。」 |
| 2 | 3 日目 | 有用なリマインダー | 「リマインダー — アクセスを維持するためにお支払いを更新してください。」 |
| 3 | 7 日目 | 緊急性 | 「アカウントは 3 日で一時停止されます。今更新してください。」 |
| 4 | 10 日目 | 最終警告 | 「アカウントをアクティブに保つための最後のチャンスです。」 |
ダニングメールのベストプラクティス:
- 支払い更新ページへの直接リンク（可能であればログインなし）
- 失うもの（データ、チームのアクセス）を表示
- 「支払いが失敗した」ではなく「失敗した」（责任を負わない）
- サポート連絡先をサポート用に含める
- ダニング用のプレーンテキストは設計されたメールより優れて実行
回復ベンチマーク
| メトリック | 低 | 平均 | 高 |
|---|---|---|---|
| ソフト拒否回復 | <40% | 50-60% | 70%+ |
| ハード拒否回復 | <10% | 20-30% | 40%+ |
| 全体的な支払い回復 | <30% | 40-50% | 60%+ |
| ダニング前の防止 | なし | 10-15% | 20-30% |
プロバイダ固有のセットアップを含む完全なダニングプレイブックについては、references/dunning-playbook.md を参照してください。
メトリクスと測定
主なチャーン メトリック
| メトリック | 計算式 | ターゲット |
|---|---|---|
| 月次チャーン率 | チャーン顧客 / 月初顧客 | <5% B2C、<2% B2B |
| 収益チャーン（ネット） | （失った MRR - 拡大 MRR）/ 開始 MRR | 負数（ネット拡大） |
| キャンセルフロー保存率 | 保存済み / 総キャンセルセッション | 25-35% |
| オファー承認率 | 承認されたオファー / 表示されたオファー | 15-25% |
| 一時停止再有効化率 | 再有効化 / 総一時停止 | 60-80% |
| ダニング回復率 | 回復 / 総失敗支払い | 50-60% |
| キャンセルまでの時間 | 最初のチャーン信号からキャンセルまでの日数 | トレンドを追跡 |
コホート分析
チャーンを次の方法でセグメント化:
- 取得チャネル — どのチャネルがより粘着性のある顧客をもたらしますか？
- プランタイプ — どのプランが最もチャーンしますか？
- 保有期間 — ほとんどのキャンセルはいつ発生しますか？（30、60、90 日？）
- キャンセル理由 — どの理由が成長していますか？
- セーブオファータイプ — どのオファーがどのセグメントに最適に機能しますか？
キャンセルフロー A/B テスト
一度に 1 つの変数をテスト:
| テスト | 仮説 | メトリック |
|---|---|---|
| 割引%（20% vs 30%） | より高い割引がより多く保存 | 保存率、LTV への影響 |
| 一時停止期間（1 vs 3 ヶ月） | より長い一時停止が再有効化率を増加 | 再有効化率 |
| サーベイ配置（オファーの前 vs 後） | サーベー ファーストはオファーをパーソナライズ | 保存率 |
| オファープレゼンテーション（モーダル vs フルページ） | フルページはより多くの注意を取得 | 保存率 |
| コピートーン（共感的 vs 直接的） | 共感的は摩擦を減らす | 保存率 |
キャンセルフロー実験を実行する方法: ab-testing スキルを使用して、統計的に厳密なテストを設計します。PostHog はキャンセルフロー実験に適しています — フィーチャーフラグは異なるフロー間でユーザーをサーバー側で分割でき、ファネル分析はキャンセルフロー（サーベイ → オファー → 承認／拒否 → 確認）の各ステップを追跡します。セットアップについては、PostHog 統合ガイド を参照してください。
よくある間違い
- キャンセルフローがない — 即座のキャンセルはテーブルにお金を残します。シンプルなサーベイ + 1 つのオファーでも 10～15% 節約できます
- キャンセルを見つけるのが困難にする — 隠されたキャンセルボタンは怨恨と悪いレビューを引き起こします。多くの管轄区域では簡単なキャンセルが必要です（FTC Click-to-Cancel ルール）
- すべての理由に対して同じオファー — 一括割引は「機能がない」や「使用していない」に対応しません
- 割引が深すぎる — 50% 以上の割引は顧客にキャンセルしてディールを取得するように訓練します
- 非自発的チャーンを無視 — 総チャーンの 30～50% を占め、修正しやすい場合が多い
- ダニングメールなし — 支払い失敗をサイレントにキャンセルアカウント
- 罪悪感トリップコピー — 「本当に私たちを放棄したいですか？」はブランド信頼を傷つけます
- 保存されたオファー LTV を追跡しない — 30 日後にチャーンした「保存」顧客は実際には保存されていませんでした
- 長すぎる一時停止 — 3 ヶ月を超える一時停止はめったに再有効化されません。制限を設定します。
- キャンセル後のパスがない — 再有効化を簡単にし、win-back メールをトリガーします。チャーンしたユーザーの一部は戻りたいからです。
ツール統合
実装については、tools registry を参照してください。
リテンション プラットフォーム
| ツール | 最適な用途 | キー機能 |
|---|---|---|
| Churnkey | 完全なキャンセルフロー + ダニング | AI を搭載した適応的オファー、平均保存率 34% |
| ProsperStack | キャンセルフロー（分析付き） | 高度なルールエンジン、Stripe/Chargebee 統合 |
| Raaft | シンプルなキャンセルフロービルダー | 簡単なセットアップ、初期段階に適している |
| Chargebee Retention | Chargebee 顧客 | ネイティブ統合、Brightback を使用 |
請求プロバイダ（ダニング）
| プロバイダ | スマートリトライ | ダニングメール | カード更新 |
|---|---|---|---|
| Stripe | 組み込み（Smart Retries） | 組み込み | 自動 |
| Chargebee | 組み込み | 組み込み | ゲートウェイ経由 |
| Paddle | 組み込み | 組み込み | 管理 |
| Recurly | 組み込み | 組み込み | 組み込み |
| Braintree | 手動設定 | 手動 | ゲートウェイ経由 |
関連 CLI ツール
| ツール | 用途 |
|---|---|
stripe | サブスクリプション管理、ダニング設定、支払いリトライ |
customer-io | ダニングメールシーケンス、リテンションキャンペーン |
posthog | キャンセルフロー A/B テスト（フィーチャーフラグ経由）、ファネル分析 |
mixpanel / ga4 | 使用トラッキング、チャーン信号分析 |
segment | ヘルススコアリング用イベントルーティング |
関連スキル
- emails: キャンセル後の win-back メールシーケンス用
- paywalls: アプリ内アップグレード機会と試用期限切れ用
- pricing: プラン構造と年間割引戦略用
- onboarding: 早期チャーンを防ぐための アクティベーション用
- analytics: チャーン信号イベント設定用
- ab-testing: 統計的厳密さを持つキャンセルフロー変動テスト用
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- coreyhaines31
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/coreyhaines31/marketingskills / ライセンス: MIT
関連スキル
superfluid
Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード：Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool（member/distributor）、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper
civ-finish-quotes
実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。
nookplot
Base（Ethereum L2）上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。
web3-polymarket
Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。
ethskills
Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格（ERC-20、ERC-721、ERC-4626など）、Layer 2ネットワーク（Base、Arbitrum、Optimism、zkSync、Polygon）、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化（EIPライフサイクル、フォーク追跡、今後の変更予定）といったトピックを含みます。
xxyy-trade
このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。