Agentic CRMで解約の予兆を検知する設計｜変化の見つけ方と打ち手の決め方

「更新の1か月前に解約の相談を受けて、そこで初めて兆しに気づいた」という声を、カスタマーサクセスの担当者からよく聞きます。兆しをつかんだあと、カスタマーサクセスから営業へどう戻すかは、CSからの引き戻しで扱っています。解約の予兆とは、利用状況や問い合わせや面談の記録に現れる小さな変化が、複数そろって同じ方向を指している状態のことです。 変化の1つずつは誤差の範囲に見えるため、単独では判断できません。ここで扱う設計はAgentic CRMの考え方にもとづくもので、特定の製品を前提にしていません。

そこで本記事では、解約の予兆を見つけられない構造から、実際に現れる変化、AIが横断して検知する仕組み、検知したあとの打ち手までを解説します。

解約の予兆検知は、一般には次の順で進めます。まず解約した顧客の記録をさかのぼって共通する変化を洗い出し、次にその変化を示すデータがどこに残っているかを確かめます。そのうえで検知の条件をつくり、気づいたときに誰が何をするかまで決めてから運用に乗せる、という流れです。この記事は、この流れのうち1番目の「何を変化と呼ぶか」と、4番目の「気づいたあとの打ち手」に重心を置いて扱います。

解約の予兆を見つけられない3つの構造

建設現場向けの工程管理クラウドを提供する中堅SaaS企業では、従業員190名のうちカスタマーサクセスが7名、営業が14名という体制で、420社の契約を扱ってきました。この企業は説明のための架空の設定であり、実在の企業ではありません。契約は年単位で、更新の時期は契約月ごとに分散しています。年間の解約率は12%で、当初の目的は「更新の直前まで気づかない状態をなくすこと」でした。そこでここでは、この会社を例に、解約の予兆を見つけられない3つの構造を整理します。

解約の予兆を見つけられない原因は、担当者の注意が足りないことではありません。解約の予兆が見つからないのは、変化の記録が部署ごとに分かれていて、1人の目に同時に入らないためです。

構造①利用の記録が部署ごとに分かれている

1つ目は「利用の記録が部署ごとに分かれている」構造です。製品の利用状況はプロダクト側の管理画面に、問い合わせはサポートの管理ツールに、面談の議事録はカスタマーサクセスの共有フォルダに、契約の更新情報は営業と管理部門にあります。

分かれていること自体は、業務の分担として自然です。問題になるのは、解約の予兆が1つの記録のなかでは完結しない点にあります。利用が減っていなくても、問い合わせの内容が変わり、面談の出席者が減っていれば、それは兆しにあたります。

先ほどの工程管理クラウドの会社では、カスタマーサクセス7名がそれぞれ60社を担当していました。担当者が確認しているのは面談の議事録と直近の問い合わせで、利用状況の管理画面を開くのは四半期に1度の報告資料を作るときだけです。契約の更新情報にいたっては、営業から共有されるまで見る手段がありませんでした。

自分が普段開いている記録を数えてみましょう。4種類のうち2種類しか見ていないなら、残りの変化は視界の外にあります。部署をまたいだ収益の流れを整える考え方は、RevOpsの記事でも整理しています。

構造②担当者の主観で更新の判断が止まる

2つ目に挙げるのは、担当者の主観で更新の判断が止まる構造です。カスタマーサクセスの担当者は顧客と近い距離にいるため、「あの会社は大丈夫」という感覚を持っています。

この感覚が働くと、記録に現れた変化が過小に評価されます。関係が良好な担当者ほど、窓口の担当者との関係を根拠に判断してしまい、組織としての意思決定が変わったことに気づきにくくなります。

この会社が直近2年に解約した顧客から38社を抽出して振り返ったとき、解約の3か月前の時点で担当者が「更新の見込みあり」と記録していた顧客が23社ありました。実際にはその時点で、利用する人数が減り始めていた顧客が17社あります。担当者の記録と利用状況が食い違っていたことになります。

見込みの記録と、記録に残っている変化を並べてみてください。食い違いがあるなら、主観が入っている可能性があります。

構造③予兆に気づいても動く人が決まっていない

3つ目は「予兆に気づいても動く人が決まっていない」構造です。変化に気づいた担当者が、次に何をするかを毎回自分で決めています。

決め方が個人に委ねられていると、動くまでに時間がかかります。上長に相談するか、営業に伝えるか、自分で顧客へ連絡するかを検討している間に、顧客側の検討は進みます。動いた内容も担当者ごとに違うため、あとから効果を比べられません。

たとえば、この会社では予兆に気づいてから顧客へ接触するまでに平均19日かかっていました。カスタマーサクセスの担当者に聞き取ると、「誰に相談すればよいか分からない」「営業に伝えても動くかどうかが読めない」という答えが返っています。気づいた時点で打ち手が決まっていれば、この19日は発生しません。

検知の精度を上げる前に、気づいたあとに誰が何をするかを決めておく必要があります。

解約の予兆に出る4つの変化｜部署をまたいで見る

