SaaSの解約予兆を検知するには、利用状況・契約情報・顧客との接点を組み合わせ、解約した顧客に共通する変化を早期に見つけます。単にログイン回数を見るだけでは不十分で、利用機能の減少、管理者の活動停止、問い合わせ内容、更新時期などをまとめて判断することが重要です。
基本的な進め方は、過去の解約顧客を分析する、予兆となる指標を決める、顧客ごとにリスクを判定する、担当者が対応し、結果をモデルやルールに反映するという流れです。
SaaSの解約予兆とは
SaaSの解約予兆とは、顧客が契約をやめる前に現れやすい行動や状態の変化です。たとえば、利用頻度が落ちる、重要な機能を使わなくなる、契約更新に関する反応がないといった変化が該当します。
ただし、1つの変化だけで解約を断定することはできません。繁忙期や担当者の異動など、一時的な事情で利用が減る場合もあるため、複数の指標を組み合わせて判断します。
解約予兆を検知する主な方法
1. 利用状況の変化を分析する
最初に確認しやすいのは、顧客がサービスをどの程度、どのように使っているかです。ログイン回数だけでなく、契約価値に関係する操作まで確認します。
- ログインユーザー数が減っている
- ログイン間隔が長くなっている
- 主要機能の利用回数が減っている
- 導入時に使っていた機能が停止している
- 登録ユーザーに対する実利用ユーザーの割合が下がっている
- 利用部署や利用拠点が減っている
たとえば、毎週使うことが前提の業務サービスで、利用者数と主要機能の実行回数が数週間続けて減っているなら、解約予兆として確認する価値があります。一方、月次処理のサービスでは、毎日のログイン数だけで判断すると誤判定につながります。
2. 契約・請求・更新情報を確認する
利用ログだけでは分からない解約リスクを把握するには、契約情報も使います。
- 契約更新日が近づいている
- 更新案内への反応がない
- 請求エラーや支払い遅延が発生している
- 契約席数に対して利用者が少ない
- プラン変更や席数削減の相談がある
- 無料期間や割引期間の終了が近い
特に、更新時期が近い顧客の利用低下は、対応の優先順位を決める材料になります。ただし、未払いと解約意思は同じではありません。請求情報を使う場合は、営業・請求担当者が確認できる権限や個人情報の扱いも整理しておきます。
3. 問い合わせや顧客の声を分析する
顧客の不満や導入効果に関する発言も、重要な手がかりです。問い合わせの件数だけでなく、内容と解決状況を確認します。
- 同じ問題について問い合わせが繰り返されている
- 重要な不具合が未解決のまま残っている
- サポートへの不満が強くなっている
- 導入効果や費用対効果を尋ねている
- 競合サービスとの比較を相談している
- 解約、縮小、停止に関する言葉が出ている
チャット、メール、アンケート、商談記録などを分析する場合は、表記ゆれを整理します。「停止したい」「利用をやめたい」「更新しない」など、意味が近い表現を同じ分類にまとめる方法があります。
4. 顧客との関係や導入状態を確認する
法人向けSaaSでは、実際の利用者だけでなく、導入を推進した担当者や意思決定者との関係も確認します。
- 社内の推進担当者が異動・退職した
- 管理者が変わった後に利用が減った
- 導入後の研修や活用支援に参加していない
- 契約担当者との定例会議が途切れた
- 利用目的や社内の運用が変わった
担当者の異動だけで解約すると決めつけるのは危険です。しかし、引き継ぎが進まず利用者も減っている場合は、再説明や管理者設定の支援が必要な可能性があります。
解約予兆に使う指標を決める方法
指標は、サービスの価値が顧客に届いているかを表すものから選びます。業種やサービスによって適切な指標は異なるため、一般的なログイン数をそのまま採用するのではなく、顧客が継続する理由と結び付けて考えます。
| 確認する領域 | 指標の例 | 見るポイント |
|---|---|---|
| 利用頻度 | ログイン日数、利用間隔 | 通常の利用周期から外れていないか |
| 利用の深さ | 主要機能の実行回数、作成件数 | 契約目的に関係する機能を使っているか |
| 利用の広がり | 利用ユーザー数、部署数、拠点数 | 導入範囲が縮小していないか |
| サポート | 問い合わせ内容、未解決件数、満足度 | 問題が解消されているか |
| 契約 | 更新日、席数変更、請求状態 | 更新判断に影響する時期や問題がないか |
| 顧客関係 | 定例会議、活用支援への参加 | 導入後の支援や社内推進が続いているか |
指標を決めるときは、まず過去の顧客を「継続した顧客」と「解約した顧客」に分け、それぞれの利用状況を比較します。解約顧客に共通していた変化が、予兆候補になります。
解約予兆をスコアリングする
複数の予兆を一つの判断にまとめるには、顧客ごとにリスクスコアを付ける方法があります。たとえば、利用低下、未解決の問題、更新時期などに点数を設定し、合計点が高い顧客から対応します。
| 予兆 | 点数の設定例 |
|---|---|
| 主要機能の利用が一定期間減少 | 高い点数 |
| 利用ユーザー数が減少 | 中程度の点数 |
| 重要な問い合わせが未解決 | 高い点数 |
| 更新日が近い | 中程度の点数 |
| 請求エラーが発生 | 別枠で確認、または点数化 |
上の点数は計算方法の例であり、実際の配点を示すものではありません。配点は、過去の解約・継続データを使って、どの予兆が解約と結び付いていたかを検証して決めます。
リスクスコアは「解約する顧客」を断定するためではなく、担当者が確認する順番を決めるために使うのが基本です。スコアが高い顧客でも、実際には社内事情による一時的な利用減少かもしれません。
解約予兆を検知する手順
- 解約の定義を決める。完全解約だけを対象にするのか、契約席数の削減やプラン縮小も対象にするのかを決めます。
- 分析対象の期間をそろえる。契約開始からの期間、更新前の期間、直近数週間など、顧客間で比較できる条件を設定します。
- 顧客データを統合する。利用ログ、契約情報、請求情報、問い合わせ履歴、顧客アンケートなどを顧客IDで結び付けます。
- 継続顧客と解約顧客を比較する。解約前に利用が減った機能や、問い合わせ内容の変化を確認します。
- 予兆指標と判定基準を作る。「何日利用がなければ注意か」など、対象サービスの通常利用に合わせて決めます。
- リスクの高い顧客を担当者が確認する。スコアだけで判断せず、商談記録や未解決の問題、顧客の事情を確認します。
- 顧客ごとの対応を実施する。操作支援、活用方法の提案、障害解消、契約内容の見直しなど、予兆の原因に合わせて対応します。
- 対応後の変化を記録する。利用が戻ったか、問題が解決したか、契約が継続したかを記録し、判定基準を見直します。
自動化する場合でも、最初から複雑な予測モデルを作る必要はありません。まずはダッシュボードや通知で異常な変化を把握し、実際の対応結果が蓄積されてから、統計モデルや機械学習の導入を検討できます。
ルールベースと機械学習の違い
解約予兆の検知方法には、あらかじめ条件を決めるルールベース方式と、過去データから解約しやすい傾向を学習する機械学習方式があります。
| 方法 | 特徴 | 向いている場面 |
|---|---|---|
| ルールベース | 条件と判定理由が分かりやすい | 導入初期、データが少ない場合、担当者が理由を説明する必要がある場合 |
| 機械学習 | 複数の指標から解約傾向を推定できる | 十分な過去データがあり、顧客数や行動データが多い場合 |
機械学習を使えば自動的に正確になるとは限りません。解約件数が少ない、顧客属性が変わった、データの欠損が多いといった場合は、判定が安定しないことがあります。
また、予測結果だけでなく、担当者が「なぜリスクが高いのか」を確認できる仕組みが重要です。理由が分からない通知は、不要な連絡や優先順位の誤りにつながります。
検知の精度を確認する指標
解約予兆の仕組みは、的中したかだけでなく、対応に役立ったかで評価します。主に次の指標を使います。
- 適合率:解約予兆と判定した顧客のうち、実際に解約した顧客の割合
- 再現率:実際に解約した顧客のうち、事前に予兆を検知できた顧客の割合
- 誤検知の割合:継続した顧客を解約予兆と判定した割合
- 対応後の継続率:予兆検知後に対応した顧客が継続した割合
- 検知から解約までの期間:対応できる時間がどの程度あったか
たとえば、幅広く顧客を拾いたい場合は再現率を重視し、担当者の対応人数が限られている場合は適合率を重視するなど、目的によって評価基準が変わります。
解約予兆を検知するときの注意点
ログイン数だけで判断しない
ログインが少なくても、必要な処理をまとめて行うサービスなら問題がない場合があります。ログイン数ではなく、顧客が契約目的を達成しているかを示す利用指標を優先します。
一時的な変化と継続的な変化を分ける
連休、繁忙期、組織変更、システム障害などで利用が一時的に変わることがあります。1回の低下だけで通知せず、通常の利用周期や過去の季節変動と比較します。
顧客規模や契約プランを考慮する
小規模顧客と大規模顧客では、利用ユーザー数や利用頻度の基準が異なります。業種、プラン、導入期間、契約規模などで分けて判定すると、単純な全体平均による誤判定を減らせます。
個人情報と権限を管理する
利用ログや問い合わせ履歴には、個人を識別できる情報や業務上の機密情報が含まれる場合があります。収集目的、利用範囲、保存期間、閲覧権限を決め、必要以上の情報を分析対象にしないことが大切です。
「解約を防ぐこと」だけを目的にしない
顧客にとって必要のない連絡を繰り返すと、かえって負担になる可能性があります。予兆の原因を確認し、問題解決や活用支援につながる対応を選びます。サービスが顧客に合わなくなっている場合は、継続だけを目的にせず、契約内容の見直しを提案する判断も必要です。
解約予兆を検知した後の対応例
検知後の対応は、検知したシグナルの種類によって変えます。
| 検知した変化 | 確認・対応の例 |
|---|---|
| 主要機能の利用が減った | 利用目的の変化や操作上の問題を確認し、必要なら操作支援を行う |
| 利用者が減った | 担当者の異動、社内展開の停止、権限設定を確認する |
| 未解決の問い合わせがある | 解決状況と対応期限を確認し、担当部署と連携する |
| 更新日が近く反応がない | 契約内容、利用実績、更新手続きの状況を確認する |
| 請求エラーがある | 請求担当者に連絡し、支払い方法や請求情報を確認する |
| 費用対効果への懸念がある | 顧客の目的に対する成果や利用方法を整理し、改善案を提示する |
対応後は、連絡したかどうかだけでなく、顧客の課題が解決したか、利用や契約がどう変化したかを記録します。この記録が、次回以降の予兆判定を改善する材料になります。
まとめ
SaaSの解約予兆を検知するには、利用状況、契約・請求情報、問い合わせ内容、顧客との関係を組み合わせて、過去の解約顧客との共通点を分析することが基本です。
まずは主要機能の利用低下や未解決の問題など、サービスの価値に直結する指標を少数選び、ルールベースで検知を始めます。その後、担当者の対応結果を記録し、必要に応じてスコアリングや機械学習へ発展させると、実際の運用に合った仕組みを作りやすくなります。







