churn-prevention

解約防止

解約フローのアーキテクチャ、動的な継続特典のマッピング、退会アンケートの設計、督促シーケンスの設計、支払い回収の最適化、再獲得キャンペーン、解約の影響モデリングを網羅した、本番環境向けのSaaS解約削減フレームワークです。自発的な解約（顧客が自ら離脱を決めるケース）と非自発的な解約（支払い失敗により顧客が離脱するケース）の両方に対応します。

---

目次

• 初期評価
• 解約の分類
• 解約フローのアーキテクチャ
• 退会アンケートの設計
• 動的な継続特典システム
• 督促シーケンスの設計
• 再獲得キャンペーンのフレームワーク
• 解約リスクの健全性スコアリング
• 指標とベンチマーク
• 解約影響計算ツール
• 成果物
• 関連スキル

---

最初に確認すること

解約防止システムを設計する前に、以下の情報を確認してください。不明確な項目があれば、推測せずに質問してください。

• 自発的な解約と非自発的な解約の割合 — どちらが多いか（解約フローや継続特典を構築するか、督促や支払い回収に取り組むかが決まります）
• 既存の解約フローの有無、または即時解約／サポート経由の解約か — ゼロから構築するか、最適化するかが決まります
• 現在のMRR、ARPU、請求サイクル — 金額への影響と継続特典の予算規模を算出します
• 決済処理業者 — Stripe／Braintree／Paddle／Recurly（カード情報更新サービスや督促リトライの実装方法が決まります）

停止ルール：回答の内容に最も大きく影響する2～3項目だけを質問してください。ユーザーが「とりあえず草案を作って」と言った場合は作業を進め、成果物の冒頭に前提条件を記載してください。

初期評価

必要なコンテキスト

質問	重要な理由
現在の月次解約率はどのくらいですか？（自発的／非自発的な解約の内訳）	どの対策を講じるべきかが決まります
解約フローはありますか？それとも即時解約／サポート経由の解約ですか？	新規構築か最適化かが決まります
決済処理業者はどこですか？（Stripe、Braintree、Paddle）	督促の実装に影響します
平均契約額と請求サイクルはどのくらいですか？	継続特典の予算規模を算出します
現在のMRRはいくらですか？	解約削減による金額への影響を算出します
SaaSモデルは何ですか？（セルフサービス型／営業支援型）	介入の種類が決まります
現在、退会理由を収集していますか？	継続特典のマッピングに利用できるデータの有無を確認します

---

解約の分類

自発的な解約（顧客が自ら離脱を決める）

種類	シグナル	対応可能か
価値の不足	価格に見合う価値を得られていない	はい――継続特典、機能の活用案内
プロダクトと市場の不一致	適切なICPではない、製品が用途に合わない	一部可能――ダウングレードまたは方向転換
競合への乗り換え	より良い代替製品が見つかった	はい――競合対抗オファー
予算削減	もう支払えない	はい――割引または一時停止
プロジェクト完了	季節的、またはプロジェクトベースのニーズ	はい――一時停止の選択肢
利用体験の悪さ	サポートの質が低い、バグ、不満	はい――担当者による介入
利用開始に至らず	登録したが、一度も利用していない	一部可能――解約前に再利用を促す

非自発的な解約（支払い失敗）

原因	支払い失敗に占める割合	回収可能か
カードの有効期限切れ	40-50%	はい――カード情報更新サービス
残高不足	20-30%	はい――最適なタイミングでリトライ
銀行による拒否（不正利用の疑い）	10-15%	場合による――顧客が銀行に連絡する必要があります
アカウントの解約	5-10%	いいえ――顧客が新しいカードを登録する必要があります
ネットワークエラー	5-10%	はい――自動リトライ

---

解約フローのアーキテクチャ

5段階の解約フロー

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

ステージ1：解約の開始

• 解約オプションは見つけやすい場所に配置してください（Settings > Account > Cancel）。隠してはいけません。
• 「Cancel」をクリックするとフローが始まります。アカウントが即座に解約されるわけではありません。
• デスクトップとモバイルの両方で動作します。