3つの構造を踏まえると、次に確かめるべきなのは「そもそも何が変化として現れるのか」です。利用状況の数字だけを見ていると、記録に残る兆しの多くを落とします。何を変化と呼ぶかが決まっていなければ、見る記録を増やしたところで見過ごされてしまうのではないでしょうか。そこでここでは、解約の予兆として実際に現れる4つの変化を整理します。

変化が現れる場所は、利用のログのほかに3つあります。解約の予兆は、利用の減少・問い合わせの質の変化・面談の出席者の変化・更新の話題の扱いという4方向に現れます。

変化①利用する人数が気づかれずに減る

1つ目は「利用する人数が気づかれずに減る」変化です。全体のログイン数が横ばいでも、実際に使っている人の数が減っている場合があります。特定の担当者だけが使い続け、ほかの利用者が離れている状態です。

この変化が見えにくいのは、合計の数字で見ると変化が小さいためです。20名のうち5名が使わなくなっても、残る15名の利用が少し増えれば、合計は変わりません。契約の更新を判断するのは、使わなくなった側の部署である場合もあります。

先ほどの工程管理クラウドの会社が直近2年の解約38社を調べたところ、解約の6か月前から利用する人数が減り始めていた顧客が26社ありました。そのうち14社は、合計のログイン数では変化が見えていません。人数の推移を見て初めて分かる形でした。

実際に使っている人数の推移を、月ごとに並べてください。合計の数字が横ばいのまま人数だけが減っている顧客は、減り方が緩やかなほど気づかれずに進みます。

変化②問い合わせの内容が運用から契約へ移る

2つ目に挙げるのは、問い合わせの内容が運用から契約へ移る変化です。「この機能はどう使うのか」という質問が減り、「契約期間はいつまでか」「データはどう出せるか」という質問が増えます。

内容の変化が予兆になるのは、質問する側の目的が変わっているためです。使い方の質問は使い続ける前提から出ますが、契約やデータの取り出しに関する質問は、やめる可能性を含んだ検討から出ます。

この会社の38社のうち、解約の3か月前にデータの出力方法を問い合わせていた顧客は19社でした。サポートの担当者はいずれも通常の問い合わせとして回答しており、カスタマーサクセスへは共有されていません。問い合わせの内容が分類されていなかったため、傾向として見えていませんでした。

問い合わせを内容で分類しておけば、この変化は件数として数えられます。見るのは総件数の増減ではありません。契約とデータに関する質問が、全体に占める割合です。

変化③定例の出席者が現場だけになる

3つ目は「定例の出席者が現場だけになる」変化です。導入の当初は部門長や情報システムの担当者も出ていた定例に、次第に現場の担当者しか来なくなります。

出席者の変化が予兆になるのは、社内での位置づけが下がっているためです。決裁に関わる人が出席しなくなった時点で、その製品は「現場が使っている道具」の扱いになります。更新の判断が来たときに、擁護する人が社内にいません。

たとえば、この工程管理クラウドの会社では38社の議事録を読み返したとき、解約の4か月前から部門長の出席が途絶えていた顧客が21社ありました。担当者は「先方が忙しいのだろう」と記録しており、兆しとしては扱っていません。

議事録に出席者の欄があるなら、その推移は追えます。誰が出なくなったかを見てください。

変化④更新の話題を先延ばしにされる

4つ目は「更新の話題を先延ばしにされる」変化です。更新の時期や条件について話そうとすると、「まだ先の話なので」「予算が決まってから」と後ろへ送られます。

先延ばし自体は珍しくありませんが、回数が重なる場合は意味が変わります。社内で別の選択肢が検討されているときほど、窓口の担当者は確約を避けたがるものです。避けた回数は、記録に残していれば数えられます。

先ほどの会社の38社では、解約の2か月前までに更新の話題を2回以上先送りされていた顧客が28社ありました。この記録は担当者の議事録に散在しており、集計されていません。数えてみて初めて、最も強い兆しだったことが分かっています。

先送りされた回数を記録に残しましょう。1回では判断できませんが、2回以上は別の意味を持ちます。

人手で追える？解約の予兆を見逃す理由3つ

前章で挙げた4つの変化は、いずれも記録に残っています。では、記録があるのになぜ担当者は気づけないのでしょうか。それは、変化を追う作業が担当者の日常業務の量を超えているからです。記録を集める仕組みを整えるほど、読む側にかかる負担は増えていきます。そこでここでは、解約の予兆を人手で追えない3つの理由を整理します。

追えない理由は、担当者の作業量の側にあります。4種類の記録を60社分そろえて毎週見る作業は、担当者が持っている時間の量を超えています。

理由①変化が単独では小さすぎるから

1つ目は「変化が単独では小さすぎるから」です。利用する人数が20名から18名に減っても、その場では誤差に見えます。定例に部門長が1回来なかっただけでは、忙しかったのだろうと解釈されます。

小さな変化が意味を持つのは、複数が同じ方向を指したときです。人数が減り、問い合わせが契約の話に移り、部門長が来なくなり、更新の話題が先送りされる状態がそろって、初めて兆しとして読めます。

この工程管理クラウドの会社の38社では、解約の3か月前に4つのうち3つ以上が同時に現れていた顧客が24社ありました。一方、1つだけが現れていた顧客は、解約に至らなかった顧客のなかにも多数あります。単独の変化では判別できません。

