marketing-retention について
サブスクリプション事業者向けの顧客維持戦略スキルです。解約分析、決済失敗の回収、顧客の再獲得を扱い、顧客行動のシグナルとブランド戦略に基づいて解約フローや健全度スコアを設計します。
主な機能
- 01解約診断とコホート分析
- 02解約フローと退出アンケート設計
- 03理由に合わせた維持オファー
- 04顧客健全度スコアの指針
- 05決済回収と再獲得の計画
活用シーン
- 01顧客セグメント別の解約診断
- 02解約フローとオファーの設計
- 03リスク顧客への先回りした連絡
- 04決済失敗の回収施策の計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ gnoviawan/ agentic-marketing --skill marketing-retentionインストール後、Claude Code で/marketing-retentionを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/benchmarks.mdcancel-flow-templates.mdframeworks-index.csvresearch-playbook.mdshared-patterns.mdreferences/frameworks/cancel-confirmation-copy.mdcancel-flow-ab-testing.mddunning-email-sequence.mddynamic-offer-templates.mdexit-survey-copy.mdoffer-decision-tree.mdproactive-retention-emails.mdsubject-line-reference.mdwin-back-email-sequence.md詳細
リテンションと解約防止のスペシャリスト
解約フローの設計、先回り型の健全性スコアリング、決済の回収、督促シーケンス、再獲得キャンペーンに関する深い専門知識を持つ、シニアリテンションストラテジストです。サブスクリプション型ビジネス(SaaS、会員制サービス、EC サブスクリプション)と連携し、非自発的・自発的な解約を減らし、決済に失敗した売上を回収し、解約済みの顧客に再びアプローチします。ブランドの SOSTAC 計画と実際の顧客行動シグナルに基づいた、実行可能でデータ主導のリテンション施策を提供します。
開始時のコンテキスト振り分け
3 つの標準モード(白紙の状態、コードベース、ライブ URL)については、
./references/shared-patterns.md § Starting Context Routerを参照してください。ユーザーの開始地点に合ったモードを適用してから、以下のスペシャリスト向けワークフローに進んでください。
0. 事前確認:戦略的コンテキストを読む
標準的なコンテキストの読み込み手順については、
./references/shared-patterns.md § Pre-Flightを参照してください。すべての提案は、まずブランドのポジショニングに基づいて作成し、それがない場合は既存のコードベースまたはライブページに基づいてください。
パスの解決:キャンペーンか、単独施策か
キャンペーンモード — 名前の付いたキャンペーンの一環として作業する場合:
→ ./brands/{brand-slug}/campaigns/{type}-{campaign-slug}/retention/ に保存します
→ キャンペーン戦略を ./brands/{brand-slug}/campaigns/{type}-{campaign-slug}/strategy.md から読み込みます
単独施策モード — 常設または独立した作業の場合:
→ ./brands/{brand-slug}/operations/retention/ に保存します
レガシーフォールバック — 古いディレクトリ構造が検出された場合:
→ ./brands/{brand-slug}/campaigns/retention/ に保存します
→ 新しい構造への移行を提案します
どちらのモードか不明な場合は、「特定のキャンペーンの一環ですか、それとも単独施策ですか?」と尋ねてください。
リサーチモード:競合情報とベンチマーク情報のリアルタイム調査
最新の情報が必要な場合は、agent-browser を使って、競合他社の解約フロー、督促のパターン、業界ベンチマークに関する最新データを収集してください。競合他社の解約フローの詳細な調査、Churnkey/ProsperStack の機能調査、督促メールのパターン分析、Baremetrics のベンチマーク抽出、Stripe Smart Retry のドキュメント調査に対応します。
セットアップ: インストール手順については、
./references/shared-patterns.md § agent-browser Setupを参照してください。
agent-browser のコマンドとセッションのワークフロー全体については、./references/research-playbook.md を参照してください。
1. 解約の診断
リテンション施策を設計する前に、どのような解約が発生しているのか、その理由を把握してください。診断前に解決策を提案することは、リテンションで最もよくある間違いです。
1.1 解約の種類
| 種類 | 定義 | 主な原因 | 回復アプローチ |
|---|---|---|---|
| 自発的(能動的) | 顧客が意図的に解約する | 価値認識、機能不足、競合他社、価格 | 解約フロー、先回り型のリテンション、再獲得 |
| 非自発的(受動的) | 決済に失敗し、アカウントが失効する | カードの有効期限切れ、残高不足、銀行によるブロック | 督促シーケンス、Smart Retry、カード情報の自動更新 |
| 暗黙的 | 顧客が利用をやめても、解約はしない | エンゲージメント低下、オンボーディングの不備、利用習慣が定着していない | 健全性スコアリング、先回りした働きかけ |
| 契約期間満了 | 期間が定められた契約が終了し、更新されない | 更新に向けた対話がない、継続的な価値提供の不足 | QBR、更新プレイブック、アップセル提案 |
非自発的な解約は、SaaS の解約全体の 30~50%を占め、最も回復率の高いカテゴリーです。まず対処してください。
1.2 解約率の計算
月次解約率(顧客数)
(Customers lost in period / Customers at start of period) x 100
目標:SMB SaaS では 2%未満、エンタープライズ SaaS では 0.5%未満、コンシューマー向けサブスクリプションでは 5%未満。
月次売上解約率(MRR 総解約率)
(MRR lost to cancellations + downgrades in period / MRR at start of period) x 100
目標:月次の MRR 総解約率を 1.5%未満にします。
売上継続率(NRR)
((Starting MRR + Expansion MRR - Contraction MRR - Churned MRR) / Starting MRR) x 100
目標:100%超(拡大分が解約分を上回ること)。クラス最高水準の SaaS では 120~140%です。
売上解約率と顧客解約率:料金プランの階層がある場合、この 2 つの数値には大きな差が生じます。エンタープライズ顧客の解約率が SMB 顧客より低ければ、売上解約率は顧客解約率より低くなります。これは健全な状態です。顧客コホートと料金プランの種類別に、両方の指標をセグメント化してください。
1.3 コホート維持率分析
登録コホート別(月次または四半期ごと)に維持率曲線を作成し、オンボーディングの失敗、プロダクトマーケットフィットのセグメント、傾向の方向性を特定します。常にプランの階層、獲得チャネル、アクティベーション状況、地域別にセグメント化してください。
コホート表の完全なテンプレート、解釈ガイド、セグメント化の方法については、./references/benchmarks.md Section 1 を参照してください。
1.4 解約原因の特定
利用可能なすべてのシグナルを使用します。次の順に優先してください。
定性的(直接的なフィードバック)
- キャンセルフローの解約アンケートデータ(自発的な解約を把握するうえで最も信頼性が高い)
- カスタマーサクセスの通話メモとサポートチケットの傾向
- NPS の批判的評価者による自由記述の回答
- 最近解約した顧客への直接的な連絡(解約後 7 日以内にメールまたは電話で連絡)
定量的(行動シグナル)
- 機能の利用率:解約した顧客はどの機能を使用していないか?
- 解約前 30~60 日間のログイン頻度の推移
- サポートの利用状況:解約した顧客のチケット数は多いか?未解決のチケットはあるか?
- 請求イベント:解約した顧客のうち、少なくとも 1 回の支払い失敗があった顧客は何人か?
- 解約コホートと継続コホートのオンボーディング完了率
ビジネスタイプ別の一般的な解約原因:
| ビジネスタイプ | 主な解約原因 |
|---|---|
| SaaS(SMB) | 価格への敏感さ、製品の定着度不足、競合への乗り換え、不十分なオンボーディング |
| SaaS(Enterprise) | 契約更新の優先度が低い、関係者の変更、予算削減、導入の失敗 |
| 消費者向けサブスクリプション | 登録していたことを忘れた、季節的な需要、価格、キャンセルを忘れた |
| E コマースのサブスクリプション | 製品の品質、品ぞろえへの飽き、価格と価値の不釣り合い、不要になった |
2. キャンセルフローの設計
適切に設計されたキャンセルフローは、キャンセルを希望する顧客の 25~35%を引き留めます。これは操作ではなく、恒久的な決断をする前に、顧客が本当に求めている可能性のある情報、選択肢、オファーを提供することです。
2.1 キャンセルフローのアーキテクチャ
Cancel button --> [Pause Gate] --> [Exit Survey (4-6 reasons)] --> [Dynamic Offer (reason-matched)]
--> Accept: confirm save, update billing/plan
--> Decline: [Confirmation Page] graceful exit (data export, community, support)
--> [Post-Cancel Sequence] win-back emails start (Section 5)
確認ページの全文とキャンセル後のメールについては、./references/frameworks/cancel-confirmation-copy.md を参照してください。オファーの判断ツリーについては、./references/frameworks/offer-decision-tree.md を参照してください。
2.2 解約アンケートの設計
原則:
- 選択肢は最大 4~6 個にします。6 個を超えると、アンケート疲れが生じ、データ品質が低下します。
- 最後の選択肢として、任意のテキスト入力欄を付けた「その他」を含めます。
- アンケートを必須にしないでください。顧客が回答をスキップした場合は、そのままキャンセルできるようにします。回答を強制すると、不満を生みます。
- 選択肢は誠実で、顧客を責めないものにします。操作を目的に設計された選択肢は、顧客に気づかれます。
- アンケートデータを活用します。収集しても何も変えないのであれば、形だけの取り組みです。
推奨する選択肢(ブランドのトーンに合わせて文言を調整してください):
| # | 理由のラベル | データの活用方法 |
|---|---|---|
| 1 | 料金が高すぎます | 割引または一時停止のオファーを提示 |
| 2 | あまり利用していません | 利用方法の案内と一時停止のオファーを提示 |
| 3 | 必要な機能がありません | ロードマップに関する説明を提示 |
| 4 | 競合他社に乗り換えます | 差別化の説明と比較情報を提示 |
| 5 | 技術的な問題がありました | 直ちにサポートへエスカレーション |
| 6 | その他 | テキスト入力欄へ誘導し、一般的なオファーを提示 |
各選択肢の正確なマイクロコピーについては、./references/frameworks/exit-survey-copy.md を参照してください。
2.3 動的なオファーのロジック
申し出の内容を、提示された理由に正確に合わせます。すべての解約理由に同じオファーを提示すると、理由に合わせたオファーよりも大幅に効果が下がります。
| 理由 | 主なオファー | 代替案 |
|---|---|---|
| 料金が高すぎる | 3か月間の20-30%割引、または恒久的なプランのダウングレード | 1-3か月の一時停止 |
| 利用頻度が低い | 無料の1対1オンボーディングセッション+一時停止オプション | 利用のヒント+リソースハブ |
| 必要な機能がない | 不足している点を認め、正直に伝えられる場合はロードマップの予定を共有し、回避策を提案する | 機能のリリースまで一時停止 |
| 競合サービスへの乗り換え | 機能の直接比較、差別化ポイントの説明、導入事例 | 再検討のための1か月無料 |
| 技術的な問題 | シニアサポートへの即時エスカレーション+アカウントクレジット | 問題解決まで無料期間を延長 |
| その他 | マネージャーからの折り返し、または自由回答形式の「継続するには何があればよいですか?」 | 通常の割引または一時停止 |
オファーの価値に基づく優先順位:
- 一時停止(費用がかからず、関係を維持し、考える時間を確保できます)
- ダウングレード(収益は減りますが、顧客を維持できます)
- 期間限定割引(3か月間の特典後、通常料金に戻ります)
- 無料延長(1か月無料で、解約を30日先延ばしにします)
- 機能の利用権(現在の料金のまま、上位プランの機能を利用可能にします)
**重要なルール:**すべてのオファーを一度に提示するのではなく、提示された理由に最も合うオファーを1つだけ表示します。複数のオファーを同時に提示すると、承諾率が下がり、顧客にお得な条件を探すよう学習させてしまいます。例外:解約理由が曖昧な場合は、2つの選択肢(例:一時停止またはダウングレード)を提示すると、1つだけ推測して提示するより効果的なことがあります。
2.4 解約阻止率のベンチマーク
| 指標 | 目標 | 業界最高水準 |
|---|---|---|
| 解約フロー表示率 | 解約を希望する顧客の80%+にフローを表示 | 90%+ |
| アンケート完了率 | 表示回数の60-70% | 75%+ |
| 解約阻止率(全手法) | 解約を希望する顧客の25-35% | 35-45% |
| オファー承諾率 | オファー表示回数の15-25% | 25-35% |
| 一時停止の利用率(提示した場合) | 10-20% | 20-30% |
2.5 解約フローのツール
| ツール | 最適な用途 | 価格帯の目安 |
|---|---|---|
| Churnkey | SaaS、解約フロー全体+督促、スマートオファー | ミッドマーケット |
| ProsperStack | SaaS、高度なカスタマイズ、A/Bテスト | ミッドマーケット |
| Chargebee Retention | Chargebeeの課金機能を利用するユーザー、ネイティブ連携 | エンタープライズ |
| 独自開発 | 完全な制御が可能、エンジニアリングリソースが必要 | 任意 |
| Stripe Portal | 基本機能のみ、動的なオファーのロジックなし | Stripe利用時は無料 |
専用の解約フローツールを使わずStripeを利用しているブランドには、Churnkeyが直接連携し、オファーのロジック層を追加します。ChargebeeまたはRecurlyを利用しているブランドは、まず各サービスのネイティブな解約防止モジュールを使用してください。
2.6 解約フローのコピーとUXの原則
- **ダークパターンは絶対に使わないでください。**解約ボタンを隠したり、電話を必須にしたり、罪悪感をあおる表現(「すべてを失います!」)を使ったりしてはいけません。こうした方法は信頼を損ない、公開の苦情を招きます。
- **トーンは、必死ではなく親切に。**解約フローは交渉の場ではなく、カスタマーサービスの一環です。
- **モバイルファースト。**解約のかなりの割合はモバイルで発生します。フロー全体をスマートフォンでテストしてください。
- **ステップごとに1画面。**退出アンケートとオファーを同じ画面にまとめないでください。
- **顧客の決定を尊重する。**オファーを断られた場合は、ただちに解約を完了してください。追加の手間がかかる画面を表示してはいけません。
3. 積極的な解約防止
最も効果的な解約防止は、顧客が「解約」をクリックする前に行われます。解約リスクのある顧客を早期に特定し、適切なタイミングで適切なメッセージを送り、そもそも解約の意向が生まれないようにします。
3.1 顧客ヘルススコア
アクティブなすべてのアカウントについて、ヘルススコアを作成します。シグナルには、特定の製品における解約との相関関係に基づいて重みを割り当てます。以下のフレームワークは出発点です。自社のデータに照らして調整してください。
エンゲージメントシグナル(最大40ポイント)
| シグナル | 良好 | 要注意 | 重み |
|---|---|---|---|
| ログイン頻度 | ベースラインに沿って安定 | ベースラインを30%以上下回る減少 | 15 pts |
| コア機能の利用状況 | 主要機能を毎週利用 | 14日間、コア機能の利用なし | 15 pts |
| セッションの深さ | 1回のセッションで3つ以上の機能を利用 | 1つの機能だけを利用するセッションのみ | 10 pts |
関係性シグナル(最大30ポイント)
| シグナル | 良好 | 要注意 | 重み |
|---|---|---|---|
| サポートチケット | なし、または迅速に解決 | 7日以上未解決のチケットあり | 10 pts |
| NPS/CSATスコア | 推奨者(9~10)または中立者(7~8) | 批判者(0~6) | 10 pts |
| カスタマーサクセスとのエンゲージメント | 定期的に連絡を取り、応答がある | 直近2回の連絡に返信なし | 10 pts |
ビジネスシグナル(最大30ポイント)
| シグナル | 良好 | 要注意 | 重み |
|---|---|---|---|
| シート数/利用状況の拡大 | 増加または安定 | シートの削減または利用状況の縮小 | 15 pts |
| 請求先担当者の変更 | 変更なし | 請求先担当者が交代 | 5 pts |
| 契約状況 | 有効で、次回更新が確定 | 更新日の60日前になっても更新が未確定 | 10 pts |
ヘルススコアの段階:
| 段階 | スコア範囲 | 状態 | アクション |
|---|---|---|---|
| 緑 | 70-100 | 良好 | 拡大に注力する。アップセル、紹介、推奨を促す |
| 黄 | 40-69 | 要注意 | チェックインの一連の連絡を開始し、サクセス支援を提案する |
| 赤 | 0-39 | 高リスク | すぐに連絡し、高価値アカウントの場合は経営幹部にエスカレーションする |
3.2 リスクシグナルのモニタリング
次のシグナルがしきい値を超えたときに、自動アラートが送信されるよう設定します。
即時アラート(24時間以内に連絡を開始)
- 14日間ログインがない(製品の種類に応じて調整してください。利用頻度の低いツールでは期間を変更します)
- サポートチケットが5日以上未解決
- NPSで批判者のスコアが送信された
- 請求先担当者が変更された
週次モニタリングのトリガー
- ログイン頻度が前週比で30%を超えて減少する状態が2週連続で続いた
- 過去7日間、コア機能の利用がゼロになった
- 1週間でヘルススコアが20ポイント以上低下した
30日間の傾向アラート
- これまで拡大していた複数シート製品で、チームが拡大していない
- 1回だけのセッションによるログインが繰り返されている(ログインして、少し見て、ログアウトするだけで、何も行われていない)
- APIに依存するインテグレーションでAPIのアクティビティがない
3.3 介入プレイブック
ヘルスの段階とシグナルの種類に応じて介入方法を選びます。スコアの深刻度に応じて、対応の強度を上げます。
黄の段階 -- メールを優先した介入
顧客が黄の段階に下がったときに、自動的に開始する一連の連絡:
- 0日目:カスタマーサクセス担当者から個別メール(「[Brand]のご利用状況についてお伺いします」)
- 3日目:顧客のユースケースや業界に関連する役立つリソースを送信
- 7日目:1対1のセッションを直接提案(「[Brand]をもっと活用するための30分」)
- 14日目:エンゲージメントがなければ、赤の段階の介入にエスカレーション
メール文面の概要については、./references/frameworks/proactive-retention-emails.md を参照してください。
赤の段階 -- マルチチャネル介入
- 0日目:担当者名を明記したカスタマーサクセスマネージャーまたは創業者からの個別メール(自動送信に見えないもの)
- 1日目:アプリ内メッセージまたはプッシュ通知でフォローアップ(利用可能な場合)
- 2日目:月間経常収益(MRR)が500ドルを超えるアカウントには、電話またはビデオ通話を試みる
- 5日目:具体的な価値を提供するセッションを提案する(設定を監査し、改善案を提示する)
- 10日目:MRRが2,000ドルを超えるアカウントについて、シニアチームにエスカレーションする
介入時のトーンに関する原則:
- 不安をあおるのではなく、相手を気遣う姿勢で始めます(「最近ログインされていないようですが、何かお困りですか?」)
- 継続利用やアカウントの状態に言及する前に、心からの支援を申し出ます
- 顧客が自分で決められるようにし、「もう使いません」と気兼ねなく返信できるようにします
- 介入の結果を追跡します。黄のアカウントのうち、緑に戻るのは何件か。介入しても赤に移行したり解約したりするのは何件か。
3.4 継続率の基盤としてのオンボーディング
継続率を高めるうえで最も効果の大きい施策は、最初の30日間に行います。第1週に「アハ体験」(製品から初めて得られる意味のある成果)に到達した顧客は、到達しなかった顧客に比べて2~3倍の割合で利用を継続します。
- 製品において最も重要なアクティベーションイベント(長期的な継続率との相関が最も高い行動)を1つ定義します。
- すべての新規顧客が7日以内にそのアクティベーションイベントに到達できるよう、オンボーディングを構築します。
- 将来の継続率を示す先行指標として、アクティベーション率を監視します。
- 14日目までにアクティベーションに至っていない顧客には、自動メールを増やすのではなく、直ちに人が介入する必要があります。
4. 支払いの回復と督促
非自発的な解約は、顧客が退会を意図していなかったため、最も回復しやすい解約です。適切に設計された督促シーケンスにより、失敗した取引の50~60%を回復できます。すぐに対応してください。日が経つごとに回復率は急激に低下します。
4.1 支払い失敗の種類を理解する
| 失敗の種類 | 原因 | 回復方法 |
|---|---|---|
| ソフトディクライン | 一時的な原因:残高不足、1日の利用限度額、銀行による保留 | 別の時間帯に再試行する。顧客に通知する |
| ハードディクライン | 恒久的な原因:カード番号が無効、口座が閉鎖、利用停止 | 直ちに顧客への通知が必要 |
| カードの有効期限切れ | カードの有効期限が過ぎている | カード情報の事前更新サービス |
| 3DS/認証の失敗 | 強力な顧客認証(EU/UK)が必要 | 顧客に認証リンクを送信する |
カード情報更新サービス(アカウント更新サービス):Stripe、Braintree、およびほとんどの決済処理業者は、期限切れまたは再発行されたカードの詳細情報を発行銀行から自動的に更新するサービスを提供しています。この機能を有効にしてください。問題があったことを顧客が知る前に、非自発的な解約のかなりの割合を、気づかれないうちに回復できます。
4.2 スマートな再試行ロジック
支払いに失敗しても、すぐに再試行しないでください。再び拒否されることが多く、カードネットワークにおける成功率が低下します。
スマートな再試行ルール:
- ソフトディクライン(残高不足):24~48時間後に再試行し、その後72時間後に再試行します
- 月末のソフトディクライン:翌月の1~2日に再試行します(給与の支給時期に合わせます)
- ハードディクライン:再試行せず、直ちに顧客に通知します
- タイミング:深夜の再試行は避けます。顧客のタイムゾーンにおける営業時間中に再試行します
- 最大再試行回数:手動での回復に移行する前に、合計4~6回までとします
Stripe Billing の Smart Retries、Chargebee の Receivables、Recurly の Intelligent Retries などのツールは、機械学習で最適化された再試行タイミングを使用します。有効にしてください。固定スケジュールの再試行ロジックよりも大幅に高い成果を上げます。
4.3 督促メールのシーケンス
督促シーケンスは、スマートな再試行ロジックと並行して実行します。各メールはシステムアラートのようではなく、人が書いたような文面にしてください。
シーケンス全体:0~21日目
| 日 | トリガー | トーン | 主なCTA |
|---|---|---|---|
| 0日目 | 支払い失敗 | 柔らかく、親切 | 支払い方法を更新 |
| 1日目 | 更新なし | 親しみやすく、率直 | 支払い情報を更新 |
| 3日目 | 更新なし | さらに率直 | 今すぐ更新(リンク) |
| 7日目 | 更新なし | 緊急 | アカウントを維持 |
| 14日目 | 更新なし | 最終警告 | 更新できる最後の機会 |
| 21日目 | 猶予期間終了 | 中立的、確認を促す | 解約済みの場合は再開 |
6通すべてのメール本文と件名は、./references/frameworks/dunning-email-sequence.md にあります。
高価値アカウントへのエスカレーション:
- MRRが500ドルを超えるアカウント:7日目に電話またはチャットでの連絡を追加します
- MRRが2,000ドルを超えるアカウント:3日目にアカウントマネージャーが個別に電話します
- MRRが5,000ドルを超えるアカウント:経営幹部から連絡し、直ちにエスカレーションします
4.4 アカウント猶予期間の設計
支払いに失敗し、督促シーケンスが終了したときの対応を定義します。
| 日数 | アカウントの状態 |
|---|---|
| 0~6日目 | すべての機能を利用可能。控えめな通知を表示 |
| 7~13日目 | すべての機能を利用可能。アプリ内に目立つバナーを表示 |
| 14~20日目 | 読み取り専用アクセス、または機能を制限(データは保持) |
| 21日目 | 無料プランにダウングレード、またはキャンセル。データは90日間保持 |
データ保持:キャンセル後も、顧客データは最低30~90日間保持してください。作業内容を失わずに再開できることは、再アクティベーションを促す重要な要素です。このことを明確に伝えましょう。「お客様のデータは安全に保管され、いつでも再開できる状態です。」
4.5 支払い回復のベンチマーク
| 指標 | 目標 | 備考 |
|---|---|---|
| スマートリトライによる回復率 | 失敗した支払いの15~25% | 顧客の操作なしで回復 |
| カード情報更新による回復率 | 5~15% | バックグラウンドで自動的に回復 |
| 督促メールによる回復率 | 残りの失敗の30~40% | リトライとカード情報更新の後 |
| 非自発的な解約の総回復率 | 失敗した支払い全体の50~60% | 複数の方法を組み合わせた場合 |
| 7日目までの回復率 | 最終的な回復件数の70%が7日以内に発生 | 早い段階で緊急性を伝える |
5. 再獲得キャンペーン
解約した顧客がすべて永久に失われるわけではありません。顧客が離れる理由は変化します。予算に余裕ができたり、競合他社に失望したり、事業が成長して再び自社製品を必要としたりすることがあります。体系的な再獲得プログラムによって、こうした顧客の再エンゲージメントを促進できます。
5.1 再獲得のセグメント分け
解約したすべての顧客に同じ再獲得メッセージを送らないでください。まず、セグメントに分けます。
| セグメント | 条件 | アプローチ |
|---|---|---|
| 高価値の解約顧客 | MRRが$200超、過去90日以内に解約 | 個別に連絡し、魅力的なオファーを提示。上級チームが対応 |
| 価格重視 | 「高すぎる」という理由でキャンセル | 価格変更のお知らせ、低価格プラン、特別プラン |
| 機能重視 | 「機能が足りない」という理由でキャンセル | 該当機能の提供開始時にお知らせ |
| 利用頻度が低い | 解約前の利用頻度が低く、解約アンケートにも未回答 | 再教育、新たなユースケース、価値の実証 |
| 支払い失敗からの回復 | 支払いに失敗し、意図せずアカウントが停止 | 簡潔な再アクティベーションメール。オファーは不要 |
| 長期未利用(90日以上) | 90日より前に解約 | 製品アップデートや大きな変更を訴求 |
5.2 再獲得メールシーケンス(基本の3通)
送信タイミング:最初の再獲得メールは、キャンセルから7~14日後に送信します。それより早いと必死な印象になり、それより遅いと、ブランドがまだ記憶に残っている機会を逃します。
| メール | 送信タイミング | 主な内容 | CTA |
|---|---|---|---|
| メール1 | キャンセルから7~14日後 | 親しみやすい近況確認+変更点 | 「もう一度ご覧ください」 |
| メール2 | キャンセルから21~30日後 | 具体的な価値の実証+オファー | 「特典付きで再開」 |
| メール3 | キャンセルから45~60日後 | 最後の案内、機能のお知らせ、またはニュース | 「[X]で再アクティベート」 |
高価値の解約顧客には、メール2とメール3の間に、個別の連絡(電話またはビデオ通話)を1回追加します。
メールの文面全体の概要については、./references/frameworks/win-back-email-sequence.mdをご覧ください。
5.3 再獲得オファー
| オファーの種類 | 適した対象 | 期間 |
|---|---|---|
| Xか月無料 | 利用頻度の低い解約顧客に、価値を改めて示す | 1~2か月 |
| Yか月間の割引 | 価格重視の解約顧客 | 3~6か月。その後は通常価格 |
| 現在のプランの価格で上位プランを提供 | 機能重視の解約顧客 | 3か月のトライアル |
| オファーなしでニュースのみ | 非自発的な解約顧客、信頼関係が強いセグメント | 該当なし |
| 製品クレジット | Eコマースのサブスクリプション、物理的な製品 | 1回限りのクレジット |
段階的なオファー:メール1では割引を提示しないでください。メール2でオファーを追加し、メール3ではオファーを強化するか種類を変えます。最大の特典を最初に提示するのは避けましょう。特典を得るために解約するよう顧客を促してしまいます。
5.4 ウィンバックのトリガー(時間ベース以外)
標準的な時間ベースのシーケンスに加えて、特定のイベントをきっかけにウィンバックのアプローチを開始します。
- 機能のリリース:「機能 X がない」ことを解約理由として挙げた解約済みの顧客全員に、機能 X のリリース時にメールを送信します。変更履歴へのリンクと、直接再開を促す CTA を含めます。
- 価格変更:「高すぎる」ことを解約理由として挙げた解約済みの顧客に、価格の引き下げ時または下位プランの開始時にメールを送信します。
- 大規模な製品アップデート:製品の周年記念日またはメジャーバージョンのリリース後に、解約済みの顧客全員に向けて、年次の「新機能のご紹介」メールを送信します。
- 競合他社のニュース(マイナス要因):主要な競合他社で障害、値上げ、買収が発生した場合は、「今が再検討のタイミングかもしれません」というメッセージを添えて、タイムリーにアプローチします。
5.5 ウィンバックのベンチマーク
| 指標 | 目標 |
|---|---|
| ウィンバック率(解約後 0〜90 日) | 10〜15% |
| ウィンバック率(解約後 90〜180 日) | 3〜8% |
| ウィンバック顧客の LTV と新規顧客の LTV の比較 | ウィンバック顧客の継続期間は 20〜30% 長くなります(製品をよく知っているため) |
| ウィンバックメールの開封率 | 25〜35%(ブランドへの親しみやすさによる効果) |
| オファー受諾率 | 開封した顧客の 15〜25% |
6. 指標とベンチマーク
6.1 リテンションダッシュボードの指標
次の主要指標を毎週または毎月追跡します。月次顧客解約率、グロス MRR 解約率、純収益維持率、解約フローの表示率、解約防止率、オファー受諾率、督促による回収率、ウィンバック率(90 日)、月ごとの維持 MRR、ヘルススコアの分布です。計算式、健全な目標値、アラートのしきい値を含む指標ダッシュボードの完全な仕様については、./references/benchmarks.md のセクション 2 を参照してください。
6.2 業種別のベンチマーク
ベンチマークはセグメント(中小企業向け SaaS、ミッドマーケット、エンタープライズ、消費者向けサブスクリプション、定期購入ボックス型 E コマース)によって大きく異なります。上限ではなく、最低基準として使用してください。業種別の月次解約率、年間解約率、NRR 目標を含む業種別ベンチマークの全表については、./references/benchmarks.md のセクション 3 を参照してください。
6.3 先行指標と遅行指標
遅行指標(解約率、損失 MRR、ウィンバック率)は何が起きたかを示すため、レポートに使用します。先行指標(ヘルススコアの分布、アクティベーション率、NPS の傾向、決済失敗件数、最終ログインからの平均日数)は何が起きようとしているかを示すため、介入に使用します。先行指標に基づいてアラートを設定してください。指標の全体的な枠組みと、対象者別のリテンションレポート作成頻度(週次・月次レポート)については、./references/benchmarks.md のセクション 4〜5 を参照してください。
7. 成果物
すべてのリテンション関連成果物は、解決済みのパス(上記のパス解決を参照)に保存します。スクリーンショットと CSV エクスポート用の assets/ サブディレクトリも作成します。
| 成果物 | ファイル名 | 主なセクション |
|---|---|---|
| 解約診断レポート | churn-diagnosis-{YYYY-MM-DD}.md | 解約タイプの内訳、コホート分析、根本原因の調査結果、優先順位付きの推奨事項 |
| 解約フローの設計 | cancel-flow-{YYYY-MM-DD}.md | アーキテクチャ図、解約理由アンケートの文面、オファーの判断ツリー、確認ページの文面、ツールの推奨事項 |
| ヘルススコアのフレームワーク | health-scoring-{YYYY-MM-DD}.md | スコアモデル、シグナルの重み、ティアのしきい値、アラートの設定、ティア別の介入プレイブック |
| 督促シーケンス | dunning-sequence-{YYYY-MM-DD}.md | 再試行ロジック、メールシーケンス(全 6 通)、猶予期間のポリシー、高価値顧客へのエスカレーション手順 |
| ウィンバックキャンペーン | winback-campaign-{YYYY-MM-DD}.md | セグメントの定義、メールシーケンス(3〜4 通)、オファー戦略、イベントベースのトリガープラン |
| リテンションダッシュボード仕様 | retention-dashboard-{YYYY-MM-DD}.md | 指標の定義、データソース、アラートのしきい値、レポート作成頻度 |
8. 対応プロトコル
ユーザーからリテンションに関する作業を依頼された場合:
- まず開始時のコンテキストに応じて進め方を決めます(開始時コンテキストのルーターを参照):白紙からの戦略立案、既存コードベースへの実装、または公開 URL の監査。
- 利用できる最適な情報源から戦略的なコンテキストを読み取ります:ブランドのコンテキストと SOSTAC が利用できる場合は、まずそれらを確認します。利用できない場合は、コードベース、公開サイト、過去のリテンション関連成果物、分析のコンテキスト、ユーザーからの情報を活用します。
- スコープを明確にします:解約の診断、キャンセルフローの設計、ヘルススコアの設定、督促シーケンス、離脱顧客の呼び戻しキャンペーン、実装作業、リテンションプログラム全体、または特定の指標の調査のどれでしょうか?
- 現状を評価します:解決されたパス(パスの解決を参照)を確認し、過去の成果物を探します。キャンセルフローの有無、どのような督促が行われているか(請求プラットフォームについて質問してください)、現在どのようなヘルススコアリングが有効かを確認します。コードベースモードの場合は、提案や変更を行う前に、関連する実装ファイル、連携、既存のパターン、依存関係、検証方法を詳しく調査します。
- 提案の前に診断します:解約率、主な解約の種類、既存の対策を把握する前に、キャンセルフローの文案へ直ちに取りかかってはいけません。データが利用できる場合は、まずセクション 1 の分析を行います。
- 実行可能な成果物を提供します:具体的なメールシーケンス、決定木、ヘルススコアモデル、オファーのロジック、監査結果、実装計画、またはコードに直接反映できる提案を提供します。曖昧な助言にとどめてはいけません。
- 成果物を保存します:ブランドのワークスペースで作業する場合、すべての出力を解決されたパス(パスの解決を参照)に書き込みます。
- 次のステップを提案します:予想される MRR 回復効果の高いものから優先します(まず非自発的解約への対策、次にキャンセルフロー、続いて積極的なリテンション施策、その後に離脱顧客の呼び戻し)。
推奨される優先順位
リテンションプログラムをゼロから始める場合は、次の順に実施します。
- 支払い回収(最も高い ROI、最も迅速な成果 — 今週中に Card Updater と Smart Retries を有効にします)
- 督促メールシーケンス(残りの非自発的解約を防ぎます)
- キャンセルフロー(解約の意思が示された時点で、自発的解約に対処します)
- ヘルススコアリングと積極的な介入(解約の意思が生まれる前に解約を防ぎます)
- 離脱顧客の呼び戻しキャンペーン(解約した顧客に再び働きかけます)
- 継続的な解約分析とコホートのモニタリング(改善を維持します)
エスカレーションが必要な場合
- キャンセルフローのエンジニアリングや請求プラットフォームとの連携 — 開発者の関与、または専用ツール(Churnkey、ProsperStack)を推奨します。
- カスタマーサクセス機能の設計や CSM の採用 — 組織設計へ引き継ぎます。
- 解約の原因となっているプロダクトの不足(機能の欠如、バグ) — 定量化した影響(リスクにさらされている MRR)を添えて、調査結果をプロダクトチームへ引き継ぎます。
- 解約の原因となっている価格戦略 — プロダクトマーケティングのコンテキストに関する作業、またはコマーシャル戦略へ引き継ぎます。
- リテンション以外を目的とする NPS プログラムの設計 — 専用の CX ツール(Delighted、Typeform、Pendo)を推奨します。
- 複雑な請求プラットフォームの移行(Stripe から Chargebee など) — RevOps の関与を推奨します。
双方向エスカレーションシグナル
リテンション業務では、他の専門家へのエスカレーションが必要なシグナルが明らかになります。分析や介入によって次の状況が判明した場合は、エスカレーションしてください。
| 検出されたシグナル | エスカレーション先 | 理由 |
|---|---|---|
| 特定の時点に解約が集中していることを示すコホート分析 | marketing-analytics | 「パターンの特定には詳細なコホート分析が必要です」 |
| 価格設定やポジショニングの不一致を示す解約アンケート | marketing-pricing | 「価格体系が自発的な解約の原因になっています」 |
| 特定のチャネル経由で獲得したリードの解約率が高い | marketing-paid-ads | 「トラフィックソースの質に問題があります」 |
| ウィンバック施策で製品知識の不足が明らかになった | marketing-content | 「再エンゲージメントに必要な教育コンテンツが不足しています」 |
| オンボーディングの離脱に関連する解約パターン | marketing-cro | 「オンボーディングでのアクティベーションの失敗が、その後の解約につながっています」 |
| メールの到達性が督促の効果に影響している | marketing-email | 「督促メールがユーザーに届いていません」 |
リテンションからエスカレーションする際は、影響を受けている具体的なコホートまたはセグメント、解約理由のカテゴリ(自発的/非自発的/暗黙的)、定量化した影響(リスクにさらされているMRR)、および発生時期やきっかけに関するパターンを伝えてください。
リファレンス検索プロトコル
キャンセルフロー、督促、ウィンバック、またはプロアクティブなリテンションのコピーが必要な場合は、次の手順に従ってください。
./references/frameworks-index.csvを読み、retention_stageまたはtagsで適切なファイルを探します./references/frameworks/から、タスクに該当するファイルだけを読み込みます- すべてのフレームワークファイルを一度に読み込まないでください。現在のタスクに必要なファイルだけを読み込みます
| タスク | 読み込むファイル |
|---|---|
| 解約アンケートの設計または監査 | frameworks/exit-survey-copy.md |
| キャンセルフローのオファー設定 | frameworks/dynamic-offer-templates.md |
| 確認ページまたは解約後のメール | frameworks/cancel-confirmation-copy.md |
| 督促/支払い回収メール | frameworks/dunning-email-sequence.md |
| ウィンバックキャンペーンのメール | frameworks/win-back-email-sequence.md |
| プロアクティブなヘルススコアに基づくアプローチ | frameworks/proactive-retention-emails.md |
| オファー振り分けロジックのクイックリファレンス | frameworks/offer-decision-tree.md |
| 件名の選定 | frameworks/subject-line-reference.md |
| キャンセルフローの最適化テスト | frameworks/cancel-flow-ab-testing.md |
成果物の要件
リテンションの成果物には、次の項目を含めてください。
- リテンション施策:キャンセルフロー、督促シーケンス、ウィンバックキャンペーン、ヘルススコア、または継続のためのオファー
- トリガー条件:介入を開始するイベントまたは行動
- シーケンス/フロー:タイミングを含む、ユーザー体験の手順
- コピー/メッセージ:正確なメッセージ、メール、またはUIテキスト
- 成功指標:解約削減の目標、継続率、または再アクティベーション率