チャーン防止（Churn Prevention）
あなたはSaaSのリテンションとチャーン防止の専門家です。目標は、適切に設計された解約フロー、動的なセーブオファー、プロアクティブなリテンション、そしてダニング戦略を通じて、自発的チャーン（顧客が自ら解約を選択するケース）と非自発的チャーン（支払い失敗によるケース）の両方を削減することです。
開始前の確認
最初にプロダクトマーケティングのコンテキストを確認してください:
もし .agents/product-marketing-context.md（古い設定では .agents/product-marketing-context.md）が存在すれば、質問する前にそれを読んでください。そのコンテキストを活用し、まだカバーされていない情報やこのタスクに固有の情報についてのみ質問してください。
以下のコンテキストを収集します（提供されていない場合は質問してください）:
1. 現在のチャーン状況
- 月間チャーンレートは？（自発的/非自発的の内訳が分かれば）
- アクティブなサブスクライバー数は？
- 顧客あたりの平均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: 解約後 期待値を設定し、簡単な再アクティブ化のパスを提供し、再獲得シーケンスを開始します。
出口調査の設計
出口調査は基本です。適切な理由カテゴリ:
| 理由 | それが示すもの |
|---|---|
| 高すぎる | 価格感度が高い。割引やダウングレードに反応する可能性 |
| 十分に使っていない | エンゲージメントが低い。一時停止やオンボーディングヘルプに反応する可能性 |
| 必要な機能がない | プロダクトギャップ。ロードマップや回避策を提示 |
| 競合他社に乗り換え | 競合圧力。彼らが何を提供しているか理解する |
| 技術的な問題/バグ | プロダクト品質。サポートにエスカレーション |
| 一時的/季節的なニーズ | 利用パターン。一時停止を提案 |
| ビジネス閉鎖/変更 | 回避不能。学び、潔く手放す |
| その他 | キャッチオール。自由記述欄を含める |
調査のベストプラクティス:
- 1つの質問、単一選択式（オプションで自由記述）
- 理由オプションは最大5〜8個（選択疲れを避ける）
- 最も一般的な理由を最初に配置（四半期ごとにデータを見直す）
- 罪悪感を与えるような印象にしない
- 「改善にご協力ください」というフレーミングが「なぜ去るのですか？」よりも効果的
動的セーブオファー
重要な洞察: オファーを理由にマッチさせること。 割引は、プロダクトを使っていない人を救いません。機能ロードマップは、それを買えない人を救いません。
オファーと理由のマッピング:
| 解約理由 | プライマリオファー | フォールバックオファー |
|---|---|---|
| 高すぎる | 割引（2〜3ヶ月間20〜30%オフ） | 低価格プランへのダウングレード |
| 十分に使っていない | 一時停止（1〜3ヶ月） | 無料オンボーディングセッション |
| 必要な機能がない | ロードマッププレビュー＋タイムライン | 回避策ガイド |
| 競合他社に乗り換え | 競合比較＋割引 | フィードバックセッション |
| 技術的な問題 | すぐにサポートにエスカレーション | クレジット＋優先修正 |
| 一時的/季節的 | サブスクリプションの一時停止 | 一時的なダウングレード |
| ビジネス閉鎖 | オファーをスキップ（状況を尊重） | — |
セーブオファーの種類
割引
- 2〜3ヶ月間の20〜30%オフが最適
- 50%以上の割引は避ける（顧客が割引を得るために解約する習慣がつく）
- オファーに期限を設定する（「このオファーはこのページを離れると失効します」）
- 割引率だけでなく、節約できる金額を表示する
サブスクリプションの一時停止
- 最大1〜3ヶ月の一時停止（長期の一時停止は再アクティブ化率が低い）
- 一時停止した人の60〜80%は最終的にアクティブに戻る
- 事前通知メール付きの自動再アクティブ化
- データと設定はそのまま保持
プランのダウングレード
- 完全解約の代わりに低いティアを提供
- 維持できるものと失うものを表示
- 「ダウングレード」ではなく「プランを適正化する」と位置付ける
- 準備ができたら簡単にアップグレードできるパスを用意
機能のアンロック/延長
- まだ試していないプレミアム機能をアンロック
- 上位ティアのトライアルを延長
- 「十分な価値を得られていない」という理由に最も効果的
パーソナルアウトリーチ
- 高価値アカウント（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）を構築:
Health Score = (
Login frequency score × 0.30 +
Feature usage score × 0.25 +
Support sentiment × 0.15 +
Billing health × 0.15 +
Engagement score × 0.15
)
| スコア | ステータス | アクション |
|---|---|---|
| 80-100 | 健全 | アップセルの機会 |
| 60-79 | 注意が必要 | プロアクティブなチェックイン |
| 40-59 | リスクあり | 介入キャンペーン |
| 0-39 | 重大 | パーソナルアウトリーチ |
プロアクティブな介入
解約を考える前に:
| トリガー | 介入 |
|---|---|
| 2週間、利用が50%以上減少 | 「[機能]をご利用いただいていないようですが、お手伝いしましょうか？」メール |
| プラン制限に近づいている | アップグレードのナッジ（壁ではない — ペイウォールアップグレードCROは別途対応） |
| 14日間ログインなし | 最近のプロダクトアップデートを伝える再エンゲージメントメール |
| NPSディトラクター（0-6） | 24時間以内の個別フォローアップ |
| サポートチケットが48時間以上未解決 | エスカレーション＋プロアクティブなステータス更新 |
| 年間更新まで30日 | バリューレキャップメール＋更新確認 |
非自発的チャーン: 支払いの回復
支払い失敗は全チャーンの30〜50%を引き起こしますが、最も回復しやすいものです。
ダニングスタック
事前ダニング → スマートリトライ → ダニングメール → 猶予期間 → 強制解約
事前ダニング（障害の防止）
- カード有効期限アラート: カード有効期限の30日、15日、7日前にメール送信
- バックアップ支払い方法: サインアップ時に第二の支払い方法を促す
- カード情報自動更新サービス: Visa/Mastercardの自動更新プログラム（ハードデクライナを30〜50%削減）
- 請求前通知: 年間プランの場合、請求の3〜5日前にメール送信
スマートリトライロジック
すべての失敗が同じとは限りません。拒否タイプ別のリトライ戦略:
| 拒否タイプ | 例 | リトライ戦略 |
|---|---|---|
| ソフトデクライナ（一時的） | 残高不足、プロセッサタイムアウト | 7〜10日間で3〜5回リトライ |
| ハードデクライナ（永続的） | カード盗難、口座閉鎖 | リトライしない — 新しいカード情報を求める |
| 認証が必要 | 3Dセキュア、SCA | 顧客に支払い情報の更新を依頼 |
リトライタイミングのベストプラクティス:
- リトライ1: 失敗から24時間後
- リトライ2: 失敗から3日後
- リトライ3: 失敗から5日後
- リトライ4: 失敗から7日後（ダニングメールのエスカレーションと共に）
- 4回のリトライ後: 再アクティブ化パスを備えた強制解約
スマートリトライのヒント: 支払いが元々成功した月の同じ日にリトライする（以前Day 1が機能した場合、Day 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 を参照してください。
指標と計測
主要チャーン指標
| 指標 | 計算式 | 目標 |
|---|---|---|
| 月間チャーンレート | 解約顧客数 / 月初顧客数 | B2C: <5%、B2B: <2% |
| 収益チャーン（ネット） | (失われたMRR - 拡大MRR) / 期初MRR | マイナス（ネット拡大） |
| 解約フローセーブ率 | 保存された解約 / 全解約セッション | 25-35% |
| オファー受諾率 | 受け入れられたオファー / 表示されたオファー | 15-25% |
| 一時停止からの再アクティブ化率 | 再アクティブ化 / 全一時停止 | 60-80% |
| ダニング回復率 | 回復した支払い / 全支払い失敗 | 50-60% |
| 解約までの時間 | 最初のチャーンシグナルから解約までの日数 | トレンドを追跡 |
コホート分析
チャーンを以下の基準でセグメント化:
- 獲得チャネル — どのチャネルが定着率の高い顧客をもたらすか？
- プランタイプ — どのプランが最もチャーンしているか？
- 継続期間 — 解約はいつ最も発生するか？（30日、60日、90日？）
- 解約理由 — どの理由が増加しているか？
- セーブオファータイプ — どのセグメントにどのオファーが最も効果的か？
解約フローのA/Bテスト
一度に一つの変数をテスト:
| テスト | 仮説 | 指標 |
|---|---|---|
| 割引率（20% vs 30%） | 高い割引ほどセーブ率が向上 | セーブ率、LTVへの影響 |
| 一時停止期間（1ヶ月 vs 3ヶ月） | 長期の一時停止で復帰率向上 | 再アクティブ化率 |
| 調査の配置（オファー前 vs オファー後） | 調査を先に行うとオファーがパーソナライズされる | セーブ率 |
| オファーの表示（モーダル vs 全画面） | 全画面の方が注目を集める | セーブ率 |
| コピーのトーン（共感的 vs 直接的） | 共感的な方が摩擦を減らす | セーブ率 |
解約フロー実験の実行方法: ab-test-setup スキルを使用して統計的に厳密なテストを設計します。PostHogは解約フロー実験に適しています。そのフィーチャーフラグはユーザーを異なるバリアントに分割できるからです。
メモと実装ノート
- これは生きたドキュメントです。チャーン防止戦略は、新しいデータや顧客からのフィードバックに基づいて定期的に見直し、更新する必要があります。
- 解約フローは決して「設定したら終わり」ではありません。継続的な最適化が必要です。
- 常に暗黙の解約理由と明示的な解約理由を考慮してください。顧客は必ずしも本当の理由を教えてくれるとは限りません。
- 倫理的なデザインを実践してください。顧客を騙して契約を維持させるようなグリットデザイン（抵抗感を生むデザインパターン）は避け、真の価値を提供することに注力してください。