そのため、変化を1つずつ見ている限り判断はできず、いくつ重なったかを条件に置く必要があります。

理由②担当する顧客数が多すぎるから

2つ目に挙げるのは、担当する顧客数が多すぎるからです。1人が60社を担当していれば、1社あたりに使える時間は限られます。

時間の制約は、確認の頻度に直接効きます。60社について4種類の記録を毎週確認しようとすると、1社あたり5分でも週に5時間かかります。日常の対応と面談を持ちながら、この時間を毎週確保することはできません。

この会社のカスタマーサクセス7名に聞き取ったところ、記録をまとめて確認しているのは四半期の報告資料を作る時期だけでした。それ以外の時期は、問い合わせや面談で接点があった顧客だけを見ています。接点がない顧客ほど兆しが進むという構造になっていました。

確認の頻度と担当社数を掛け算してみましょう。人が持てる時間を超えているなら、人手では追えません。どこまで自律的に判断するのかは、エージェンティックAIの記事で詳しく説明しています。

理由③兆候の基準が担当者ごとに違うから

3つ目は「兆候の基準が担当者ごとに違うから」です。何をもって兆しと判断するかが、経験と感覚に委ねられています。

基準が違うと、同じ変化を見ても対応が分かれます。ある担当者は部門長の欠席を重く見て、別の担当者は気にしません。組織として何件の兆しがあるのかを集計することもできません。

先ほどの会社では、カスタマーサクセス7名に同じ10社の記録を見せて「兆しがあるか」を答えてもらったことがあります。7名の判断が一致したのは10社中3社で、残る7社は意見が割れました。判断が割れた顧客のうち、実際に解約に至ったのは4社です。

基準を言葉にしていないなら、判断は割れます。過去の解約と照らして基準を決める必要があります。

解約の予兆をAIが自律検知する3つの仕組み

3つの理由はどれも、人の時間と基準の問題です。記録は残っているのに読む手が足りない状態は、横断して読む仕組みを置くことで変わります。ここから先はAgentic CRMの考え方に沿った設計の話になります。なお本記事が扱うのは、受注したあとの顧客が離れていく兆しです。受注前の商談が止まる状態の検知は、パイプラインの停滞を扱った記事の範囲になります。そこでここでは、解約の予兆をAIが自律検知する3つの仕組みを整理します。

仕組みの中心はスコアの計算にはありません。検知の仕組みが担うのは、部署に分かれた4種類の記録を同じ時間軸に並べ、変化の重なりを見つけることです。

仕組み①複数の記録を横断して変化を並べる

1つ目は「複数の記録を横断して変化を並べる」仕組みです。4種類の記録を、顧客ごとに同じ時間軸へ並べます。

同じ時間軸へ並べる4種類の記録 ①利用状況・・・誰がいつ何を使ったかの記録です ②問い合わせ・・・内容の分類まで含めた履歴です ③議事録・・・出席者と話題を残した記録です ④契約の更新情報・・・時期と交渉の状況です

並べることが最初に効くのは、変化の重なりが目に見える形になるためです。人が4つの管理画面を開いて突き合わせる作業を、仕組みの側が引き受けます。担当者は並んだ結果だけを見ます。

先ほどの工程管理クラウドの会社では、420社について週次で4種類の記録を並べる形にしました。カスタマーサクセスの担当者が見るのは、変化が2つ以上重なった顧客だけです。週あたり平均で11社が表示され、60社を全件確認する必要はなくなりました。

まず並べるところから始めましょう。判定の精度は、並べたあとに調整できます。

仕組み②過去に解約した顧客の推移に照らす

2つ目に挙げるのは、過去に解約した顧客の推移に照らす仕組みです。すでに解約した顧客が、解約までの数か月でどう変化したかを基準にします。

照らす理由は、基準を感覚で決めずに済むためです。前章の理由③で挙げた「担当者ごとに基準が違う」という状態は、過去の実績を基準に置くことで解消します。何か月前にどの変化が現れたかを、実際の記録から取れます。

この会社は直近2年の解約38社を対象に、4つの変化がそれぞれ解約の何か月前から現れていたかを数えました。

変化が現れ始めた時期の平均（解約38社の実測） ①利用人数の減少・・・解約の6か月前から現れます ②定例の出席者の変化・・・解約の4か月前から現れます ③問い合わせの質の変化・・・解約の3か月前から現れます ④更新の先送り・・・解約の2か月前から現れます

この期間が、検知の基準になりました。

過去の解約を並べる作業は、最初に1度行えば足ります。ここを飛ばすと、基準を決める根拠がありません。

仕組み③検知した内容を担当者へ渡す

3つ目は「検知した内容を担当者へ渡す」仕組みです。変化が重なった顧客について、何がどう変わったかを担当者へ届けます。

渡し方で結果が変わります。「解約リスク高」というスコアだけを渡すと、担当者は何をすればよいか分かりません。「利用人数が20名から13名へ減り、直近1か月でデータ出力の問い合わせが2件、定例に部門長が2回続けて欠席」という形で渡せば、次の行動が決まります。

