churn-prevention

解約防止

あなたは 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 つのモードをサポートします:

1. 解約フローを構築する — 調査、セーブオファー、確認を含めてゼロから設計する
2. 既存のフローを最適化する — 解約データを分析し、セーブ率を改善する
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] を最近ご利用になっていないようです。サポートが必要ですか？」というメール
プランの上限に近づいている	アップグレードの案内（利用を妨げる制限ではなく）
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 を参照してください。

---

指標と測定

主要なチャーン指標

指標	計算式	目標
月次チャーン率	チャーンした顧客 / 月初時点の顧客	<5% B2C、<2% B2B
収益チャーン (ネット)	(失った MRR - 拡大 MRR) / 開始時 MRR	マイナス (ネット拡大)
キャンセルフローの保存率	保存された数 / キャンセルセッションの合計	25-35%
オファー承諾率	承諾されたオファー / 提示されたオファー	15-25%
一時停止の再有効化率	再有効化された数 / 一時停止の合計	60-80%
ダニングのリカバリー率	リカバリーされた数 / 失敗した支払いの合計	50-60%
キャンセルまでの時間	最初のチャーンシグナルからキャンセルまでの日数	傾向を追跡

コホート分析

チャーンを次のようにセグメント化します:

• 獲得チャネル — どのチャネルがより定着率の高い顧客をもたらすか?
• プランタイプ — どのプランが最もチャーンするか?
• 継続期間 — ほとんどの解約はいつ起こるか? (30 日、60 日、90 日?)
• キャンセル理由 — どの理由が増えているか?
• 保存オファーの種類 — どのオファーがどのセグメントに最も効果的か?

解約フローの A/B テスト

一度にテストする変数は 1 つにします。

テスト	仮説	指標
割引率（20% vs 30%）	割引率が高いほど、解約を防げる	継続率、LTV への影響
一時停止期間（1 か月 vs 3 か月）	一時停止期間が長いほど、復帰率が上がる	再開率
アンケートの配置（オファーの前 vs 後）	先にアンケートを行うことで、オファーをパーソナライズできる	継続率
オファーの表示形式（モーダル vs 全ページ）	全ページ表示のほうが注目される	継続率
文面のトーン（共感的 vs 直接的）	共感的な表現は抵抗感を減らす	継続率

解約フローの実験方法： ab-testing スキルを使って、統計的に厳密なテストを設計します。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	督促メールのシーケンス、リテンションキャンペーン
klaviyo	再獲得キャンペーン、督促メールのテンプレート、解約リスクの高いセグメントのデータ、継続オファー用のクーポンコード
posthog	機能フラグを使った解約フローの A/B テスト、ファネル分析
mixpanel / ga4	利用状況の追跡、解約シグナルの分析
segment	ヘルススコアリング用のイベントルーティング

Klaviyo (MCP)

解約防止におけるメール層を担当し、再獲得キャンペーン、督促メールのテンプレート、解約リスクのあるセグメントの特定に対応します。Klaviyo MCP を接続すると、次のことができます。

MCP ツール	用途
get_segments + query_segment_values	解約リスクのあるセグメント（エンゲージメントの低下、最近のアクティビティなし）を取得します
get_events	解約リスクを示す行動イベントを確認します
get_profiles	ターゲットを絞ったアプローチに向けて、解約リスクのある個々のプロフィールを取得します
query_metric_aggregates	メールエンゲージメントの傾向を確認します。開封率やクリック率の低下は解約の兆候です
get_flows + get_flow_report	既存の再獲得フローを監査し、メールによる引き留め率を測定します
create_email_template	督促メールのテンプレートを作成します（0日目、3日目、7日目、10日目の順序）
create_campaign	解約済みのコホートを対象に再獲得キャンペーンを開始します
get_coupons + get_coupon_codes	引き留めオファーのメールに記載する、利用可能な割引コードを取得します

注: Klaviyo が担当するのはメール層のみです。キャンセルフローのロジック（Churnkey、ProsperStack）と支払い再試行のロジック（Stripe）は別途管理します。