SaaS企業のチャーン対策は「解約された後の振り返り」ではなく「解約される前の検知」が勝負です。行動データを活用した予測の仕組みを整えれば、CSチームが先手を打てるようになります。
- ヘルススコア設計: ログイン頻度・機能利用率・サポート問い合わせの3軸で100点満点のスコアを構築する
- アラート設計: スコア低下時にCSへ自動通知し、対応の遅れを防ぐ
- MA/CRM連携: リスク顧客にリテンション施策を自動配信する仕組みを作る
- ダッシュボード: コホート別・セグメント別の推移を可視化し、傾向を早期に捉える
- スプレッドシート運用: データ基盤がなくても手動集計から始められる
本記事では、チャーン予測の設計からアラート運用、MA/CRM連携による自動リテンション施策まで、データ分析の実務を整理します。チャーンレート自体の改善施策は別記事で解説していますので、施策の全体像はそちらも参照してください。
チャーン予測が重要な理由
要点: 解約後の振り返りではなく、解約前の予兆検知にリソースを集中させることで、リテンション施策の効果が大幅に変わります。
SaaSビジネスにおいて、解約を1件防ぐことの経済インパクトは、新規顧客を1件獲得するよりも大きくなるケースがほとんどです。LTVとCACの関係を踏まえると、既存顧客の維持にかかるコストは新規獲得コストの5分の1程度とされています。
チャーン予測が機能すると、以下のような変化が起きます。
| チャーン予測なし | チャーン予測あり |
|---|---|
| 解約通知を受けてから対応開始 | 解約60日前にリスクを検知 |
| CSMが全顧客を均等にフォロー | リスク顧客に優先リソース配分 |
| 解約理由は事後アンケートで推測 | 行動データから原因を特定 |
| リテンション施策は属人的な判断 | スコアに基づく標準化された対応 |
| 解約率は月末の集計で初めて把握 | 週次でリスク量を予測・監視 |
チャーン予測を「精度の高い機械学習モデルを作ること」と捉えると、ハードルが上がりすぎます。実務的には、行動データの変化からリスク顧客を特定し、CSチームの対応に余裕を持たせることが目的です。完璧な精度は必要なく、解約の50%を事前に検知できるだけでも、CSのリソース配分が大きく変わります。
チャーン予兆を捉える行動データの種類
要点: ログイン頻度・機能利用率・サポート問い合わせの3指標が、チャーン予測の基本データです。
チャーン予測のデータソースは大きく3つのカテゴリに分かれます。
プロダクト利用データ
プロダクトの利用状況は、チャーン予兆を最も直接的に示すデータです。
- ログイン頻度の変化: 週5回ログインしていた顧客が週1回に減少した場合、30日以内の解約確率が上昇する
- 主要機能の利用回数: プロダクトのコアバリューに直結する機能（レポート作成、データ取り込みなど）の利用頻度が低下すると、価値を感じなくなっている可能性がある
- 最終ログインからの経過日数: 14日以上ログインがない場合は即時アラート対象にするのが一般的
- 招待ユーザー数の推移: 社内展開が進んでいない、あるいはユーザーが減っている場合は利用縮小の兆候
顧客満足度データ
利用データだけでは捉えきれない「不満の蓄積」を補足する指標です。
- NPS / CSATスコア: 定期アンケートで取得するスコアの推移。前回比で10ポイント以上低下した顧客は要注意
- サポート問い合わせ数: 急増は不満の表れ、急減は諦めの表れ。どちらもリスクシグナル
- 問い合わせの内容分類: 「機能要望」が多い顧客は現状に不足を感じている。「不具合報告」が繰り返される顧客は体験品質に不満
契約・請求データ
契約更新や請求に関するデータからも予兆が読み取れます。
- 契約更新日までの残日数: 更新90日前からリテンション施策を開始するのが標準的
- ダウングレード履歴: プランを下げた顧客は次回更新で解約するリスクが高い
- 請求エラー / 支払い遅延: 意図的な解約ではなくても、放置すると離脱につながる
| データカテゴリ | 代表指標 | 取得難易度 | 予測への寄与 |
|---|---|---|---|
| プロダクト利用 | ログイン頻度、機能利用率 | 低〜中 | 高 |
| 顧客満足度 | NPS、サポート件数 | 中 | 中〜高 |
| 契約・請求 | 更新日、ダウングレード | 低 | 中 |
ヘルススコアの設計方法
要点: 100点満点のヘルススコアを行動データ60点・満足度データ40点で構成し、3段階で顧客の健康度を可視化します。
ヘルススコアは、複数の指標を1つのスコアに統合して顧客の健康度を判定する仕組みです。CSチームが「どの顧客から対応すべきか」を瞬時に判断できるようにするのが目的です。
スコアの配点設計
100点満点で、以下のような配点が実用的です。
| カテゴリ | 指標 | 配点 | 計算ロジック例 |
|---|---|---|---|
| 行動データ | ログイン頻度 | 20点 | 直近30日のログイン日数 / 20日 x 20 |
| 行動データ | 主要機能利用 | 25点 | コア機能の週次利用回数を閾値で3段階評価 |
| 行動データ | アクティブユーザー率 | 15点 | 月間アクティブ / 契約ユーザー数 x 15 |
| 満足度 | NPSスコア | 20点 | NPS値を0〜20に正規化 |
| 満足度 | サポート評価 | 10点 | 未解決チケット数に応じて減点 |
| 満足度 | 直近フィードバック | 10点 | ポジティブ+10 / ネガティブ-10 / なし0 |
3段階の判定基準
スコアに応じて顧客を3つのゾーンに分類します。
- 70〜100点（Green / 健全）: 通常のCS対応でOK。アップセル提案の対象にもなる
- 40〜69点（Yellow / 要注意）: CSMが個別フォローを開始。利用状況のヒアリングと課題把握を行う
- 0〜39点（Red / 危険）: 即座に介入が必要。CSマネージャーまたは上長がエスカレーション対応
スコアの閾値は仮設定で構いません。運用を始めてから、実際の解約データと照合して四半期ごとに調整するのが現実的です。最初から精度にこだわるより、まず回し始めることの方が重要です。
スコア更新の頻度
週次更新が基本です。リアルタイム更新はデータ基盤への投資が大きいため、ほとんどのSaaS企業では週次のバッチ処理で十分です。ただし、最終ログインからの経過日数だけは日次で監視し、14日超過でアラートを飛ばす設計にすると、急激な利用離脱を見逃しません。
解約リスク検知のアラート設計とCS連携フロー
要点: アラートは「誰が・いつ・何をするか」まで定義して初めて機能します。通知だけで対応フローがなければ形骸化します。
ヘルススコアが構築できたら、次はアラートの設計です。スコアが閾値を下回った顧客にCSチームが確実に対応する仕組みを作ります。
アラートの発火条件
以下のような条件を設定します。
- Yellowアラート: スコアが70点から69点以下に低下したタイミング
- Redアラート: スコアが40点未満に到達したタイミング
- 急落アラート: 1週間でスコアが20点以上低下した場合（ゾーンを問わず発火）
- 未ログインアラート: 最終ログインから14日以上経過
CS対応フローの定義
アラートが出た後の対応を標準化します。
| アラート種別 | 対応者 | 初動アクション | 対応期限 |
|---|---|---|---|
| Yellowアラート | 担当CSM | 利用状況確認メール送信 | 3営業日以内 |
| Redアラート | CSM + マネージャー | 電話またはオンラインMTG設定 | 1営業日以内 |
| 急落アラート | CSM | 原因調査 + 即日連絡 | 当日中 |
| 未ログインアラート | CSM | 再利用促進メール + 翌週電話 | 2営業日以内 |
対応フローを定義しても、CSMの負荷が過大になると形骸化します。1人のCSMが同時に対応できるRedアラートは5〜10件が限界なので、アラートの発火量を見ながら閾値を調整する運用が必要です。
Slackやメールへの通知連携
アラートをCSMに届ける経路も設計します。CRMツール（HubSpot、Salesforceなど）のワークフロー機能を使い、ヘルススコアの変動を検知してSlack通知やメール通知を自動化するのが一般的です。通知にはスコアの推移、低下の主要因、顧客の契約更新日を含めると、CSMが状況を即座に把握できます。
MA/CRMを活用した自動リテンション施策
要点: ヘルススコアのゾーン別にMA/CRMの自動シナリオを組み、人的対応とデジタル施策を併走させます。
CSMの手動対応だけでは、顧客数が増えるほどカバレッジが落ちます。MAツール（HubSpot、Marketo、Pardotなど）やCRMのオートメーション機能を組み合わせ、リスク顧客へのアプローチを自動化します。
ゾーン別の自動施策設計
| ゾーン | 自動施策 | 目的 |
|---|---|---|
| Green（70点以上） | 活用事例メール配信（月1回） | エンゲージメント維持、アップセル伏線 |
| Yellow（40〜69点） | 再活用ガイド + ウェビナー案内 | 利用頻度回復 |
| Yellow（40〜69点） | CSM面談予約リンク送付 | 課題の早期把握 |
| Red（39点以下） | 経営層向け価値レポート送付 | 意思決定者への直接訴求 |
| Red（39点以下） | 特別サポート枠の案内 | 離脱前の最終フォロー |
シナリオの組み方
MAのシナリオは「トリガー → 条件分岐 → アクション」の構造で設計します。
たとえば、Yellowゾーンに入った顧客への自動シナリオは以下のようになります。
- トリガー: ヘルススコアが69点以下に低下
- 条件分岐: 主要機能の利用が減少している → 機能活用ガイドを送信 / NPSが低下している → CSM面談予約リンクを送信
- 送信後7日経過してもスコアが回復しない → CSMにエスカレーション通知
このようにデジタル施策で初動を自動化しつつ、改善しないケースはCSMの手動対応にエスカレーションする二段構えが効果的です。CS×マーケの連携設計については別記事も参考にしてください。
SaaSのCS戦略やマーケティング施策の改善については、BtoBマーケティング支援でご相談いただけます。
チャーン分析のダッシュボード設計
要点: ダッシュボードは「現在のリスク量」と「時系列の傾向変化」の2軸で構成し、週次のCS会議で使える粒度にします。
チャーン予測の仕組みを運用に乗せるには、可視化が不可欠です。CSチーム全体が同じ数字を見て議論できるダッシュボードを設計します。
必須ウィジェット
ダッシュボードに含めるべき要素は以下の通りです。
- ゾーン別顧客分布: Green / Yellow / Red の顧客数と割合。前週比の増減を表示
- Redアラート一覧: スコア、低下の主要因、担当CSM、対応ステータスをリスト表示
- コホート別チャーン率推移: 契約月別の解約率を折れ線で表示。特定コホートの異常を検知
- セグメント別ヘルススコア平均: プラン別、業種別、企業規模別のスコア平均値
- リテンション施策の効果: アラート発火後に介入した顧客の解約回避率
ツール選定の目安
| ツール | 適用段階 | 特徴 |
|---|---|---|
| Googleスプレッドシート | 顧客100社以下 | 無料、柔軟、手動更新で十分 |
| Looker Studio | 100〜500社 | BigQueryやスプレッドシートと連携、無料 |
| Metabase / Redash | 500社以上 | SQLベースで自由度が高い、セルフホスト可 |
| Gainsight / Totango | 1,000社以上 | CS専用ツール、ヘルススコア機能が標準搭載 |
初期段階で高機能なCS専用ツールを導入する必要はありません。スプレッドシートでヘルススコアを管理し、Looker Studioで可視化するだけでも、CSの意思決定は大きく改善します。
データ基盤がない段階から始める簡易チャーン分析の手順
要点: スプレッドシートと週次の手動集計だけで、チャーン予測の第一歩は踏み出せます。
データ基盤やBIツールが整っていなくても、チャーン予測は始められます。むしろ、手動運用でロジックを検証してからシステム化する方が、無駄な開発投資を避けられます。
Step 1 データ収集シートの作成
Googleスプレッドシートに以下のカラムを用意します。
- 顧客名
- 契約プラン
- 契約開始日
- 更新日
- 直近30日ログイン日数
- 主要機能の週次利用回数
- サポート問い合わせ数（直近30日）
- ヘルススコア（自動計算）
- ゾーン判定（Green / Yellow / Red の条件付き書式）
ログイン日数と機能利用回数は、プロダクトの管理画面からCSVエクスポートするか、開発チームに週次のデータ抽出を依頼します。
Step 2 スコアリングロジックの仮設定
前述のヘルススコア配点表をスプレッドシートの数式に落とし込みます。NPSデータがまだない場合は、行動データのみで暫定スコアを算出しても問題ありません。行動データ3指標（ログイン頻度・機能利用率・アクティブユーザー率）で60点満点とし、残りの40点はCSMの主観評価（5段階 x 8点）で補完する方法もあります。
Step 3 週次レビューの運用開始
毎週月曜日にスコアを更新し、以下の3つを確認します。
- 新たにYellowまたはRedに入った顧客はいるか
- 前週Red判定の顧客への対応状況はどうか
- スコアが回復した顧客の成功要因は何か
この3点を15分のCSミーティングで共有するだけで、チームの解約予防意識は格段に上がります。
Step 4 四半期ごとの精度検証
四半期に一度、以下を検証してスコアリングロジックを改善します。
- 実際に解約した顧客のうち、何%が事前にRedまたはYellowだったか（検知率）
- Red判定だったが解約しなかった顧客の割合（偽陽性率）
- 各指標のウェイトは妥当だったか
検知率と偽陽性率のバランスを見ながら、配点やゾーンの閾値を調整します。最初は大まかでも、4〜5回のサイクルを回すとかなり精度の高いモデルに仕上がります。
KPI設計の基本と組み合わせて、チャーン率の改善がLTV向上にどう寄与するかも合わせてモニタリングすると、CS活動のROIを経営層に説明しやすくなります。
チャーン予測は、データサイエンスの高度なスキルがなくても始められます。スプレッドシートでの手動集計からスタートし、仮説を検証しながら徐々にシステム化していくのが、最も現実的で成果が出やすいアプローチです。まずは来週から、自社の顧客リストにヘルススコアの列を追加するところから始めてみてください。