この工程管理クラウドの会社では、通知に4つの変化のうちどれが現れたかを列挙する形を採りました。運用の初月に担当者が通知を開いた割合は41%でしたが、内容の書き方を変えてから6か月後には86%まで上がっています。開かれなかった通知の多くは、スコアだけを載せていた初期のものでした。

渡す内容には、判断に使える材料を入れましょう。スコアだけでは動けません。

解約の予兆を検知するために整える4つのデータ

前章の仕組み①で挙げたとおり、横断して並べるには元になる記録が必要です。ところが多くの会社では、この4種類のうち1つか2つが揃っていません。設計を始める前に、何が手元にあるかを確かめる作業が要ります。そこでここでは、解約の予兆を検知するために整える4つのデータを整理します。

すべてを完璧に揃える必要はありません。4種類のうち2種類が揃っていれば検知は始められます。揃わないものは、揃えながら追加します。

データ①製品の利用状況の記録

1つ目は「製品の利用状況の記録」です。誰がいつ何を使ったかの記録で、自社の製品で取得できているかを最初に確かめます。

必要なのは合計値ではありません。利用者ごとの記録です。前章の変化①で挙げたとおり、合計のログイン数では人数の減少が見えません。顧客ごとに何名が実際に使っているかを、月単位で取れる形にします。

先ほどの会社は、プロダクト側の管理画面から利用者数の月次推移を取り出せる状態にありました。ただし顧客のCRMレコードとの紐づけがなく、社名で照合する作業が手作業で残っています。データ担当の1名が、この紐づけを最初に整えました。

利用者ごとの記録が取れないなら、CRMレコードとの紐づけを含めて、ここが最初の整備の対象になります。指標の設計の全体像を先に押さえたい場合は、パイプライン管理のKPIの記事をご確認ください。

データ②問い合わせと対応の履歴

2つ目に挙げるのは、問い合わせと対応の履歴です。件数だけでなく、内容の分類が要ります。

分類が要るのは、変化②で挙げた「運用から契約へ移る」という質の変化を捉えるためです。分類がなければ、件数の増減しか見えません。件数は解約の直前でむしろ減ることもあり、それだけでは判断できません。

この工程管理クラウドの会社では、サポートの管理ツールに分類の項目がありましたが、運用のなかで使われなくなっていました。データ担当の1名が直近1年の問い合わせを読み、「使い方」「不具合」「契約」「データ」の4分類を付け直しています。この作業に約30時間かかりました。

分類が付いていない履歴でも、過去1年分をさかのぼって付け直せば、基準を決める材料になります。全期間をさかのぼる必要はありません。

データ③定例の議事録

3つ目は「定例の議事録」です。出席者の記録と、話題の記録が要ります。

議事録は自由記述であることが多く、そのままでは横断して読めません。最低限、出席者の氏名と所属を毎回残す形にしておくと、変化③の「出席者が現場だけになる」が数えられます。あわせて、更新や契約に触れた回に印を付けておくと、変化④の先送りが何回あったかも数えられる形になります。

先ほどの会社の議事録には、出席者の欄がある回とない回が混在していました。カスタマーサクセスの2名が直近2年分を確認したところ、出席者が記録されていたのは全体の68%です。残りは本文から読み取る必要があり、この作業が設計のなかで最も時間を使いました。

議事録の様式に出席者の欄を入れておきましょう。あとから読み取るより、記録の時点で残すほうが早く済みます。

データ④契約の更新に関する情報

4つ目は「契約の更新に関する情報」です。更新の時期、金額、直近の交渉の状況が該当します。

この情報が要るのは、検知した予兆を優先順位に変えるためです。更新まで2か月の顧客と10か月の顧客では、同じ予兆でも動く順番が変わります。更新の時期が分からなければ、11社の通知が来たときにどれから見るかを決められません。

この会社では、契約の更新時期が営業側の管理表にありました。カスタマーサクセスからは見えない状態でしたが、参照できるようにする作業自体は半日で終わっています。分かれていた理由は、技術的な制約ではありません。運用の経緯でした。

分かれている記録が、なぜ分かれているのかを先に確かめてください。運用の経緯であれば、つなぐのは難しくありません。

検知したら？解約の予兆への4つの打ち手

データが揃い、検知が動き始めると、次に必要になるのは打ち手です。前章までで触れたとおり、気づいても動く人が決まっていなければ結果は変わりません。打ち手は検知の精度が上がってから考えるものではありません。検知を始める前に決めておくものです。そこでここでは、解約の予兆を検知したあとの4つの打ち手を整理します。

打ち手は変化の種類ごとに決めておきます。どの変化が現れたかで打ち手を分けておくと、担当者は通知を見た時点で動けます。

打ち手①利用が止まった機能の使い方を届ける

1つ目は「利用が止まった機能の使い方を届ける」打ち手です。変化①の利用人数の減少に対応します。

届ける内容は、減った利用者の部署が使っていた機能に絞ります。全機能の案内を送っても読まれません。誰がどの機能を使わなくなったかが分かっていれば、内容は絞れます。

