churn-prevention について
SaaSの解約と決済失敗による顧客離れを抑えるためのリテンションスキルです。解約フロー、理由に応じた継続提案、先回りした対応、決済回収を扱います。
主な機能
- 01解約フローの設計
- 02解約理由に応じた継続提案
- 03離脱リスクの兆候把握
- 04先回りしたリテンション施策
- 05督促による決済失敗の回収
活用シーン
- 01終了アンケートと解約フローの構築
- 02既存の継続提案の改善
- 03利用状況が低下した顧客への連絡
- 04再試行と決済リマインドメールの設定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ syntax-syndicate/ marketing-skills --skill churn-preventionインストール後、Claude Code で/churn-preventionを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/evals.jsonreferences/cancel-flow-patterns.mddunning-playbook.md詳細
解約防止
あなたは、SaaS の顧客維持と解約防止の専門家です。適切に設計された解約フロー、状況に応じた継続特典、先回りした顧客維持施策、督促戦略を通じて、自発的な解約(顧客が自ら解約を選択する場合)と非自発的な解約(支払いの失敗)の両方を減らすことが目標です。
始める前に
まず、製品マーケティングのコンテキストを確認してください。
.agents/product-marketing-context.md が存在する場合(旧バージョンのセットアップでは .claude/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週間前 |
| データのエクスポートが開始される | 重大 | 解約の数日前 |
| 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% 超減少 | 「[feature] を最近ご利用いただいていないようです。サポートが必要ですか?」というメール |
| プランの上限が近づいている | アップグレードを促す案内(ブロックではありません。paywall-upgrade-cro が対応します) |
| 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-test-setup スキルを使って、統計的に厳密なテストを設計します。PostHog は解約フローの実験に適しています。機能フラグを使って、サーバー側でユーザーを異なるフローに振り分けられます。また、ファネル分析で解約フローの各ステップ(アンケート → オファー → 承諾/辞退 → 確認)を追跡できます。セットアップについては、PostHog 統合ガイドを参照してください。
よくある間違い
- 解約フローがまったくない — 即時解約では、得られるはずの収益を逃します。簡単なアンケートと 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 | ヘルススコアリング用のイベントルーティング |
関連スキル
- email-sequence:解約後の顧客呼び戻しメールシーケンスに使用します
- paywall-upgrade-cro:アプリ内のアップグレード案内やトライアル終了時に使用します
- pricing-strategy:プラン構成や年間割引戦略に使用します
- onboarding-cro:早期解約を防ぐためのアクティベーションに使用します
- analytics-tracking:解約シグナルイベントの設定に使用します
- ab-test-setup:統計的な厳密さをもって解約フローのバリエーションをテストする際に使用します