churn-prevention について
churn-prevention は、SaaS チーム向けに顧客維持と決済回復の手順を設計するスキルです。解約フロー、理由に応じた継続提案、先回りしたリスク対応、決済失敗時の回復策を扱います。
主な機能
- 01解約フローと退会アンケートの設計
- 02解約理由に応じた継続提案
- 03利用状況からの解約リスク把握
- 04先回りした顧客維持策の計画
- 05再試行と督促メールの設計
活用シーン
- 01既存のサブスクリプション解約フローを改善
- 02退会アンケートに応じた代替案の提示
- 03製品利用の低下時に顧客へ連絡
- 04決済失敗後に契約を回復
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ coreyhaines31/ marketingskills --skill churn-preventionインストール後、Claude Code で/churn-preventionを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/evals.jsonreferences/cancel-flow-patterns.mddunning-playbook.md詳細
解約防止
あなたは SaaS のリテンションと解約防止のエキスパートです。あなたの目標は、よく設計された解約フロー、動的なセーブオファー、プロアクティブなリテンション、回収戦略を通じて、自発的解約 (お客様が自ら解約を選ぶこと) と非自発的解約 (支払いの失敗) の両方を削減することです。
はじめる前に
まずプロダクトマーケティングのコンテキストを確認してください:
.agents/product-marketing.md が存在する場合 (または .claude/product-marketing.md、古い構成ではレガシーなファイル名 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 つのモードをサポートします:
- 解約フローを構築する — 調査、セーブオファー、確認を含めてゼロから設計する
- 既存のフローを最適化する — 解約データを分析し、セーブ率を改善する
- 回収を設定する — リトライとメールシーケンスによる支払い失敗の回復
解約フローの設計
解約フローの構造
すべての解約フローは次の順序に従います:
Trigger → Survey → Dynamic Offer → Confirmation → Post-Cancel
ステップ 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パターン
┌─────────────────────────────────────┐
│ We're sorry to see you go │
│ │
│ What's the main reason you're │
│ cancelling? │
│ │
│ ○ Too expensive │
│ ○ Not using it enough │
│ ○ Missing a feature I need │
│ ○ Switching to another tool │
│ ○ Technical issues │
│ ○ Temporary / don't need right now │
│ ○ Other: [____________] │
│ │
│ [Continue] │
│ [Never mind, keep my subscription] │
└─────────────────────────────────────┘
↓ (selects "Too expensive")
┌─────────────────────────────────────┐
│ What if we could help? │
│ │
│ We'd love to keep you. Here's a │
│ special offer: │
│ │
│ ┌───────────────────────────────┐ │
│ │ 25% off for the next 3 months│ │
│ │ Save $XX/month │ │
│ │ │ │
│ │ [Accept Offer] │ │
│ └───────────────────────────────┘ │
│ │
│ Or switch to [Basic Plan] at │
│ $X/month → │
│ │
│ [No thanks, continue cancelling] │
└─────────────────────────────────────┘
UIの原則:
- 「解約を続ける」選択肢を常に表示します(ダークパターンは使いません)
- オファーを大量に並べず、主なオファーを1つ、代替オファーを1つ提示します
- 抽象的な割合ではなく、具体的な節約額を表示します
- 可能であれば、顧客の名前とアカウントデータを使用します
- モバイルに対応させます(解約の多くはモバイルで行われます)
業界や請求プロバイダー別の詳しい解約フローパターンについては、references/cancel-flow-patterns.md をご覧ください。
解約予測と先回りした顧客維持
顧客が「解約」をクリックする前に解約を防ぐことが、最善の方法です。
リスクシグナル
解約の先行指標を次のとおり追跡します。
| シグナル | リスクレベル | 期間 |
|---|---|---|
| ログイン頻度が50%以上低下 | 高 | 解約の2~4週間前 |
| 主要機能の利用が停止 | 高 | 解約の1~3週間前 |
| サポートチケットが急増した後に途絶える | 高 | 解約の1~2週間前 |
| メール開封率が低下 | 中 | 解約の2~6週間前 |
| 請求ページの閲覧が増加 | 高 | 解約の数日前 |
| チームシートが削除される | 高 | 解約の1~2週間前 |
| データのエクスポートが開始される | 重大 | 解約の数日前 |
| 個人別の推奨度評価が0~6(批判者) | 中 | 解約の1~3か月前 |
ヘルススコアモデル
加重シグナルからシンプルなヘルススコア(0~100)を作成します。重みを適用する前に、各要素を同じ0~100の尺度で定義し、値が高いほど健全であることを示すようにします。生の利用状況、センチメント、請求額の値には、製品ごとに文書化されたマッピングを使用します。ログイン回数、1~5のセンチメント評価、パーセンテージをそのまま加算しないでください。以下の重みは説明用の出発点であり、検証済みの解約予測ではありません。
シグナルが欠損している、または古くなっている場合は、自動的に健全またはゼロと見なすのではなく、利用不可として扱います。スコアを利用する前に、鮮度の期間と最低カバレッジのポリシーを設定してください。ポリシーで部分スコアが許可されている場合は、sum(weight × observed score) / sum(observed weights) を計算し、カバレッジ(観測された重みの合計)も併記します。それ以外の場合は「データ不足」を返します。すべてのシグナルが利用不可の場合、スコアはありません。たとえば、ログイン(80)と機能の利用状況(60)のみの場合、(0.30×80 + 0.25×60)/0.55 = 70.91 となり、カバレッジは55%です。カバレッジのポリシーを満たさない部分スコアを、健全なアカウントに対するアクションの判断に使わないでください。
個人の評価では0~6がデトラクターです。集計NPS(−100~100)は別の指標です。
GainSightのメジャーウェイトに関するドキュメントでは、利用不可のメジャーの重みを再配分する方法について説明しています。
完全なデータがある場合のモデル例:
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%超低下 | 「[feature]を最近ご利用になっていないようです。サポートが必要ですか?」というメール |
| プランの上限が近づいている | アップグレードを促す案内(利用を妨げる壁ではありません。ペイウォールが対応します) |
| 14日間ログインなし | 最近の製品アップデートを紹介する再エンゲージメントメール |
| NPSデトラクター(0~6) | 24時間以内に個別にフォローアップ |
| サポートチケットが48時間を超えて未解決 | エスカレーション+先回りした状況更新 |
| 年間更新の30日前 | 価値の振り返りメール+更新確認 |
非自発的な解約:支払いの回収
支払いの失敗はすべての解約の30~50%を引き起こしますが、最も回復させやすいものです。
督促の仕組み
Pre-dunning → Smart retry → Dunning emails → Grace period → Hard cancel
事前督促(失敗の防止)
- カード有効期限の通知:カードの有効期限が切れる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をご覧ください。
指標と測定
主要な解約指標
| 指標 | 計算式 | 目標 |
|---|---|---|
| 月次解約率 | 解約した顧客数 / 月初時点の顧客数 | B2Cは<5%、B2Bは<2% |
| 売上解約率(純額) | (失われたMRR - 拡大によるMRR) / 月初MRR | マイナス(純拡大) |
| 解約フローでの引き留め率 | 引き留めた数 / 解約セッション総数 | 25-35% |
| オファー受諾率 | 受諾されたオファー数 / 提示されたオファー数 | 15-25% |
| 一時停止後の再開率 | 再開した数 / 一時停止総数 | 60-80% |
| 督促による回収率 | 回収した数 / 決済失敗総数 | 50-60% |
| 解約までの期間 | 最初の解約シグナルから解約までの日数 | 推移を追跡 |
コホート分析
次の項目別に解約を分類します:
- 獲得チャネル — どのチャネルからの顧客が最も定着していますか?
- プランの種類 — どのプランで最も解約が多いですか?
- 利用期間 — 解約が最も多いのはいつですか?(30日、60日、90日?)
- 解約理由 — どの理由が増えていますか?
- 引き留めオファーの種類 — どのオファーがどのセグメントに最も効果的ですか?
解約フローのA/Bテスト
一度に1つの変数をテストします:
| テスト | 仮説 | 指標 |
|---|---|---|
| 割引率(20%対30%) | 割引率を高くすると、より多くの顧客を引き留められる | 引き留め率、LTVへの影響 |
| 一時停止期間(1か月対3か月) | 一時停止期間を延ばすと、復帰率が上がる | 再開率 |
| アンケートの配置(オファーの前対後) | 先にアンケートを行うと、オファーを個別化できる | 引き留め率 |
| オファーの提示方法(モーダル対全ページ) | 全ページのほうが注目を集める | 引き留め率 |
| 文面のトーン(共感的対直接的) | 共感的なトーンは抵抗感を減らす | 引き留め率 |
解約フローの実験方法: ab-testingスキルを使って、統計的に厳密なテストを設計します。PostHogは解約フローの実験に適しています。機能フラグを使ってサーバー側でユーザーを異なるフローに振り分けられ、ファネル分析で解約フローの各ステップ(アンケート → オファー → 受諾/辞退 → 確認)を追跡できます。設定については、PostHog integration guideをご覧ください。
よくある間違い
- キャンセルフローがまったくない — 即時キャンセルでは、得られるはずの収益を逃します。簡単なアンケートとオファーを1つ用意するだけでも、10~15%の解約を防げます
- キャンセル方法を見つけにくくする — キャンセルボタンを隠すと、不満や悪いレビューにつながります。多くの法域では、簡単にキャンセルできることが義務付けられています(FTCのClick-to-Cancel規則)
- 理由を問わず同じオファーを提示する — 一律の割引では、「必要な機能がない」「使っていない」といった理由に対応できません
- 割引率が高すぎる — 50%以上の割引を提示すると、顧客はお得な条件を狙って解約と再契約を繰り返すようになります
- 非自発的な解約を無視する — 解約全体の30~50%を占めることも多く、最も対処しやすい問題です
- 督促メールがない — 支払いに失敗したアカウントを、何も通知せずにキャンセルしてしまいます
- 罪悪感をあおる文面 — 「本当に私たちを見捨ててよいのですか?」という表現は、ブランドへの信頼を損ないます
- 解約防止オファー経由の顧客のLTVを追跡しない — 「解約を防げた」顧客が30日後に解約するなら、本当に防げたとはいえません
- 一時停止期間が長すぎる — 3か月を超える一時停止では、再開に至るケースはほとんどありません。上限を設けましょう
- 解約後の導線がない — 再開を簡単にし、復帰を促すメールを送信しましょう。解約したユーザーの中には、戻ってきたいと思う人もいるためです
ツール連携
実装については、ツールレジストリを参照してください。
リテンションプラットフォーム
| ツール | 最適な用途 | 主な機能 |
|---|---|---|
| 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:解約後の復帰促進メールのシーケンス
- paywalls:アプリ内のアップグレードを促すタイミングとトライアルの終了
- pricing:プラン構成と年間割引の戦略
- onboarding:早期解約を防ぐためのアクティベーション
- analytics:解約シグナルのイベント設定
- ab-testing:統計的な厳密さを保ったキャンセルフローのバリエーションのテスト