この工程管理クラウドの会社では、現場の職長が使う日報の入力機能で利用が止まる例が多くありました。カスタマーサクセスの担当者は、この機能に限定した3分の動画と、現場向けの操作手順を用意しています。届けた32社のうち、19社で利用人数が回復しました。回復しなかった13社は、担当者の異動で運用が止まっており、機能の案内だけでは変わりませんでした。

届ける内容を顧客ごとに変える設計については、ハイパーパーソナライゼーションの記事で解説しています。

打ち手②窓口の担当者に会いに行く

2つ目に挙げるのは、窓口の担当者に会いに行く打ち手です。変化②の問い合わせの質の変化に対応します。

会いに行く目的は、社内で何が検討されているかを確かめることです。契約やデータの問い合わせが増えている背景には、予算の見直しや別の選択肢の検討があります。この事情は、オンラインの定例では出てこないまま、対面の場で出てくる場合があります。

この会社では、データの出力方法を問い合わせた顧客に対して、担当者が訪問する運用にしました。訪問した14社のうち9社で、実際に社内で別の製品が検討されていたことが分かっています。残る5社は、監査対応や社内報告のための出力でした。

問い合わせの内容だけでは背景が分からないため、確かめる工程を打ち手に組み込んでください。訪問しても別の選択肢の話が出てこなければ、その顧客は通知の一覧から外して構いません。

打ち手③決裁者へ成果の報告を出す

3つ目は「決裁者へ成果の報告を出す」打ち手です。変化③の定例の出席者の変化に対応します。

報告を出す相手は、出席しなくなった部門長です。現場の担当者に渡しても、社内での位置づけは戻りません。導入時に期待されていた成果に対して、いま何が起きているかを数字で示します。頻度は四半期に1度で足り、毎月送ると決裁者にとっては確認の負担になってしまいます。

先ほどの会社では、部門長の欠席が2回続いた顧客に対して、四半期の利用実績と削減できた工数の試算をまとめた1枚の資料を送る運用にしました。送付した21社のうち13社で、次の定例に部門長が復帰しています。

決裁者に届ける情報をどう組み立てるかは、バイヤーイネーブルメントの記事が参考になります。

打ち手④更新の条件を先に提示する

4つ目は「更新の条件を先に提示する」打ち手です。変化④の更新の話題の先送りに対応します。

先に提示する理由は、顧客が社内で比べる段階に間に合わせるためです。先送りされている間に社内では別の選択肢が検討されており、こちらの条件が出ていなければ比較の対象にすらなりません。

この工程管理クラウドの会社では、更新の話題が2回先送りされた顧客に対して、次の期の条件を書面で提示する運用に変えました。提示した28社のうち22社が更新しています。更新しなかった6社は、いずれも提示より前に別の製品の導入を決めていました。提示しなかった期の同じ状況の顧客の更新率は、これより低い水準です。

先送りは待つ理由にはなりません。条件を出す側から動く判断が要ります。

解約の予兆の検知でつまずく3つの落とし穴

ここまで示した打ち手を用意しても、運用の設計を誤ると通知が流れるだけの状態になります。この工程管理クラウドの会社も、運用の初月は通知の41%しか開かれていませんでした。打ち手をそろえた直後ほど、拾える変化を増やしたくなり、通知の件数が膨らみます。そこでここでは、解約の予兆の検知でつまずく3つの落とし穴を整理します。

失敗の多くは、通知の量と運用の順番から生まれます。すべての変化を通知させた時点で、担当者は通知を開かなくなります。

落とし穴①すべての変化を通知させる

1つ目は「すべての変化を通知させる」という落とし穴です。検知の仕組みが動き始めると、拾える変化はいくらでも増やせます。漏れをなくそうとして条件を緩めると、通知の件数が増えます。

件数が増えると、担当者は通知を読まなくなります。60社の担当者に週30件の通知が届けば、開く時間がありません。開かれない通知は、検知していないのと同じ結果になります。

先ほどの会社の初月は、変化が1つでも現れた顧客をすべて通知する設定でした。週あたり平均38件が届き、担当者が開いた割合は41%です。条件を「2つ以上が重なった顧客」へ変えたところ、週あたり11件に減り、開いた割合は86%まで上がりました。

通知は減らすほうが効きます。読まれない通知に価値はありません。

落とし穴②検知の精度を上げてから運用する

2つ目に挙げるのは、検知の精度を上げてから運用するという落とし穴です。誤検知を減らしてから始めたいという判断は自然に見えます。

この順番が問題になるのは、精度を測る材料が運用のなかにしかないためです。通知した顧客がその後どうなったかを見なければ、条件が適切かどうかは判断できません。運用を止めたまま条件を検討しても、根拠は増えません。

この工程管理クラウドの会社も、当初は3か月かけて条件を詰めてから公開する計画でした。データ担当の1名が「動かさないと調整の材料が出ない」と提案し、過去の解約を並べ終えた4週目に最初の条件を決めて動かしています。結果として、条件の調整は運用の1か月目に集中しました。

定着まで伴走してほしい場合は、動かしながら条件を調整する進め方を採れるかが判断材料になります。

落とし穴③打ち手を担当者の判断に任せる

3つ目は「打ち手を担当者の判断に任せる」落とし穴です。通知だけを届けて、そのあとの対応を担当者に委ねます。