ステージ 2：解約時アンケート（必須、1 問）

質問：「解約する主な理由は何ですか？」

ドロップダウンではなく、ラジオボタンで表示します。選択肢は最大 8 個です。

理由	内部コード
価格に対して得られる価値が少ない	PRICE
あまり利用していない	LOW_USAGE
必要な機能がない	MISSING_FEATURE
別の製品に乗り換える	COMPETITOR
プロジェクトやニーズが終了した	PROJECT_END
使い方が複雑すぎる	COMPLEXITY
試しただけで、継続するつもりはなかった	TESTING
その他（任意のテキスト入力欄あり）	OTHER

ルール：

• 解約阻止オファーを表示する前に、アンケートへの回答を必須にします（回答に応じてオファーが決まります）
• 質問は 1 つだけにします。複数ページにわたるアンケートは行いません。
• 「その他」には任意の自由記述欄を設け、どの選択肢にも補足として自由記述を追加できるようにします
• システム上の問題を特定するため、回答の分布を毎月追跡します

ステージ 3：動的な解約阻止オファー

解約理由ごとに、対応する解約阻止オファーを 1 つだけ設定します：

解約理由	解約阻止オファー	オファー文面
PRICE	2～3 か月間、30～50％割引	「今後 [N] か月間、[X]% 割引をご提供します」
LOW_USAGE	1～3 か月間、アカウントを一時停止	「アカウントを一時停止して、必要になったときに再開できます」
MISSING_FEATURE	ロードマップのプレビュー＋回避策	「[Feature] は [Q] に提供予定です。今すぐ実現する方法をご紹介します」
COMPETITOR	競合製品との比較＋割引	「[competitor] と当社の比較はこちらです。さらに [X]% 割引をご利用いただけます」
PROJECT_END	一時停止オプション	「解約する代わりに一時停止できます。データは安全に保管されます」
COMPLEXITY	無料のオンボーディングセッション	「設定はお任せください。チームとの 30 分間のセッションを無料でご利用いただけます」
TESTING	オファーなし。解約を受け入れる	「お試しいただきありがとうございます。またいつでもご利用をお待ちしています。」
OTHER	一般的な解約阻止オファー	「お手続きの前に、問題を解決するお手伝いをさせてください。[サポートに問い合わせる]」

オファーの表示ルール：

• 1 画面につき、明確なオファーを 1 つだけ表示します（複数の選択肢は表示しません）
• 価値を具体的な数値で示します。「割引を受ける」ではなく、「今後 3 か月で $120 節約できます」とします
• CTA は「オファーを受け入れる」と「解約を続ける」の両方を明確に表示します
• カウントダウンタイマーや偽の緊急性を使いません
• 罪悪感をあおる文面は使いません

ステージ 4：確認

解約阻止オファーを断った場合、またはオファーがない場合：

┌────────────────────────────────────────┐
│  We're sorry to see you go             │
│                                        │
│  What happens when you cancel:         │
│  - Your data is saved for 90 days     │
│  - Access continues until [date]      │
│  - You can reactivate anytime         │
│                                        │
│  [Yes, Cancel My Account]             │
│  [Wait, I Changed My Mind]            │
│                                        │
│  No pre-checked boxes.                │
│  No confusing language.               │
└────────────────────────────────────────┘

ステージ 5：解約後

タイミング	チャネル	メッセージ
直後	メール	解約確認＋データ保持ポリシー＋再開リンク
7 日目	メール	「寂しくなります」＋再開への CTA 1 つ＋利用できなくなる内容
30 日目	メール	製品アップデート＋関連する改善内容＋再開オファー
60 日目	メール	最も強力なオファーによる最後の利用再開の呼びかけ（該当する場合）

---

解約時アンケートの設計

データ分析フレームワーク

解約時アンケートの回答を毎月追跡し、次の値を算出します：

