SaaSの解約予兆は、利用状況・契約状況・顧客との接点・問い合わせ内容を組み合わせて検知します。単にログイン回数だけを見るのではなく、「以前と比べて利用が落ちた」「重要機能を使わなくなった」「更新前に問い合わせや不満が増えた」といった変化を捉えることが重要です。
検知後は、顧客を一律に引き止めるのではなく、解約リスクが高まった理由を確認し、利用支援や不具合対応など原因に合った対応につなげます。
SaaSの解約予兆として見るべき変化
解約予兆は、顧客がサービスから得ている価値が下がっている可能性を示す変化です。次の指標を、契約プランや利用目的に合わせて確認します。
| 確認する項目 | 解約予兆になり得る変化 | 確認する理由 |
|---|---|---|
| ログイン・利用頻度 | ログイン日数、利用回数、利用ユーザー数が継続的に減る | サービスを使う機会が減っている可能性があるため |
| 主要機能の利用 | 契約の目的に関わる機能を使わなくなる | 導入目的を達成できていない可能性があるため |
| 利用ユーザー | アクティブユーザーやチーム内の利用者が減る | 社内で定着していない、または利用価値が伝わっていない可能性があるため |
| 利用量 | 作成件数、処理件数、保存データ量などが下がる | 業務への組み込みが弱まっている可能性があるため |
| サポート・問い合わせ | 不具合、使いにくさ、料金への不満に関する問い合わせが増える | 不満や利用上の障害が解消されていない可能性があるため |
| 顧客との接点 | 定例会への欠席、メールへの返信停止、導入支援の中断が起きる | 担当者の関心低下や、社内での優先順位低下が考えられるため |
| 契約・請求 | 更新時期が近い、支払い遅延がある、契約縮小の相談がある | 解約だけでなく、ダウングレードの兆候も含まれるため |
これらはあくまで解約の可能性を示すサインです。利用頻度が一時的に下がっていても、季節要因やプロジェクト終了が原因なら、直ちに解約するとは限りません。
最も重要なのは「利用の減少」ではなく「価値の減少」
ログイン回数が多い顧客でも、契約の目的を達成できていなければ解約することがあります。一方で、利用回数が少なくても、必要な業務を安定して処理できていれば継続する場合があります。
そのため、次の2種類の指標を分けて設計します。
- 利用指標：ログイン回数、アクティブユーザー数、機能利用数、処理件数など
- 価値指標：作業時間の削減、処理完了、成果物の作成、目標達成など
たとえば、営業支援SaaSであれば、ログイン回数だけでなく、案件登録数や商談管理の継続状況を見る必要があります。請求・経費管理SaaSなら、ログイン数よりも申請や承認が業務の中で完了しているかが重要になることがあります。
解約予兆を検知する基本的な手順
最初から複雑なAIモデルを導入する必要はありません。まずは、解約した顧客に共通していた変化を整理し、ルールで検知できる状態にします。
-
解約の定義と対象期間を決める
完全な解約だけを対象にするのか、契約金額の縮小や更新見送りも含めるのかを決めます。あわせて「更新日の30日前に予兆を検知する」など、検知したい時点も設定します。
-
顧客ごとの基準値を作る
全顧客に同じ利用回数の基準を当てはめず、契約プラン、導入目的、利用人数、業種などで分けます。導入直後と定着後では通常の利用状況が違うため、契約開始からの期間も考慮します。
-
解約顧客の過去データを確認する
過去に解約した顧客について、解約前の利用頻度、主要機能の利用、問い合わせ、契約変更などを調べます。解約しなかった顧客とも比較し、解約顧客だけに多い変化を探します。
-
予兆となる条件を複数設定する
「ログインが減った」だけで判断せず、「主要機能の利用が減った」「問い合わせの未解決がある」「更新時期が近い」といった複数の条件を組み合わせます。
-
リスクを顧客単位で一覧化する
顧客ごとに、現在のリスク状態、変化した指標、契約更新日、担当者、次に取る対応を確認できるようにします。営業やカスタマーサクセスが、数値だけでなく理由まで読めることが重要です。
-
顧客への確認と対応を行う
予兆が出た顧客には、利用状況を一方的に指摘するのではなく、困っている点や利用目的の変化を確認します。使い方の案内、不具合の解消、設定支援、契約内容の見直しなど、原因に応じて対応します。
-
検知結果を検証して条件を見直す
一定期間後に、予兆が出た顧客のうち実際に解約・縮小した割合を確認します。予兆が多すぎる場合は条件が広すぎる可能性があり、見逃しが多い場合は指標や対象期間が適切でない可能性があります。
最初に作りやすい解約予兆のルール
初期段階では、次のように「変化」「重要度」「更新時期」を組み合わせると運用しやすくなります。数値の基準は、サービスの通常利用と過去の解約データから決めてください。
- 過去の平均と比べて、利用日数が継続的に減っている
- 契約の目的に直結する主要機能が一定期間使われていない
- アクティブユーザー数が減り、利用者が一部の担当者に偏っている
- 重要な問い合わせが未解決のまま残っている
- 定例会やオンボーディングなど、顧客との接点が途切れている
- 更新日が近い時期に、利用量の低下や契約縮小の相談がある
「30日間ログインがない」などの固定ルールを使う場合も、契約形態によって意味が変わります。毎月頻繁に使うサービスと、月に一度だけ使うサービスでは、同じ未利用期間でもリスクは同じではありません。
解約リスクのスコアリング方法
複数の予兆をまとめて判断したい場合は、指標ごとに点数を付ける方法があります。点数は解約を断定するものではなく、対応する顧客の優先順位を決めるために使います。
| 評価項目 | 評価の例 | 確認する内容 |
|---|---|---|
| 利用の変化 | 低下・横ばい・増加 | 過去の自社平均や同じ顧客の以前の状態と比較する |
| 主要機能の利用 | 未利用・一部利用・継続利用 | 導入目的に関係する機能が使われているか確認する |
| 顧客の反応 | 不満・反応低下・良好 | 問い合わせ、アンケート、定例会での発言などを見る |
| 契約更新までの期間 | 近い・中程度・遠い | 更新前に対応が必要な顧客か確認する |
たとえば、主要機能の未利用と未解決の問い合わせが同時にある顧客は、ログイン回数だけが減った顧客よりも優先して確認する、といった運用ができます。点数の配分は、実際の解約結果と照らし合わせて調整します。
AIや機械学習を使う場合の注意点
顧客数や過去データが十分にある場合は、解約した顧客と継続した顧客の違いを機械学習で分析する方法もあります。ただし、モデルが出したリスクをそのまま解約確定と扱うことはできません。
導入前に、次の点を確認します。
- 解約・継続の判定データが正しく記録されているか
- 契約開始直後など、通常とは違う期間の顧客を分けているか
- プランや業種の違いを考慮しているか
- なぜ高リスクと判定されたかを担当者が確認できるか
- 過去の傾向を学習した結果であり、将来の解約を保証するものではないと理解しているか
特に、過去に解約が少ない顧客層では、予測結果の精度を判断しにくくなります。まずはルールベースでデータの欠損や記録方法を整え、必要性が明確になってから高度な分析へ進む方法が現実的です。
解約予兆を検知した後に確認すること
検知後の目的は、顧客を無理に引き止めることではなく、解約につながる問題を特定して解消できるか判断することです。担当者は次の順番で確認すると、数値だけで判断しにくくなります。
- 利用が減ったのは、顧客側の業務量や担当者が変わったためか確認する
- サービスの操作方法、設定、連携に問題がないか確認する
- 契約した目的や評価指標が変わっていないか確認する
- 未解決の問い合わせや不具合が残っていないか確認する
- 改善できる問題と、顧客側の事情で解決できない問題を分ける
- 対応後に利用や顧客の反応が変わったか確認する
連絡する際は、「利用が減っているので解約しますか」と決めつけるよりも、「現在の運用で困っている点はないか」「導入時の目的は達成できているか」と聞くほうが、原因を把握しやすくなります。
検知の精度を確認する指標
解約予兆の仕組みは、当たった件数だけでなく、誤検知や見逃しも含めて評価します。
- 適合率：解約予兆と判定した顧客のうち、実際に解約・縮小した割合
- 再現率：実際に解約・縮小した顧客のうち、事前に予兆を検知できた割合
- 対応後の変化：支援後に利用、継続、契約金額などがどう変わったか
- 対応コスト：検知した顧客数に対して、担当者が対応できる量か
予兆を広く拾うと見逃しは減りやすくなりますが、対応対象が増えて担当者の負担が大きくなることがあります。自社の人員と更新プロセスに合わせて、検知する顧客数と優先順位を調整します。
解約予兆の検知で避けたい失敗
- ログイン回数だけで解約を判断する
- 全顧客に同じ利用基準を適用する
- 解約後のデータだけを見て、解約前の変化を比較しない
- スコアが高い理由を確認せず、同じ案内を全顧客に送る
- 一時的な利用低下を、継続的なリスクとみなす
- 顧客の業務変更や担当者変更をデータに記録しない
- 個人情報や行動データの利用目的、権限管理を整理しない
特に重要なのは、予兆を検知する指標と、顧客への連絡内容を分けることです。内部では複数のデータを使って判定しても、顧客には監視されていると感じさせない自然な形で状況を確認します。
まとめ
SaaSの解約予兆は、利用頻度、主要機能の利用、ユーザー数、顧客の反応、契約更新時期を組み合わせて検知します。最初は過去の解約顧客を分析し、自社で確認できるデータからルールを作る方法が始めやすいでしょう。
検知結果は解約の確定ではありません。予兆が出た理由を顧客に確認し、原因に合った支援を行ったうえで、検知条件と対応効果を継続的に見直すことが重要です。