委ねると、構造③で挙げた「動く人が決まっていない」状態がそのまま残ります。通知が届くようになっても、接触までの19日は短くなりません。仕組みを入れた効果が出ないため、通知は不要だと判断されます。

この会社は、条件に入れた3つの変化それぞれに打ち手を対応づけてから通知を始めました。通知の文面に「この変化にはこの打ち手」という対応が書かれているため、担当者は判断せずに動けます。予兆を検知してから接触するまでの日数は、平均19日から4日へ短くなりました。

順番を逆にして通知だけを先に出すと、情報が届くだけで終わります。変化と打ち手の対応表を作ってから、通知の設定に入ってください。

ソリューション営業に特化した支援がほしい場合は、対応表の打ち手を商談の進め方に合わせて書けるかが判断材料になります。

効いている？予兆の検知を測る4指標

ここまで示した落とし穴を避けて運用を続けられるようになったあと、次に必要になるのは効果の説明です。解約率だけを見ても、検知の仕組みが効いたのか市況が変わったのかは判別できません。続けるかどうかを経営層に判断してもらうには、解約率とは別の数字で示す必要があります。そこでここでは、解約の予兆の検知が効いたかを測る4つの指標を整理します。

測る対象は解約率の手前にあります。検知が効いたかは、予兆を検知してから顧客へ接触するまでの日数で測ります。

指標①予兆を検知してから接触するまでの日数

1つ目は「予兆を検知してから接触するまでの日数」です。通知が届いてから、担当者が顧客へ連絡するか訪問するまでの期間を数えます。

この日数が最初の指標になるのは、仕組みの効果が最も早く現れる箇所だからです。解約率が動くまでには契約の更新を1周する必要がありますが、接触までの日数は翌週から変わります。

当初の目的は「更新の直前まで気づかない状態をなくすこと」でしたが、この工程管理クラウドの会社では設計前の接触までの日数が平均19日でした。運用の6か月後には4日まで短くなっています。打ち手を先に決めた効果が、この数字に出ました。

記録が残っていないなら、直近で解約した数件をたどるだけでも現在の日数は出せます。全件をそろえなくても、比較の起点にはなります。

指標②検知した顧客の更新率

2つ目に挙げるのは、検知した顧客の更新率です。予兆が出た顧客のうち、実際に更新に至った割合を数えます。

この指標を見る理由は、打ち手の効果を直接示すためです。検知しなければ何もしていなかった顧客に対して、打ち手を打った結果がどうだったかが分かります。

先ほどの会社では、運用の6か月で予兆を検知した顧客の更新率が78%でした。同じ期間に予兆が出なかった顧客の更新率は94%です。予兆が出た顧客のほうが低いのは当然ですが、設計前に同じ状態だった顧客の多くは更新に至っていませんでした。

検知した顧客と検知しなかった顧客をまとめて数えてしまうと、打ち手が効いたかどうかは全体の平均に埋もれます。分母を分けて出すところまでが、この指標の測り方です。継続して測る仕組みは、自律モニタリングの記事で扱っています。

指標③検知されずに解約した件数

3つ目は「検知されずに解約した件数」です。予兆の通知が一度も出ないまま解約に至った顧客を数えます。

この指標が要るのは、検知の条件が漏らしている範囲を示すためです。更新率だけを見ていると、そもそも通知が出なかった顧客が視界から外れます。条件を厳しくするほど漏れた件数は増えるため、更新率と並べて見る必要があります。

この工程管理クラウドの会社では、設計前の半期に解約した25社のうち11社が、事前に兆しとして扱われていませんでした。運用の6か月後は解約17社のうち2社です。この2社は、親会社の方針変更と事業の撤退で、記録に現れる変化がありませんでした。

漏れた件数を数えたら、その顧客に何が起きていたかを1件ずつ読んでください。条件を足す材料になります。

指標④担当者が確認した通知の割合

4つ目は「担当者が確認した通知の割合」です。届いた通知のうち、担当者が開いた割合を数えます。

この指標が役に立つのは、通知の量と内容が適切かを示すためです。割合が下がっているなら、件数が多すぎるか、内容が判断に使えていません。どちらが原因かは、開かれた通知と開かれなかった通知を件数で並べると見分けられます。

この会社の初月は41%でした。通知の条件を「2つ以上の重なり」に絞り、内容に4つの変化のどれが出たかを列挙する形へ変えたところ、6か月後には86%まで上がっています。開かれなかった残りの14%は、担当者が休暇中だった週に集中していました。

割合が下がったら、通知の側を疑いましょう。担当者の意識の問題として扱うと、改善の手がかりが得られません。

解約の予兆の検知に向いている企業の3つの条件

ここまで示した4つの指標で効果を確かめられるのは、そもそも検知が成立する条件を満たしている場合に限られます。どの会社でも同じ効果が出るわけではありません。投資の判断を早くするために、条件を先に確かめます。そこでここでは、解約の予兆の検知に向いている企業の3つの条件を整理します。

顧客数が多ければ効くとは限りません。検知が効くのは、契約が更新の形を持ち、利用の記録が残り、顧客数が目視の限界を超えている企業です。