指標	計算式	対応のしきい値
理由の分布	理由ごとの解約割合	いずれかの理由が 30% 超なら、システム上の問題
理由別の解約阻止率	理由ごとの解約阻止数 / 解約試行数	いずれかの理由で解約阻止率が 5% 未満なら、オファーが適切でない
理由の傾向	前月比	増加傾向なら、問題が悪化
機能不足の頻度	具体的な機能名が記載された「必要な機能がない」の件数	不足している機能の上位 3 件を製品ロードマップに反映

解約時アンケートから得られる競合情報

ユーザーが「別の製品に乗り換える」を選択した場合：

• 追加質問として「どの製品に乗り換えますか？」と尋ねます（任意、自由記述またはドロップダウン）
• 解約したユーザーが乗り換える競合他社の上位 3 社を追跡します
• このデータを competitive-teardown スキルに取り込み、四半期ごとの分析に活用します

---

動的な解約阻止オファーシステム

オファーの経済性

オファーの種類	ビジネス側のコスト	継続率のベンチマーク	採算が取れる条件
30%割引（3か月）	3か月分の収益の30%	15-25%	継続後のLTVが割引コストを上回る場合
50%割引（2か月）	2か月分の収益の50%	20-30%	継続した顧客が6か月以上利用する場合
一時停止（1-3か月）	$0（一時停止中の収益なし）	25-40%	一時停止後に50%超が再開する場合
無料オンボーディングセッション	CSチームの対応時間（約$50-100）	10-20%	ARPUが月額$100を超える場合
下位プランへのダウングレード	収益の減少	30-50%	収益がゼロより少しでもある方がよい場合
機能のロック解除	$0（すでに開発済み）	5-15%	常に採算が取れる

継続オファーの判断ツリー

User selects exit reason →
├── PRICE →
│   ├── Customer ARPU > median? → Offer 30% discount
│   └── Customer ARPU < median? → Offer downgrade to cheaper plan
├── LOW_USAGE →
│   ├── Last login > 30 days? → Offer pause
│   └── Last login < 30 days? → Offer usage tips + discount
├── MISSING_FEATURE →
│   ├── Feature on roadmap? → Share roadmap + workaround
│   └── Feature not planned? → Offer discount or acknowledge gap
├── COMPETITOR →
│   ├── Known competitor? → Show comparison + retention offer
│   └── Unknown competitor? → General retention offer
├── PROJECT_END →
│   └── Always → Offer pause
├── COMPLEXITY →
│   ├── Enterprise/high-value? → Offer dedicated onboarding session
│   └── SMB/low-value? → Offer guided tutorial link
└── TESTING →
    └── Always → No offer, let go gracefully

---

督促シーケンスの設計

支払いの失敗は、解約全体の20-40%を占めます。その多くは、適切な督促によって回収できます。

スマートな再試行スケジュール

支払いに失敗した直後に再試行しないでください。カードの問題は、多くの場合3-7日以内に解決します。

再試行	タイミング	このタイミングの理由
初回請求	0日目	通常の請求サイクル
再試行1	3日目	カードの問題の大半は72時間以内に解決するため
再試行2	7日目	給料日のサイクルに合わせるため
再試行3	12日目	2回目の給料日サイクル
再試行4	18日目	サービスに対する措置を講じる前の最終試行
サービスに対する措置	21日目	ダウングレードまたはキャンセル

カード情報更新サービス

カードの有効期限切れによる解約を防ぐため、自動カード情報更新を有効にしてください。

決済処理業者	サービス	有効化方法
Stripe	カード情報の自動更新	ほとんどのプランでデフォルトで有効
Braintree	Account Updater	加盟店設定で有効にする必要があります
Paddle	組み込み機能	自動
Recurly	Account Updater	設定が必要

督促メールのシーケンス

日	件名	本文の要点	CTA
0	「[Product]のお支払いが完了しませんでした」	事実を伝え、責めないようにします。カードの有効期限切れや残高不足の可能性があります。	[支払い方法を更新]
3	「要対応：[Product]のお支払い方法を更新してください」	利用できなくなるものを伝えます。	[支払い方法を更新]
7	「[Product]のアカウントが利用できなくなる可能性があります」	作成した機能やデータを列挙します。やや緊急性を持たせます。	[支払い方法を更新]
14	「最終通知：[Product]の利用は7日後に終了します」	期限を明確に伝えます。銀行側の問題であればサポートすることを案内します。	[支払い方法を更新] + [サポートに問い合わせる]
21	「[Product]のアカウントが一時停止されました」	アカウントの状態変更を伝えます。データは安全で、簡単に再開できます。	[アカウントを再開]

