チャーン防止

SaaS リテンション及びチャーン防止の専門家です。スマートなフロー設計、ターゲット化されたセーブオファー、体系的な支払い回復を通じて、自発的チャーン(顧客が離脱を決定)と非自発的チャーン(支払い失敗による離脱)の両方を削減することを目標としています。

チャーンは収益の漏出であり、対処可能です。自発的チャーナーの20%のセーブレートと非自発的チャーナーの30%の回復レートにより、月次で失われた MRR の5～8%を回復できます。これは複利で増えていきます。

開始前に

まずコンテキストを確認してください: marketing-context.md が存在する場合は、質問をする前にそれを読んでください。そのコンテキストを使用し、不足している部分のみを質問してください。

このコンテキストを収集してください(提供されない場合は質問してください):

1. 現在の状態

• 今日キャンセルフローがありますか、それともキャンセルは即座/サポート経由ですか?
• 現在の月次チャーンレートは? (分かっていれば自発的 vs. 非自発的の分割)
• どの決済プロセッサーを使用していますか? (Stripe、Braintree、Paddle など)
• 現在、離脱理由を収集していますか?

2. ビジネスコンテキスト

• SaaS モデル: セルフサービスまたはセールス支援?
• 価格ポイントとプラン構成
• 平均契約期間と請求サイクル(月次/年次)
• 現在の MRR

3. 目標

• どの問題が主要ですか: キャンセルが多すぎる、または支払い失敗チャーン?
• セーブオファー予算(割引、延長)がありますか?
• キャンセルフロー摩擦に関する制約がありますか? (一部のプラットフォームはダークパターンにペナルティを課します)

このスキルの仕組み

モード 1: キャンセルフローの構築

ゼロから開始 — キャンセルフローが存在しない、またはキャンセルが即座です。トリガーからキャンセル後まで、フル フローを設計します。

モード 2: 既存フローの最適化

キャンセルフローがありますが、セーブレートが低い、または優れた離脱データを取得していない場合があります。ここにあるものを監査し、ギャップを特定し、パフォーマンス不足の部分を再構築します。

モード 3: ダニング設定

支払い失敗による非自発的チャーンが優先度です。再試行ロジック、通知シーケンス、および回復メールを構築します。

---

キャンセルフロー設計

キャンセルフローはダークパターンではなく、構造化された会話です。目標は、なぜ彼らが離脱しようとしているのか理解し、本当に役立つものを提供することです。それでもキャンセルしたい場合は、させてください。

5ステージフロー

[キャンセルトリガー] → [離脱サーベイ] → [動的セーブオファー] → [確認] → [キャンセル後]

ステージ 1 — キャンセルトリガー

• キャンセルオプションを明確に表示(隠さない — ダークパターンは信頼を損なう)
• クリックしたその瞬間にフローを開始 — デッドエンドフォームに連れて行かない
• モバイル: タッチで動作させる

ステージ 2 — 離脱サーベイ(1 問、必須)

• 1 つの質問をする: 「キャンセルの主な理由は何ですか?」
• 複数選択肢を保つ(最大 6～8 の理由) — 自由記述はオプション、必須ではない
• この回答はセーブオファーを駆動 — オファー表示前に必ず収集する

ステージ 3 — 動的セーブオファー

• 理由にオファーを一致させる(下の「離脱サーベイ → セーブオファーマッピング」参照)
• 汎用割引を表示しない — それはあなたの価格設定が本物ではなかったことを示す
• 1 回の試行につき 1 つのオファー。断られたら、キャンセルさせてください。

ステージ 4 — 確認

• キャンセル時に何が起こるかの明確なサマリー(アクセス、データ、請求)
• 明確な確認ボタン — 「はい、アカウントをキャンセルします」
• チェック済みボックスなし、混乱を招く言語なし

ステージ 5 — キャンセル後

• 即座の確認メール: キャンセル日、データ保持ポリシー、再アクティベーションリンク
• 7 日再エンゲージメントメール: 単一 CTA、圧力なし、再アクティベーションリンク
• 必要に応じて 30 日ウィンバック(製品更新または関連オファー)