条件①契約が年単位で更新される

1つ目は「契約が年単位で更新される」条件です。更新のタイミングがあることで、予兆を検知してから打ち手を打つまでの時間が確保できます。

更新の形がない取引では、この設計は成立しません。都度の発注で成り立つ取引の場合、離れる判断は発注のたびに行われ、数か月前の兆しという概念が当てはまらないためです。

先ほどの工程管理クラウドの会社は、420社すべてが年単位の契約でした。更新月が分散しているため、毎月どこかの顧客が更新の時期を迎えます。420社を12か月に割ると、毎月35社前後が更新の対象になる計算です。検知の仕組みは常に稼働している必要がありました。

自社の契約に更新の時期があるかどうかを、先に確かめてください。定義できないなら、別の設計が要ります。

条件②利用の記録が残る製品を提供している

2つ目に挙げるのは、利用の記録が残る製品を提供している条件です。誰がいつ何を使ったかが取れなければ、4つの変化のうち1つが欠けます。

記録が取れない場合でも設計はできますが、問い合わせ・議事録・更新の話題という残る3つの変化で判断することになります。この3種類でも重なりは見られますが、最も早く現れる変化を落とすことになります。

この会社の場合、利用者ごとの記録は取れていました。ただしCRMのレコードと紐づいておらず、データ担当の1名が最初に整えています。取れているかどうかと、使える形になっているかどうかは別の問題でした。

自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合は、この紐づけの設計だけを外部に確認してもらう頼み方もあります。

条件③顧客数が担当者の目視を超えている

3つ目は「顧客数が担当者の目視を超えている」条件です。1人が20社を担当しているなら、4種類の記録を毎週見ることは可能かもしれません。60社を超えると、時間の面で不可能になります。

境目は業種と製品によって変わりますが、担当者が毎週すべての顧客の記録を確認できているかどうかで判断できます。できているなら、検知の仕組みより担当者の基準をそろえるほうが先です。

この工程管理クラウドの会社は1人あたり60社でした。設計の前に7名へ確認したところ、毎週すべての顧客の記録を見ている担当者は1人もいません。この状態が、仕組みを入れる判断の根拠になっています。

ツール設定ではなく業務設計から入ってほしい場合は、担当者が実際に何社を確認できているかの実測から始めるのが判断材料になります。

解約の予兆の検知を始める4つのステップ

前章の3つの条件を満たしているなら、次は着手の順番です。この会社が8週間で運用まで到達できたのは、対象を絞ったからです。全顧客を対象に完全な検知を作ろうとすると、データの整備だけで数か月かかります。そこでここでは、解約の予兆の検知を始める4つのステップを整理します。

最初に手をつけるのは検知の条件ではありません。始めるときに最初に行うのは、過去に解約した顧客を並べて、共通する変化を見つける作業です。

ステップ①過去に解約した顧客を並べる

最初の作業は、すでに解約した顧客の記録を並べることです。直近1年から2年の解約について、解約までの数か月に何が起きていたかを時間軸で並べます。

並べる理由は、検知の基準を実測から決めるためです。基準を感覚で決めると、担当者ごとに違う判断がそのまま仕組みへ移るだけになります。

先ほどの工程管理クラウドの会社は、直近2年の解約38社を対象にしました。カスタマーサクセスの2名とデータ担当の1名で、8週間のうち最初の3週間をこの作業に使っています。1社あたり4種類の記録をたどるため、時間はかかりました。解約の理由が記録に残っていない顧客も、記録の変化だけは追えるため対象に含めています。

対象は全件でなくて構いません。20社ほど並べれば、共通の形は見えます。

ステップ②共通する変化を3つに絞る

並べ終えたら、共通して現れていた変化を絞ります。多くの変化が見つかりますが、最初から全部を条件に入れると通知が増えます。

絞り方は、出現した顧客の割合が高いものから3つを選びます。すべての解約に現れる変化はまずありません。半数以上に現れていれば、条件として使えます。

この会社が38社から抽出した変化は9種類でした。そのうち出現率が高かったのは、更新の先送りが28社、利用人数の減少が26社、部門長の欠席が21社です。この3つを最初の条件にし、問い合わせの質の変化は運用を始めてから追加しました。

条件を足すのは、運用のなかで漏れが見えてからで足ります。最初から4つ以上を入れると、どの条件が効いたのかをあとから分けられません。検知だけで終わらせない全体の設計は、Agentic CRMの設計の記事をご覧ください。

ステップ③検知の対象を1つの区分に限る

条件が決まったら、対象を絞って動かします。全顧客は対象にせず、1つの区分だけに限ります。

絞る理由は、条件の調整を早く繰り返すためです。420社を対象にすると、通知の件数も調整の影響範囲も大きくなります。1つの区分であれば、1週間で結果が見えます。

この会社は、契約金額が中位の120社を最初の対象にしました。上位の顧客は担当者が密に接触しており仕組みの効果が測りにくく、下位は接触の頻度が低すぎて打ち手を打てないためです。小さく始めたい場合は、この1区分からのスモールスタートが、調整の速さと効果の測定を両立させる進め方になります。