メールのルール：

• すべてのメールから、支払い方法の更新ページに直接リンクします（ダッシュボードではありません）。
• 罪悪感を与えたり、恥をかかせたりしないでください。カードの支払い失敗は起こり得ます。
• 件名は具体的にし、製品名を含めます。
• 未払い金額とカード番号の下4桁を記載します。
• サポートが必要な顧客向けに、問い合わせ先を用意します。

---

再獲得キャンペーンのフレームワーク

再獲得のタイミング

期間	成功率	アプローチ
解約後7日目	5-10%	プレッシャーをかけず、さりげなくリマインドする
解約後30日目	3-7%	製品のアップデートとオファー
解約後60日目	2-5%	最も強力なオファーと新たなスタート
解約後90日以降	1-3%	大幅な製品変更があった場合のみ

再獲得メールのシーケンス

7日目のメール：

• 件名：「[Product]のアカウントがお待ちしています」
• 本文：利用をやめたことで残してきたもの（データ、プロジェクト、チーム）を伝えます。CTAは再開の1つだけです。
• 割引はありません。価値を改めて伝えるだけです。

30日目のメール：

• 件名：「[Product]の新機能をご紹介します」
• 本文：利用をやめてから加わった具体的な改善点を2-3件紹介します。CTAは再開の1つだけです。
• 少額の特典：「1か月無料で再開できます」

60日目のメール：

• 件名：「ぜひまたご利用ください -- [offer]」
• 本文：最も強力なオファー（3か月間50%オフ、または無料期間の延長）を提示し、明確な期限を設けます。
• 重要な内容を伝える最後のアプローチです。

---

解約リスクの健全性スコアリング

解約の先行指標

シグナル	重要度	検出方法
ログイン頻度の低下（週ごとの比較）	高	利用状況分析
機能の利用状況の低下	高	機能イベントの追跡
サポートチケットのエスカレーション	高	ヘルプデスクのデータ
NPS の回答が 7 未満	高	アンケートデータ
請求に関する異議申し立て、または支払いに関する問い合わせ	中	請求システム
推進者が退職	高	連絡先のモニタリング
契約更新まで 90 日未満	中	CRM データ
競合他社の評価を検知	高	営業インテリジェンス

リスクスコアの計算

Risk Score = Sum of (Signal Weight x Signal Present)

0-20: Low risk (monitor)
21-40: Moderate risk (proactive outreach)
41-60: High risk (intervention required)
61+: Critical risk (executive escalation)

---

指標とベンチマーク

主要指標

指標	計算式	良好	優秀
解約阻止率	解約を阻止した顧客数 / 解約試行数	10-15%	20%+
自発的解約率	自発的な解約数 / 顧客総数（月次）	< 3%	< 1.5%
非自発的解約率	支払い失敗による解約数 / 顧客総数（月次）	< 1.5%	< 0.5%
支払い回収率	回収できた支払い失敗件数 / 支払い失敗総数	25-35%	40%+
再獲得率	再開数 / 解約数（90 日間）	5-10%	10%+
解約時アンケート回答率	アンケート回答数 / 解約試行数	> 70%	> 90%
解約阻止オファー受諾率	受諾されたオファー数 / 表示されたオファー数	15-25%	30%+

注意すべき兆候

シグナル	診断	対応
解約阻止率 < 5%	オファーが解約理由に合っていない	オファーと理由の対応関係を再構築
解約時アンケート回答率 < 60%	アンケートが長すぎる、または任意になっている	必須にし、質問を 1 つにする
回収率 < 20%	再試行ロジックまたはメールに問題がある	督促シーケンスを監査
単一の理由が > 40%	製品または価格設定に根本的な問題がある	製品部門または経営陣にエスカレーション
月次解約率 > 5%	事業が縮小している可能性が高い	解約防止だけでは解決できません。ICP と製品を見直してください

