解約の予兆を検知するには、解約した顧客が解約の前にどんな行動の変化を見せていたかを利用データから洗い出し、その変化を「予兆のシグナル」として定義して、継続中の顧客に同じ変化が現れたら担当者に知らせる仕組みを作ります。代表的なシグナルは、ログインや利用の頻度の低下、主要な機能を使わなくなること、利用するユーザー数の減少、問い合わせの内容や頻度の変化、支払いの失敗などです。大切なのは、一般論のシグナルをそのまま使うのではなく、自社のデータで「解約した顧客と継続した顧客で何が違ったか」を確かめてから使うことです。
予兆の検知は、それだけでは解約を防げません。検知した後に、誰が、いつまでに、どんな手を打つかまで決めておいて、初めて効果が出ます。また、シグナルの精度は最初から高くはないため、検知した顧客のその後を記録し、シグナルの定義を見直し続けることが欠かせません。
この記事は、SaaSや会員制サービス、サブスクリプション型の事業を運営していて、解約の連絡を受けてから慌てて対応している、どの顧客が危ないのかを事前に知りたい、と考えている事業責任者やカスタマーサクセスの担当者に向けて書いています。シグナルの見つけ方、検知の仕組みの作り方、検知後の対応の設計、よくある失敗までを順に解説します。
なぜ解約の予兆を捉える必要があるのか
解約の連絡を受けた時点では、顧客の中ではすでに判断が終わっていることがほとんどです。他のサービスへの乗り換えが決まっている、社内の承認を得ている、予算が削られた、といった状況では、引き止めの提案をしても覆すのは難しくなります。
一方で、解約に至るまでには、多くの場合、段階的な変化があります。使い始めの段階でつまずいて主要な機能を使わないまま時間が過ぎる、担当者が異動して使う人がいなくなる、業務の流れが変わってサービスの出番が減る、といった変化です。この段階で気づき、利用の支援や設定の見直し、新しい担当者への説明などを行えば、解約を防げる可能性が高くなります。
予兆を捉える仕組みのもう一つの利点は、解約の原因を事業として学べることです。どんなシグナルが解約につながりやすいのかが分かれば、製品の改善や導入支援の設計に生かせます。継続率を上げる施策の全体像はサービスの継続率を上げる施策：初回体験の改善と利用習慣化の設計で扱っています。
解約の予兆として現れやすいシグナル
解約の前に現れやすいシグナルを、種類ごとに整理します。ただし、どのシグナルが自社で有効かは、サービスの性質によって大きく変わります。毎日使うことが前提のサービスと、月に一度の締め処理で使うサービスでは、利用頻度の意味が違います。以下は検討の出発点として使ってください。
| シグナルの種類 | 具体的な指標の例 | 読み取れること | 注意点 |
|---|---|---|---|
| 利用頻度 | ログイン回数、利用日数、直近の利用からの経過日数 | サービスが業務の中で使われなくなっている | 利用の周期（毎日・毎週・毎月）に合わせて見る |
| 機能の利用 | 主要な機能の利用回数、使っている機能の種類の数 | 価値を感じる使い方に至っていない、または離れている | 何が主要な機能かを先に定義する |
| 利用者の広がり | 契約内で利用しているユーザー数、管理者のログイン | 社内での利用が広がっていない、推進役がいなくなった | 契約の規模に対する割合で見る |
| データの量 | 登録されたデータの件数、新規の登録の推移 | 業務のデータがサービスに入ってこなくなった | サービスの性質によっては季節で変動する |
| サポートとの接点 | 問い合わせの件数や内容、不満の表明、要望の放置 | 困りごとが解決されていない、関心が下がっている | 問い合わせがゼロになることも予兆になりうる |
| 契約・支払い | 支払いの失敗、プランの縮小、契約更新の担当者の変更 | 予算や社内の状況が変わった | 支払いの失敗は非自発的な解約にもつながる |
この表の中で特に見落とされやすいのが、「問い合わせがなくなる」ことと「推進役の担当者の変化」です。以前はよく問い合わせをくれていた顧客が急に静かになった場合、満足しているのではなく、関心を失っている可能性があります。また、導入を推進した担当者が異動や退職をすると、社内でサービスを使う理由を説明できる人がいなくなり、次の更新で解約されることがあります。
「定着していない」という予兆
解約の予兆は、利用が減ることだけではありません。契約してから一度も主要な機能を使っていない、初期設定が終わっていない、という「最初から定着していない」状態も、強い予兆です。この場合は、利用が減るのを待つのではなく、契約から一定期間が経った時点で定着の状況を確認する仕組みが必要です。
自社のデータで予兆のシグナルを見つける手順
一般論のシグナルを並べるだけでは、自社の解約の予兆を正しく捉えられるとは限りません。次の手順で、自社のデータから有効なシグナルを見つけます。
- 過去の一定期間（半年から一年程度）に解約した顧客と、同じ時期に継続していた顧客の一覧を作る。
- 両方の顧客について、利用頻度、機能の利用、利用者数、問い合わせ、支払いなどのデータを集める。
- 解約した顧客について、解約の三か月前、二か月前、一か月前の各指標の値を時系列で並べる。
- 継続した顧客の同じ時期の値と比べ、明らかに違いがある指標を探す。
- 違いがあった指標について、「どの水準を下回ったら」「どのくらいの期間続いたら」解約が多くなるかを確認する。
- 見つかったシグナルを、二〜五個の条件として定義する（例：直近四週間のログイン日数が二日以下）。
- 定義した条件を過去のデータに当てはめ、条件に当てはまった顧客のうち実際に解約した割合と、解約した顧客のうち条件に当てはまっていた割合の両方を確認する。
手順7の二つの割合は、シグナルの精度を測るうえで大切です。条件に当てはまった顧客のほとんどが継続しているなら、そのシグナルは誤報が多すぎます。逆に、解約した顧客のほとんどが条件に当てはまっていなかったなら、見逃しが多すぎます。どちらに重きを置くかは、検知した後の対応にかけられる手間で決めます。担当者が少なく、一件ずつ丁寧に対応したいなら誤報の少なさを、多少の誤報があっても広く手を打ちたいなら見逃しの少なさを重視します。
データが少ないときの進め方
サービスを始めて間もない、解約した顧客の数が少ない、という場合は、統計的に確かな分析は難しくなります。その場合は、解約した顧客一社ずつについて、解約の前に何が起きていたかを振り返り、担当者の記憶や問い合わせの記録と合わせて仮説を立てます。解約の際に理由を聞き取る仕組みを作っておくと、仮説の材料が増えます。仮説として置いたシグナルを運用しながら、データが増えるたびに確かめていきます。
必要なデータが取れていない場合
ログインの記録はあっても、どの機能をどれだけ使ったかが記録されていない、ということはよくあります。予兆の検知に必要な利用のデータを、操作ごとの記録（イベントログ）として残す仕組みを整えることが、検知の前提になります。記録を始めてから分析できるようになるまでには時間がかかるため、早めに着手することをおすすめします。
解約リスクの検知の仕組みを作る
シグナルが定義できたら、継続中の顧客に対して定期的にシグナルを確認し、当てはまる顧客を担当者に知らせる仕組みを作ります。
リスクの段階を分ける
すべての予兆を同じ重さで扱うと、担当者は優先順位を付けられません。複数のシグナルを組み合わせて、リスクの段階を分けます。たとえば、一つのシグナルに当てはまれば「注意」、複数のシグナルに当てはまるか、特に強いシグナル（主要な機能の利用が完全に止まった、など）に当てはまれば「高リスク」とします。契約の金額や更新日までの期間も加味すると、限られた担当者の時間を、影響の大きい顧客に集中させられます。
点数で表す方法もあります。シグナルごとに点数を付け、合計点で顧客の健全さを示す方法で、カスタマーヘルススコアと呼ばれることもあります。点数の付け方は最初は仮のもので構いませんが、実際の解約との関係を見て調整していきます。
確認の頻度と通知の仕方
シグナルの確認は、サービスの利用の周期に合わせて、毎日から毎週の頻度で行います。手作業で確認すると続かないため、データから自動で判定し、該当する顧客の一覧を担当者のチャットや顧客管理の画面に表示する形が望ましいです。通知には、顧客の名前、当てはまったシグナル、直近の利用状況の推移、契約の更新日、担当者を含めます。指標の急な変化を自動で知らせる仕組みの作り方はKPIの急変に気づく仕組み：異常検知とアラート通知の設計でも解説しています。
顧客ごとの状況を見られる画面
担当者が顧客に連絡する前に、その顧客の利用状況の推移、過去の問い合わせ、契約の内容を一つの画面で確認できると、対応の質が上がります。複数のシステムを行き来しないと状況が分からない状態では、担当者の手間が大きく、対応が遅れます。
検知した後の対応を設計する
予兆を検知しても、何もしなければ解約は防げません。シグナルの種類ごとに、取るべき対応をあらかじめ決めておきます。
| 検知したシグナル | 考えられる原因 | 対応の例 |
|---|---|---|
| 契約後一定期間、主要な機能を使っていない | 初期設定のつまずき、使い方が分からない | 初期設定の支援、使い方の説明の場の提案 |
| 利用頻度が急に下がった | 業務の変化、担当者の不在、不具合や使いにくさ | 状況の聞き取り、困りごとの確認 |
| 利用者数が減った | 推進役の異動、社内での利用の縮小 | 新しい担当者への説明、管理者への利用状況の共有 |
| 問い合わせで不満が続いた | 製品の不足、対応への不満 | 上位の担当者からの連絡、改善の予定の共有 |
| 支払いが失敗した | カードの期限切れ、予算の問題 | 支払い方法の更新の案内、状況の確認 |
対応を決めるときは、担当者が使える文面の例や、説明の資料を用意しておくと、対応の質がそろいます。また、すべての顧客に人が個別に対応するのが難しい場合は、契約の規模に応じて、規模の小さい顧客には自動のメールで使い方の案内を送り、規模の大きい顧客には担当者が直接連絡する、というように対応を分けます。
対応の結果を記録する
検知した顧客に対して何をしたか、その後どうなったか（継続した、解約した、利用が回復した）を記録します。この記録が、シグナルの精度の見直しと、対応の効果の検証の材料になります。記録がないと、仕組みが役に立っているのかどうか判断できません。
社内の関係者に知らせる範囲
検知の結果は、カスタマーサクセスの担当者だけでなく、契約の規模が大きい顧客については営業の担当者や事業責任者にも共有します。更新の交渉や価格の相談が関わる場合、営業の担当者が状況を知らないまま顧客と話すと、対応がちぐはぐになります。共有の範囲と方法を、リスクの段階ごとに決めておきます。
架空の例：業務管理クラウドサービスの予兆検知
小規模な事業者向けに業務管理のクラウドサービスを提供している会社を例に考えます。これまでは、解約の連絡が来てから理由を聞き、引き止めの提案をしていましたが、ほとんど覆りませんでした。
まず、過去一年に解約した顧客と継続している顧客のデータを比べました。その結果、解約した顧客の多くに、解約の二か月ほど前から「新しいデータの登録が止まる」という変化が見られました。また、契約から一か月以内に、売上の集計の機能を一度も使っていない顧客は、その後の解約が多い傾向がありました。
そこで、「直近三週間、新しいデータの登録がない」と「契約から一か月時点で集計の機能を未使用」の二つをシグナルとして定義しました。前者に当てはまった顧客には、カスタマーサクセスの担当者が状況を尋ねる連絡をし、後者に当てはまった顧客には、集計の機能の使い方を紹介するメールを自動で送り、反応がなければ担当者が電話で支援を申し出ることにしました。
運用を始めて数か月後、シグナルに当てはまった顧客への対応の記録を振り返ると、データの登録が止まった理由として「繁忙期で入力が後回しになっていた」という回答が多いことが分かりました。この場合は解約の予兆ではないため、繁忙期の時期を考慮して条件を調整しました。このように、運用しながらシグナルを磨いていくことが大切です。
よくある失敗とその避け方
一般論のシグナルをそのまま使う
「ログインが減ったら危険」という一般論は、多くのサービスに当てはまりますが、利用の周期が長いサービスでは誤報が多くなります。自社のデータで、解約した顧客と継続した顧客の違いを確かめてから使います。
検知しても誰も動かない
シグナルの一覧が毎週届くだけで、誰が対応するのか決まっていないと、一覧は読まれなくなります。顧客ごとに担当者を決め、対応の期限と内容を決めておきます。
対象が多すぎて対応しきれない
条件を緩く設定すると、対象の顧客が多すぎて、一件ずつの対応ができなくなります。リスクの段階と契約の規模で優先順位を付け、人が対応する範囲と自動の案内で済ませる範囲を分けます。
引き止めの値引きに頼る
予兆を検知した顧客に、すぐに値引きを提案すると、根本の問題（使いこなせていない、業務に合っていない）が解決されず、次の更新で再び解約の危機が訪れます。値引きの前に、利用の支援や困りごとの解消を優先します。
解約の理由を製品の改善に生かさない
予兆の検知と対応をカスタマーサクセスの部署だけで完結させると、同じ原因の解約が繰り返されます。シグナルと解約の理由の傾向を定期的に製品の開発や営業の部署と共有し、根本の改善につなげます。
予兆検知の仕組みのチェックリスト
- 解約した顧客と継続した顧客のデータを比べたか
- 利用頻度、機能の利用、利用者数、問い合わせ、支払いのデータが取れているか
- 主要な機能の利用を操作ごとに記録しているか
- シグナルを二〜五個の条件として明確に定義したか
- 過去のデータに当てはめて、誤報と見逃しの程度を確認したか
- リスクの段階と、優先順位の付け方を決めたか
- シグナルの確認を自動化し、担当者に通知する仕組みがあるか
- シグナルの種類ごとに、対応の内容と担当者と期限を決めたか
- 対応の結果を記録しているか
- 定期的にシグナルの定義と対応の効果を見直しているか
- 解約の理由と傾向を、製品や営業の部署と共有しているか
よくある質問
Q. 機械学習で解約を予測する仕組みは必要ですか？
最初から必要というわけではありません。まずはこの記事のように、少数のシグナルを条件として定義し、運用しながら精度を確かめる方が、仕組みの理由を担当者が理解しやすく、対応にもつなげやすくなります。顧客の数とデータが十分に蓄積され、条件の組み合わせでは精度が頭打ちになった段階で、機械学習による予測を検討するのが現実的です。
Q. BtoCのサービスでも同じ考え方が使えますか？
使えます。ただし、BtoCでは顧客の数が多いため、一人ずつに人が対応するのは難しく、検知した後の対応はメールやアプリの通知、画面上の案内など、自動の手段が中心になります。シグナルの考え方はBtoBと同じで、利用頻度や主要な機能の利用の変化を見ます。
Q. どのくらいの期間で効果が分かりますか？
対応の効果が解約率に表れるまでには、契約の更新の周期に応じた時間がかかります。月額契約なら数か月、年額契約なら一年近くかかることもあります。それまでの間は、シグナルに当てはまった顧客の利用が回復したかどうかを、先行の指標として見るとよいでしょう。継続率の推移を時期ごとに比べる方法はコホート分析のやり方：継続率の表の作り方と改善への読み方で解説しています。
Q. カスタマーサクセスの担当者がいない場合はどうすればよいですか？
まずは自動のメールや画面上の案内で対応できる範囲から始めます。そのうえで、契約の規模が大きい顧客や、強いシグナルに当てはまった顧客に限って、営業担当や事業責任者が連絡する形にします。カスタマーサクセスで追うべき指標の全体像はカスタマーサクセスのKPI：オンボーディング・活用・更新の指標を参考にしてください。
Otsumuに相談できること
利用のデータが記録されていて、解約した顧客と継続した顧客を比べられる状態にあり、検知した後に対応できる担当者がいる場合は、この記事の手順に沿って自社で予兆の検知を始めることは十分可能です。まずは過去の解約顧客のデータを振り返り、仮のシグナルを二つほど決めて運用してみるところから始めてみてください。
一方で、必要な利用のデータが取れておらず計測の設計から始める必要がある、データが複数のシステムに分かれていて顧客ごとの状況を一つにまとめられない、シグナルの判定と通知を自動化する仕組みを作りたい、といった場合は、外部の手を借りた方が早く進むことがあります。
Otsumuでは、解約の予兆となるシグナルの分析から、利用データの計測の設計、リスクの判定と通知の仕組みの構築、顧客ごとの状況を見られるダッシュボードの整備、対応の運用の定着までを一貫して支援しています。詳しくはKPI改善コンサルティングやダッシュボード開発のページをご覧ください。
自社のデータでどんな予兆が見つかりそうか、まずは状況を伺いながら一緒に考えることもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01