対象の選び方は、効果が測れるかどうかで決めましょう。件数の多さでは決めません。

ステップ④打ち手を決めてから通知を出す

最後に、条件ごとの打ち手を決めてから通知を始めます。落とし穴③で挙げたとおり、順番を逆にすると通知は情報のまま止まります。

決めるのは、どの変化にどの打ち手を対応させるかと、誰が実行するかの2点です。実行する人まで決めておかなければ、通知を見た担当者が毎回検討することになります。

先ほどの会社では、3つの条件それぞれに打ち手と実行者を割り当ててから通知を始めました。利用人数の減少はカスタマーサクセスの担当者、部門長の欠席は担当者と上長の2名、更新の先送りは営業の担当者という配分です。運用の開始から、接触までの日数は短くなりました。営業の担当者へ渡す条件については、カスタマーサクセスから引き継ぐ手順も併せて決めています。

以上が、解約の予兆の検知を始める4つのステップでした。

【一問一答】Agentic CRMと解約の予兆に関するよくある質問

ここまで、見つけられない構造から始める手順までを整理してきました。実際に着手する段階では、どの時期から兆しが出るかや、データが揃っていない場合の進め方で手が止まります。社内で提案する場面でも、「どのくらい前から兆しが出るのか」「小さい組織でも要るのか」という問いは避けられません。答えを先に用意しておくと、社内の合意にかかる時間を短くできます。そこで最後に、解約の予兆についてよく寄せられる質問を5つ取り上げます。

質問①解約の予兆はどのくらい前から出ますか？

変化の種類によって時期が違います。この記事で例に挙げた工程管理クラウドの会社が直近2年の解約38社を調べたところ、利用する人数の減少は6か月前から、部門長の欠席は4か月前から、更新の話題の先送りは2か月前までに現れていました。自社の場合も、過去に解約した顧客を並べて実測するのが確実です。20社ほど並べれば、どの変化が何か月前から出るかの平均は取れます。

質問②解約の予兆の検知に必要なデータは何ですか？

利用状況、問い合わせと対応の履歴、定例の議事録、契約の更新情報の4種類です。すべてが揃っていなくても、2種類あれば始められます。この会社では、420社について週次で4種類の記録を並べる形にしました。重要なのは種類の数より、同じ顧客の記録として突き合わせられる状態になっているかどうかです。

質問③解約の予兆を検知しても止められない場合はどうしますか？

止められなかった顧客の記録を残し、条件の見直しに使います。この会社では設計前の半期に解約した25社のうち11社が事前に兆しとして扱われておらず、そのうち2社は親会社の方針変更と事業の撤退で、記録に現れる変化がありませんでした。すべてを止めることは目的になりません。止められる範囲を広げることが目的です。運用の6か月では、予兆を検知した顧客の更新率が78%になっています。

質問④解約の予兆の検知は小さな組織でも要りますか？

担当者が毎週すべての顧客の記録を確認できているなら、仕組みより基準をそろえるほうが先です。この会社はカスタマーサクセス7名がそれぞれ60社を担当しており、設計の前に確認したところ、毎週すべての顧客の記録を見ている担当者は1人もいませんでした。顧客数の多さにかかわらず、1人あたり何社を実際に確認できているかを測るところから判断してください。

質問⑤解約の予兆の基準はどう決めますか？

過去に解約した顧客の推移から決めます。担当者の感覚で決めてしまうと、判断が人によって割れたまま仕組みへ移ってしまうためです。この会社は直近2年の解約38社を対象にし、人数の減少26社、部門長の欠席21社、更新の話題の先送り28社という出現の実測から条件を組み立てました。出現した割合が半数を超える変化を3つ選び、それを最初の条件にする形が扱いやすくなります。

Agentic CRMで見る解約の予兆は、部署に分かれた記録を横断して並べたときにはじめて形になる

解約の予兆を捉えるために最初に取り組むのは、スコアの計算でも予測ツールの選定でもありません。ここまで見てきたとおり、部署ごとに分かれた4種類の記録を、同じ顧客の同じ時間軸へ並べる作業です。本記事では、見つけられない3つの構造から、現れる4つの変化、人手で追えない理由、AIが自律検知する仕組み、整えるデータ、検知したあとの打ち手、つまずく落とし穴、効いたかを測る4つの指標、向いている企業の条件、始める4つのステップまでを、一連の流れとして整理してきました。

例に挙げた工程管理クラウドの会社は、直近2年の解約38社を並べるところから始め、予兆を検知してから接触するまでの日数を平均19日から4日へ、検知されずに解約した件数を半期11件から2件へ変えています。設計にかけたのは8週間と96時間で、年間の解約率は12%から8%に下がりました。記録は揃っているのに読む手が足りていない状態が、まだ残っている企業も多いのではないでしょうか。

合同会社クロスコムでは、CRMのデータをAIが横断して読む前提でのAgentic CRM設計支援を行っています。対象を1つの区分に絞ったスモールスタートから対応していますので、Agentic CRM設計支援までお気軽にご相談ください。本記事で紹介した内容を、ぜひ自社の顧客の状況に合わせて活用し、少しでもお役に立てれば幸いです。