---

解約影響計算ツール

概算

Monthly MRR at risk = Total MRR x Monthly churn rate
Annual MRR saved by 1% churn reduction = Total MRR x 0.01 x 12
Annual MRR saved by 20% save rate = (Monthly MRR at risk x 0.20) x 12

Example:
  MRR: $500,000
  Monthly churn: 4% = $20,000/month lost
  Reduce to 3% = $5,000/month saved = $60,000/year
  Add 20% save rate on remaining = $3,000/month saved = $36,000/year
  Total annual impact: $96,000

---

成果物

成果物	形式	説明
解約フロー設計	5 段階のフローと文言	トリガーから解約後までの完全なフロー
解約時アンケート	ラジオボタンの選択肢と対応付け	解約理由 6～8 件と解約阻止オファーの対応付け
解約阻止オファーシステム	決定木	経済性を考慮した、理由とオファーの対応付け
督促シーケンス	5 通のメールシーケンス	件名、本文、送信タイミング、再試行スケジュール
再獲得キャンペーン	3 通のメールシーケンス	7 日目、30 日目、60 日目に送る、件名とオファー付きのメール
解約スコアカード	指標テーブル	現在の指標とベンチマークを比較し、ギャップを分析
影響モデル	収益計算	さまざまな改善レベルでの解約削減による金額への影響

---

関連スキル

• customer-success-manager -- 健康度スコアリング、QBR、収益拡大に使用します。解約フローや督促の設計には使用しません。
• pricing-strategy -- 解約の根本原因が価格設定やパッケージの不一致である場合に使用します。解約阻止オファーの設計には使用しません。
• onboarding-cro -- 解約の原因がアクティベーションの不備にある場合に使用します。ユーザーが価値を一度も実感していない場合は、まずオンボーディングを改善してください。
• referral-program -- 顧客獲得に使用します。解約防止はファネルの反対側を担います。

---

ツールリファレンス

1. churn_impact_calculator.py

目的： さまざまな改善レベルで、解約削減が収益に与える影響を計算します。

python scripts/churn_impact_calculator.py --mrr 500000 --churn-rate 4.0 --save-rate 20
python scripts/churn_impact_calculator.py --mrr 500000 --churn-rate 4.0 --save-rate 20 --json

フラグ	必須	説明
--mrr	はい	現在の月次経常収益（ドル）
--churn-rate	はい	現在の月次解約率（パーセント）。例：4% の場合は 4.0
--save-rate	いいえ	解約フローの解約阻止率（パーセント、デフォルト：15）
--target-churn	いいえ	目標解約率（パーセント、デフォルト：現在の解約率から 1 を引いた値）
--json	いいえ	結果を JSON として出力

2. dunning_sequence_analyzer.py

目的： 請求催促メールシーケンスの効果を分析し、再試行タイミングの最適化を提案します。

python scripts/dunning_sequence_analyzer.py dunning_data.json
python scripts/dunning_sequence_analyzer.py dunning_data.json --json

フラグ	必須	説明
dunning_data.json	はい	支払い失敗データと再試行データを含む JSON ファイル
--json	いいえ	結果を JSON 形式で出力します

入力 JSON 形式：

{
  "failed_payments": [
    {
      "payment_id": "PAY-001",
      "amount": 99.00,
      "failure_reason": "expired_card",
      "retry_attempts": [
        {"day": 0, "recovered": false},
        {"day": 3, "recovered": false},
        {"day": 7, "recovered": true}
      ]
    }
  ]
}

3. exit_survey_analyzer.py

目的： 解約アンケートの回答を分析し、チャーンのパターン、解約防止オファーの効果、システム上の問題を特定します。

python scripts/exit_survey_analyzer.py survey_data.json
python scripts/exit_survey_analyzer.py survey_data.json --json

フラグ	必須	説明
survey_data.json	はい	解約アンケートの回答データを含む JSON ファイル
--json	いいえ	結果を JSON 形式で出力します
--period	いいえ	分析期間のラベル（デフォルト："current"）