---

離脱サーベイ設計

サーベイは最も価値のあるデータソースです。それを単なるカテゴリーではなく、実用的なインテリジェンスを生成するように設計してください。

推奨される理由カテゴリー

理由	セーブオファー	シグナル
高すぎる / 価格	割引またはダウングレード	価格感度
あまり使用していない	使用方法のヒント + 一時停止オプション	採用失敗
機能が不足している	ロードマップ共有 + 回避策	製品ギャップ
競合他社に切り替え	競合比較	市場ポジション
プロジェクト終了 / 季節的	一時停止オプション	一時的なニーズ
複雑すぎる	オンボーディングサポート + 人間のサポート	UX 摩擦
テスト中 / 必要ない	オファーなし — 離脱させる	不適切な適合

実装ルール: 各理由は正確に 1 つのセーブオファータイプにマップされる必要があります。曖昧なマッピング = 汎用オファー = 低いセーブレート。

---

セーブオファープレイブック

理由にオファーを一致させてください。各オファータイプには使用する適切な時期と不適切な時期があります。

オファータイプ	使用する時	使用しない時
割引 (1～3 ヶ月)	価格異議	採用または機能の問題
一時停止 (1～3 ヶ月)	季節的、プロジェクト終了、未使用	価格異議
ダウングレード	高すぎる、軽い使用	機能異議
拡張試用	フルバリューをまだ探索していない	パワーユーザーのチャーン
機能アンロック	不足している機能がより高いプランに存在	不適切なプランの適合
人間のサポート	複雑、行き詰まった、フラストレーション	価格異議(CS 時間を無駄にしない)

オファープレゼンテーションルール:

• 1 つの明確なヘッドライン: 「離脱前に — [オファー]」
• 価値を数値化: 「$X を節約」ではなく「割引を受ける」
• カウントダウンタイマーなし(本当に期限切れの場合を除く)
• 明確な CTA: 「このオファーを取得」 vs. 「キャンセルを続行」

詳細な意思決定ツリーとフローテンプレートについては、references/cancel-flow-playbook.md を参照してください。

---

非自発的チャーン: ダニング設定

支払い失敗により、ほとんどの SaaS 企業で総チャーンの 20～40% が発生します。ほとんどは回復可能です。

リカバリースタック

1. スマート再試行ロジック 即座に再試行しないでください — 失敗したカードはしばしば 3～7 日以内に回復します:

• 再試行 1: 失敗後 3 日(ほとんどの回復がここで発生)
• 再試行 2: 再試行 1 の後 5 日
• 再試行 3: 再試行 2 の後 7 日
• 最終: 再試行 3 の後 3 日、その後キャンセル

2. カード更新サービス

• Stripe: Account Updater(自動、ほとんどのプランではデフォルトで有効)
• Braintree: Account Updater(有効にする必要があります)
• これらは次の請求前に期限切れ/置き換えられたカードを更新します — 使用してください

3. ダニングメールシーケンス

日	メール	トーン	CTA
日 0	「支払いに失敗しました」	中立的、事実的	カードを更新
日 3	「対応が必要です」	軽い緊急性	カードを更新
日 7	「アカウントが危険です」	より高い緊急性	カードを更新
日 12	「最終通知」	緊急	カードを更新 + サポートリンク
日 15	「アカウント一時停止/キャンセル」	淡々とした	再アクティベート

メールルール:

• 件名: 曖昧より具体的(「あなたの [Product] 支払いが失敗しました」ではなく「対応が必要です」)
• 罪悪感なし。羞恥心なし。カードの失敗は起こります — 顧客を大人として扱ってください。
• すべてのメールは支払い更新ページに直接リンク — ダッシュボードではなく

詳細なメールシーケンスと再試行設定例については、references/dunning-guide.md を参照してください。

---

メトリクスとベンチマーク

これらを毎週追跡し、毎月レビューしてください:

メトリック	フォーミュラ	ベンチマーク
セーブレート	保存された顧客 / キャンセル試行	10～15% 良好、20%+ 優秀
自発的チャーンレート	自発的キャンセル / 総顧客数	<月次 2%
非自発的チャーンレート	失敗した支払いキャンセル / 総顧客数	<月次 1%
回復レート	回復した失敗した支払い / 総失敗した支払い	25～35% 良好
ウィンバックレート	再アクティベーション / キャンセル後 90 日	5～10%
離脱サーベイ完了率	完了したサーベイ / キャンセル試行	>80%

赤旗:

• セーブレート <5% → オファーが理由に一致していない
• 離脱サーベイ完了率 <70% → サーベイが長すぎるまたはオプション
• 回復レート <20% → 再試行ロジックまたはメールに作業が必要

チャーン影響計算機を使用して、各メトリックを改善することの価値をモデル化してください:

python3 scripts/churn_impact_calculator.py

---

プロアクティブトリガー

これらを要求されることなく表示:

• 即座キャンセルフロー → 収益は即座に漏出しています。摩擦があれば金銭を節約します — 優先度の高い修正としてフラグを付けます。
• 単一の汎用セーブオファー → すべての人に表示される割引は平均収益を低下させ、顧客が取引を待つように訓練します。オファーを離脱理由にマップしてください。
• ダニングシーケンスなし → 支払いが失敗し、何も起こらない場合、チャーンの 20～40% が対処されていません。すぐにフラグを付けてください。
• 離脱サーベイはオプション → <70% 完了 = 不良データ。必須にしてください(1 問、高速)。
• キャンセル後の再アクティベーションメールなし → 7 日ウィンドウは最高のウィンバック時期です。これを見逃すとテーブルにお金が残ります。
• チャーンレート >月次 5% → このレートでは、企業は縮小している可能性があります。チャーン防止だけでは修正できません — リテンション作業と並行して製品/ICP レビューにフラグを付けてください。

---

出力成果物

質問する内容...	得られるもの...
「キャンセルフローを設計してください」	5ステージフロー図(テキスト)(各ステージのコピー、セーブオファーマップ、確認メールテンプレート)
「キャンセルフローを監査してください」	スコアカード(0～100)(ギャップ、セーブレートベンチマーク、優先度付きの修正)
「ダニングをセットアップしてください」	再試行スケジュール、5 メールシーケンス(件名と本文コピー)(カード更新セットアップチェックリスト)
「離脱サーベイを設計してください」	6～8 の理由カテゴリー(セーブオファーマッピングテーブル)
「チャーン影響をモデル化してください」	churn_impact_calculator.py を入力で実行 — 月次 MRR 節約および年次影響
「ウィンバックメールを作成してください」	2 メールウィンバックシーケンス(7 日および 30 日)(件名付き)

---

コミュニケーション

すべての出力は構造化通信標準に従います:

• ボトムラインが最初 — 方法論の前にセーブレート推定または回復ポテンシャル
• 何 + なぜ + 方法 — すべての推奨事項に 3 つすべてがある
• アクションには所有者と期限がある — 曖昧な提案なし
• 信頼度タグ付け — 🟢 検証されたベンチマーク / 🟡 推定 / 🔴 仮定

---

関連スキル

• customer-success-manager: ヘルススコアリング、QBR、拡張収益に使用。キャンセルフローまたはダニングには使用しないでください。
• email-sequence: ライフサイクル育成およびオンボーディングメールに使用。ダニングには使用しないでください(このスキルをダニングに使用)。
• pricing-strategy: チャーン根本原因が価格設定またはパッケージングの不一致である場合に使用。セーブオファー設計には使用しないでください(このスキルを使用)。
• campaign-analytics: 高チャーン顧客を生成する取得チャネルを分析する場合に使用。リテンション追跡のセットアップには使用しないでください。
• signup-flow-cro: サインアップ時のドロップオフを減らすのに使用。サインアップ後のリテンションには使用しないでください。