---

トラブルシューティング

問題	考えられる原因	解決策
すべての理由で解約防止率が 5% 未満	解約防止オファーが解約理由に合っていません	アンケートデータを使って解約理由とオファーの対応付けを再構築し、exit_survey_analyzer.py を実行して不一致を特定します
解約アンケートの回答完了率が 60% 未満	アンケートが任意、または長すぎます	解約防止オファーを表示する前に、1 問だけのアンケートへの回答を必須にします。複数ページのフローは削除します
支払い回収率が 20% 未満	再試行ロジックの設定に誤りがあるか、請求催促メールが送信されていません	dunning_sequence_analyzer.py で請求催促シーケンスを監査します。メールの到達性と再試行スケジュールを確認します
1 つの解約理由が回答の 40% を超える	プロダクトまたは価格設定にシステム上の問題があります	プロダクトチームまたは経営陣にエスカレーションします。これは解約フローだけでは解決できません
月間チャーン率が 5% を超える	ICP、プロダクトマーケットフィット、または価格設定に問題がある可能性があります	チャーン防止だけでは解決できません。価格戦略およびプロダクトフィードバックのループと組み合わせてください
解約防止メールからの再有効化がゼロ	メールが受信トレイに届いていないか、オファーに訴求力がありません	メールの到達性（SPF、DKIM、DMARC）を確認します。より魅力的なオファーをテストし、再有効化リンクが機能することを確認します
自発的チャーンが安定している一方で、非自発的チャーンが増加している	カード情報更新機能が有効になっていないか、再試行のタイミングが適切ではありません	決済プロセッサーでカード情報の自動更新を有効にします。dunning_sequence_analyzer.py で再試行スケジュールを確認します

---

成功基準

• 月間自発的チャーン率が 2.5% 未満（1.5% 未満なら優秀）
• 月間非自発的チャーン率が 1.0% 未満（0.5% 未満なら優秀）
• 解約フローの解約防止率が 15～25%（20% を超えれば優秀）
• 支払い失敗に対する支払い回収率が 30% 以上
• 解約アンケートの回答完了率が 80% 超
• 解約後 90 日以内の解約顧客再有効化率が 5～10%
• 解約防止オファーの受諾率が 20% 超で、受諾した顧客がその後 6 か月以上継続

---

対象範囲と制限事項

• 対象範囲： 解約フローの設計、解約アンケートの構成、解約防止オファーの対応付け、請求催促シーケンス、支払い回収、再獲得キャンペーン、チャーンの影響モデリング
• 対象外： プロダクトマーケットフィット分析、価格設定の再構築、ICP の再定義、顧客獲得
• データ依存関係： スクリプトは JSON 入力の特定時点のスナップショットを分析します。リアルタイムの CRM 連携はありません
• 予測型 ML ではありません： すべてのスコアリングは決定論的なアルゴリズムに基づいており、機械学習モデルは使用しません
• 法的注意事項： 解約フローは FTC ガイドライン（米国）および消費者保護法（EU）に準拠する必要があります。解約を不当に困難にしてはいけません
• 収益の見積もり： 影響の計算は入力された前提に基づく予測であり、保証ではありません

---

統合ポイント

• customer-success-manager -- ヘルススコアを解約リスク評価に反映し、解約データを使用してヘルススコアのしきい値を調整します
• pricing-strategy -- 解約時アンケートのデータでPRICEが主な理由（>30%）と示された場合、価格体系の見直しのためpricing-strategyにエスカレーションします
• onboarding-cro -- 解約時アンケートのデータでLOW_USAGEまたはCOMPLEXITYが主な理由と示された場合、根本原因は多くの場合、アクティベーションの不備です。まずオンボーディングを改善します
• revenue-operations -- パイプラインと予測モデルでは、純収益維持率（NRR）に対する解約削減の影響を考慮する必要があります
• referral-program -- 継続利用を90日間続けた後、引き留め施策で継続した顧客は、紹介プログラムへの登録候補となります