チャーン予測モデルの構築｜機械学習による解約リスクスコアの構築

ヘルススコアを運用し始めると、やがて「閾値を超えたら対応する」というルールベースの管理に限界を感じる場面が訪れます。「なぜこの閾値なのか」「複数の変数が複合したときにどう判断するか」という問いに、ルールベースの仕組みは答えを出せないからです。

この記事では、機械学習を使ったチャーン予測モデルの構築プロセスを、データ準備から変数設計・モデル選択・精度評価・実務への落とし込みまで、手順ベースで解説します。対象読者は、ヘルススコアの運用経験があり、次のステップとして予測モデルの構築を検討しているCSマネージャー・CS担当者・データ分析担当者です。

データドリブンCS全体の体系を確認したい場合は、先にデータドリブンCSの全体像と組織設計をご覧ください。本記事はそこから派生したクラスター記事として、予測モデルの構築プロセスに特化して掘り下げます。

チャーン予測モデルとは何か：ルールベースとの本質的な違い

チャーン予測モデルとは、過去の解約データから「解約に至った顧客の行動パターン」を機械学習で学習し、現在の顧客ごとに解約確率（リスクスコア）を出力するモデルです。ルールベースの管理との最大の違いは、変数の重み付けをデータが自動的に決定する点にあります。「ログイン回数が週1回未満なら警告」というルールは担当者が立てた仮説の検証にとどまりますが、機械学習モデルはデータの中から人間が見落としていた組み合わせパターンを発見できます。

ただし、モデルが機能するには「解約ラベルのついた十分な過去データ」と「解約前の行動ログ」が整備されている必要があります。本記事では、構築の前提条件から実運用までの全ステップを順に解説します。

ルールベース管理の限界：どこで天井に当たるか

ルールベース管理の課題は、大きく3点に整理できます。

• 閾値の恣意性 「週1回未満のログインを警告とする」という設定の根拠は、担当者の経験則に過ぎません。データに基づく最適値とは限らず、製品や顧客セグメントが変わるたびに手動で見直す必要があります。
• 変数間の交互作用を捉えられない ログイン回数が少なくてもサポートへの問い合わせが多い顧客は、積極的に活用しようとしている健全な状態の可能性があります。単一の閾値ルールは、こうした組み合わせの意味を解釈できません。
• 顧客セグメントをまたいだ汎化が難しい エンタープライズと中小企業では利用パターンが根本的に異なります。セグメントごとにルールを設定すると、管理すべきルールの数が爆発的に増加します。

機械学習モデルが「次のステップ」になる条件

機械学習による予測モデルへの移行は、次の条件がそろった段階で現実的な選択肢になります。

• 過去の解約データが一定数蓄積されている
• 解約ラベルと紐づく行動ログが時系列で取得できている
• ルールベースでのヘルス管理が一定期間運用されており、変数候補がある程度整理済みである

逆に言えば、解約事例が数件しかなく行動ログが断片的な状態では、機械学習モデルを作ることはできても意味のある精度は出ません。この場合は、まずヘルススコアの変数整理とデータ基盤の整備を優先する段階です。ヘルススコアの高度化と変数設計については別記事で詳しく解説しています。

予測モデル構築の前提：データ準備と目的変数の定義

モデル構築で最初に躓くのは「コードの書き方」ではなく「何を予測するか」の定義です。目的変数（解約したかどうかのラベル）の定義が曖昧なままモデルを作ると、実務で使えないスコアが出力されます。たとえば「解約」の定義を「契約終了」に限定するか「ダウングレード・縮小」を含めるかで、ラベルの作り方も変数の意味も変わります。この定義への投資が、後工程の品質を大きく左右します。

目的変数の定義：「解約」の範囲を決める

目的変数の設計では、以下の3点を最初に確定します。

• 対象期間の設定 「向こう90日以内に解約するかどうか」のように、予測の対象期間を明示します。この期間が短すぎると介入の時間が確保できず、長すぎると予測精度が落ちます。CS担当者が実際に介入できるリードタイムを踏まえ、60〜90日を目安に設定することが多いです。
• 解約の定義 完全解約のみを対象とするか、ダウングレード・一部機能停止も含めるかを決めます。どちらを含めるかによって学習データのサンプル数と変数の意味が変わるため、ビジネス上どちらを防ぎたいかを先に議論します。
• 予測ウィンドウとオブザベーションウィンドウの設計 「観測期間（特徴量を収集する期間）」と「予測期間（解約有無を確認する期間）」を時間軸上で明確に分離します。この設計が次項のデータリーケージ防止に直結します。

学習データの構造設計

学習データは、顧客ごと・時点ごとのスナップショット形式で設計します。特定の時点における顧客の状態を1行として表現し、その後の解約有無をラベルとして紐づけます。

注意すべき点は、データリーケージです。データリーケージとは、予測時点では知り得ない「未来の情報」が学習データに混入してしまうことを指します。たとえば「解約手続き開始のログ」を特徴量に含めると、モデルは「解約手続きをした顧客が解約する」という自明な関係を学習するだけになり、実務で予測に使えません。

時間軸の切り方として、観測ウィンドウの終点と予測ウィンドウの開始点を明確に分離し、予測ウィンドウ内のデータは特徴量から除外することが基本ルールです。

解約サンプル数が少ない場合の対処

SaaSのチャーン率は多くの場合、全顧客の数%程度です。これにより、学習データは「解約なし」サンプルが圧倒的多数を占めるクラス不均衡の状態になります。

代表的な対処方法は以下のとおりです。

• オーバーサンプリング 少数クラス（解約あり）のサンプルを合成的に増やし、学習データのバランスを取る手法です。実際のサンプルを複製するのではなく、特徴量空間で補間した合成データを生成するアプローチが知られています。
• コスト敏感学習 解約ありのサンプルを誤分類した場合のペナルティを重くするように学習アルゴリズムに指定します。多くのライブラリでclass_weightパラメータとして設定できます。

なお、解約事例が少ない段階では、複雑な手法よりロジスティック回帰のような解釈可能な簡易モデルを優先する判断が現実的です。データが少ない状況で複雑なモデルを使うと、学習データへの過学習が深刻になります。

特徴量（変数）の設計：何がチャーンを予測するか

特徴量の設計が、モデルの予測精度とCSMによる解釈可能性の両方を決定します。「取得できるデータをすべて入れる」アプローチは、モデルの精度を上げるどころか過学習・解釈困難・メンテナンスコストの増大につながります。SaaSのCS文脈で実績のある変数群をカテゴリ別に整理します。なお、どの変数が有効かは自社の顧客セグメントや製品特性によって異なるため、後述の特徴量重要度の確認を必ずセットで実施します。

プロダクト利用系変数

プロダクトの利用状況は、顧客が製品から価値を得ているかどうかを直接示す変数群です。

• ログイン頻度・セッション時間 直近30日・90日の集計値に加え、直前の同期間との比較による変化率を変数に加えます。絶対値より「減っているかどうか」が予測に寄与することが多いです。
• コア機能の利用率 製品ごとに「使われていることが価値を感じている証拠となる機能」を定義します。ダッシュボードの閲覧だけでなく、データの入力・出力・他機能への展開など、深い関与を示す行動を指標にします。
• 機能到達深度 上位機能・高度な機能に到達しているかどうかを変数化します。オンボーディング段階にとどまっている顧客はチャーンリスクが高い傾向があります。
• 直近トレンド 利用が増加傾向か減少傾向かを、変化率として表現します。先月比・3ヶ月前比の両方を特徴量に加えることで、急落と緩やかな減少を区別できます。

サポート・エンゲージメント系変数

• サポートチケット数・未解決率・解決までの時間 チケット数が多いこと自体はリスクではなく、未解決率や解決まで長期間かかっている場合がリスクシグナルになります。
• オンボーディング完了率・トレーニング参加有無 初期段階の関与度は、長期的な継続率と相関することが知られています。
• CSMとの接触頻度 定期レビューの実施有無・メール開封率・最終接触からの経過日数を変数化します。
• NPS・CSATの回答有無と直近スコア スコアの値だけでなく「回答しているかどうか」自体が関与度の指標になります。

契約・商務系変数

• 契約更新までの残日数 更新直前の一定期間は解約判断が固まりやすいため、残日数は重要な変数です。
• プラン（ティア）・シート数の推移 ダウングレードや利用ライセンス数の削減は解約の前兆として機能することがあります。
• 契約開始からの経過月数 初期（特に契約後3〜6ヶ月以内）のチャーンリスクが高い製品では、契約年齢を変数に含めることで初期チャーンと後期チャーンのパターンを区別できます。
• 過去の更新・ダウングレード履歴 一度ダウングレードした顧客の解約率が高い場合、この履歴が強力な予測変数になります。

LTV・NRR改善のための分析手法では、契約更新・拡張に関わる指標の設計についてさらに詳しく解説しています。

特徴量エンジニアリングの実務ポイント

• 生の数値より「変化率」「トレンド」を変数に加える 「先月のログイン回数が10回」という絶対値より「先月比のログイン増減率が-50%」のほうが予測に寄与することが多いです。絶対値と変化率の両方を特徴量として用意します。
• 欠損値の扱い NPS未回答を「0点扱い」にするか「回答しなかった」という別フラグを立てるかによって意味が変わります。「未回答＝関心が低い」という解釈を採用する場合は、その前提を明示した上で運用します。
• カテゴリ変数のエンコーディング プランティア・業種・従業員規模などのカテゴリ変数は、数値に変換する必要があります。順序のある変数（プランティア）は順序エンコーディング、順序のない変数（業種）はOne-Hotエンコーディングが基本です。

モデル選択と学習：実務で使われるアルゴリズム

CSの予測モデルには「精度が高いこと」と同時に「なぜそのスコアが出たかをCSMが説明できること」が求められます。精度最大化だけを目指してブラックボックス化したモデルは、CSMが「このお客様はなぜリスクが高いのか」を顧客に説明できず、実務での活用が止まります。初期構築では解釈可能性を重視したモデルを選び、精度が不十分であれば段階的に複雑なモデルへ移行する判断が現実的です。

ロジスティック回帰：まず試すべき基準モデル

ロジスティック回帰は、各変数の係数から「この変数が1単位増えると解約確率がどれだけ変化するか」を直接読み取れる点で、解釈可能性が最も高いモデルです。

• メリット 変数の係数が直接解釈でき、CSMへの説明が容易です。学習も速く、データが少ない段階でも過学習しにくいです。
• 適した場面 データが少ない段階・説明責任が重い組織・ベースラインを早く確認したい場合。
• 実装上の注意 特徴量のスケーリング（標準化）が必要です。変数間のスケールが大きく異なると係数の比較ができなくなります。

決定木・ランダムフォレスト：解釈性と精度のバランス

決定木は「ログイン回数が30回未満かつサポートチケット未解決が2件以上なら高リスク」のような判定条件を可視化でき、CSMに判断プロセスを見せやすいモデルです。

ランダムフォレストは複数の決定木を組み合わせた手法で、特徴量重要度（Variable Importance）を出力できます。「どの変数がスコアに最も寄与しているか」をランキング形式で確認できるため、変数選定の根拠として活用しやすいです。

• 適した場面 データが中程度（数百件以上）以上あり、変数の重要度を確認しながら特徴量設計を改善していく段階。

勾配ブースティング（XGBoost・LightGBM）：精度を優先する場合

勾配ブースティング系のアルゴリズムは、一般的に分類精度が高い反面、モデル自体はブラックボックスになります。実務での活用には、SHAP（SHapley Additive exPlanations）による個別顧客スコアの要因分解が必要です。

SHAPを使うと、この顧客のリスクスコアが高くなった理由を、ログイン頻度の急減・NPS未回答・コア機能の未到達といった要因ごとに分解して示すことができます。これをCSMに提示することで、「なぜこの顧客にアクションするか」の根拠を共有できます。CSオペレーションにおけるAI活用では、SHAP値の実務表示を含むAIツールの導入パターンを解説しています。

• 適した場面 データが十分にあり・モデルの運用体制が整っており・精度改善の余地を積極的に追う段階。SHAP値の計算・表示の仕組みをセットで整備できる環境であること。

モデルの評価指標：正確率だけでは実務で使えない理由

モデルの評価を「正確率（Accuracy）」だけで見てはなりません。解約率が低い場合、「全員を解約しない」と予測するだけで正確率は高くなりますが、これは実務で何の役にも立ちません。CSにおけるチャーン予測では、「見落とし（見逃した解約）のコスト」と「空振り（リスクなし顧客への無駄な介入）のコスト」を踏まえた評価指標を使います。

混同行列と精度・再現率・F1スコア

混同行列は、予測結果を「正しく検知した解約（True Positive）」「見逃した解約（False Negative）」「誤ってリスクとした非解約（False Positive）」「正しく非リスクとした非解約（True Negative）」の4セルで表します。

ここから導かれる主要指標は以下のとおりです。

• Precision（適合率） リスクありと予測した中で、実際に解約した割合。CSMが空振りアクションに時間を使わなくて済むかを示します。
• Recall（再現率） 実際に解約した顧客のうち、リスクありと正しく検知できた割合。解約を見落としていないかを示します。
• F1スコア PrecisionとRecallの調和平均。単一指標でバランスを確認したい場合に使います。

CSでは一般的に「解約を見落とす（Recall低下）」ことのコストが「空振りアクション（Precision低下）」より大きいため、Recallを優先する評価設計になることが多いです。

AUC-ROCとAUC-PRC

• AUC-ROC 分類閾値を動かしたときの精度と再現率のトレードオフを面積で表した指標です。1.0が完全な予測、0.5がランダムと同等です。クラス不均衡が比較的小さい場合の標準指標として使われます。
• AUC-PRC（Precision-Recall Curve下面積） クラス不均衡が大きい場合（解約が全体の数%）は、AUC-ROCより実態を正確に反映します。解約事例が少ないSaaSデータではAUC-PRCを合わせて確認することを推奨します。
• 実務的な評価の考え方 AUC-ROCの絶対値よりも、自社データで「ランダム選定との比較でどれだけ改善したか」を確認することが重要です。データの質・特性・クラス比率によって適切な水準は異なります。

閾値の設定：スコアをどこでリスクありに分類するか

モデルが出力するのは「解約確率0.0〜1.0」の連続値です。これを「リスクあり・なし」に二分するには閾値の設定が必要ですが、デフォルトの0.5が最適とは限りません。

実務的には、「CSMが週に対応できるリスク顧客は何社か」を先に決め、スコアの上位N社を対象にする運用のほうが現実に即しています。CSチームが5社しか対応できない週に20社をリスクありにしてもアクションにつながらないからです。閾値を変えるとPrecisionとRecallはトレードオフの関係で動くため、ROCカーブを確認しながら自社のキャパシティに合わせた設定を選びます。

予測スコアの実務運用：CSMが使えるかたちに落とし込む

予測モデルの最大の失敗パターンは「スコアは出ているがCSMが何をすればよいかわからない」状態です。スコアはアクションに接続されて初めて価値を持ちます。スコアの更新頻度・CSMへの表示設計・スコアに紐づくプレイブックの整備がセットで必要です。Mazrica Salesをはじめとするデータ管理基盤にスコアを組み込み、CSMが日常業務の中でリスク情報にアクセスできる設計を検討してください。

スコアの更新頻度とトリガー設計

スコアの更新方法には、大きく2種類のアプローチがあります。

• 定期更新（週次・月次） 全顧客を定期的に再スコアリングします。安定したベースラインを提供しますが、急変を即時に捉えられない弱点があります。
• イベントドリブン更新 「ログイン停止が7日継続」「サポートチケットが週3件以上急増」などの特定シグナルを検知したタイミングで即時スコアを更新します。急激な変化を見逃しません。

実務上は両方を組み合わせる形が機能しやすいです。週次の定期スコアリングで全顧客の優先度を把握しながら、重要シグナルが発生した顧客についてはリアルタイムアラートで通知する設計です。

CSMへのスコア表示設計

スコアをCSMに提示する際には、数値そのものより「見て何をすべきかわかる設計」を優先します。

• スコアの数値（0〜100等）に加えて主要因を併記する 「なぜそのスコアか」がわからないと、CSMはスコアを信頼できません。SHAP値を活用して「ログイン頻度低下・NPS未回答」のように上位2〜3因子を表示します。
• 優先度ランク（High/Medium/Low）に変換する 細かいスコア差より「今週対応すべきかどうか」の判断を助けるランク表示のほうがCSMの認知負荷を下げます。
• 利用中のCRM・CS管理ツールへの組み込み CSMが日常的に使うツールにスコアが表示されない限り、予測モデルの存在は忘れられます。

スコアに紐づくプレイブックの設計

スコアが出るだけでは、CSMの行動は変わりません。スコア別・リスク因子別のアクションをあらかじめ定義したプレイブックが必要です。

プレイブックの設計例は以下のとおりです。

• ログイン減少が主因でリスクHighの場合：利用活性化のユースケース提案メールを送付する
• サポートチケット未解決が主因の場合：CSMが直接連絡し、課題ヒアリングとエスカレーションを実施する
• 契約更新まで60日以内・スコアMediumの場合：定期レビューの日程調整と利用状況のレビューを開始する

プレイブックがない状態では、スコアが上がってもCSMが個人判断で動くため、属人化は解消されません。スコアの設計とプレイブックの設計は同時並行で進めることを推奨します。CSオペレーション最適化の体系では、プレイブック整備を含むオペレーション設計の全体像を解説しています。

モデルの継続的な改善と陳腐化への対処

機械学習モデルは一度作れば永続するものではありません。顧客構成の変化・製品のアップデート・市場環境の変化により、構築時点で有効だった変数やパターンがいつの間にか実態と乖離します（コンセプトドリフト）。モデルのパフォーマンスを定期的に監視し、再学習のタイミングを計画的に設計することが、予測精度を維持するうえで不可欠です。

モデルのパフォーマンス監視

パフォーマンス監視は、予測スコアと実際の解約結果を定期的に照合することから始まります。

• Precision/Recallの推移をトラッキングする 月次・四半期ごとに精度指標を記録し、傾向的な低下が見られた段階で再学習を検討します。
• データドリフトの確認 学習時と現在の特徴量の分布が大きくずれていないかを確認します。たとえば、製品のアップデートで利用パターンが変化した場合、学習時のログイン頻度の分布と現在の分布が乖離します。

再学習のタイミングと戦略

再学習には2つのアプローチがあります。

• 定期再学習 四半期ごとに直近データを追加して再学習します。予測精度の低下を待たずに定期的に最新化する方法で、安定した運用に向いています。
• トリガー型再学習 Recallが設定した基準（例：0.70）を下回った場合のみ再学習します。再学習コストを抑えたい場合に適しています。

再学習時のデータ設計として、直近データに重みをつけるか古いデータを除外するかも判断が必要です。製品や顧客構成が大きく変わった場合は古いデータの除外を、継続的な変化の場合は重み付けを選ぶことが多いです。

「モデルの判断を疑う」文化の醸成

定量的な監視に加え、モデルが低リスクと評価したにもかかわらず解約した顧客の事例を定期的にレビューする習慣が重要です。このレビューから「モデルが捉えていなかった変数候補」が見つかることが多いです。

CSMが「このお客様は現場感覚ではリスクが高いと思っていたが、スコアは低かった」という違和感を言語化し、それを変数候補としてモデルにフィードバックする仕組みを設計します。データ担当者とCSMの定期的な共同レビュー（月次30分程度）が、この文化を支える実務的な仕組みになります。

構築に失敗するパターンと現実的な進め方

チャーン予測モデルの構築プロジェクトが途中で止まる理由の多くは、技術的な問題ではありません。「精度の高いモデルを作ること」を目的にしてしまい、「CSMが毎日使える状態にすること」を後回しにすることが最大の失敗パターンです。データドリブンCS全体の落とし穴についてはデータドリブンCSの全体像と組織設計が詳述しています。ここでは予測モデル構築固有の失敗パターンに絞って整理します。

よくある失敗パターン

• データ準備の過小見積もり データ収集・クレンジング・ラベリングに多くの工数が費やされます。「解約日のログ」「行動ログ」「CSM活動記録」が別々のシステムに散在している場合、これらを結合して学習データを組み立てる工程だけで数週間かかることがあります。モデリングに直行しようとするとデータ品質問題で頓挫します。
• 精度追求と実運用の乖離 高いAUC-ROCのモデルを作っても、CSMがスコアの意味を説明できなければ使われません。精度よりも「CSMが顧客に説明できるスコアかどうか」を評価基準に加えます。
• CSMの関与なしに設計する 変数の候補や閾値の実務妥当性は、CSMのフィールド知見なしには決められません。「この顧客は実際には健全だったが、ログイン数だけ見ると低かった」という現場感覚が、変数設計を正します。データ担当者だけで設計を完結させないことが重要です。
• 「まず完璧なモデルを」という先延ばし 解約事例が少ない段階でもロジスティック回帰で試算を始められます。精度が低くても「ランダムより少し良い」状態であれば、CSMが優先対応すべき顧客の絞り込みに使えます。完璧を待つより、早期に動かして改善するサイクルに入ることを優先します。

現実的な段階的アプローチ

以下の4ステップで段階的に進めることを推奨します。

1. （2〜4週間） 過去の解約データを手動でレビューし、解約前に共通していた変数候補を3〜5個特定します。この作業は、ヘルススコアの変数整理と並行して実施できます。
2. （1〜2週間） Step 1で特定した変数でロジスティック回帰を組み、AUC-ROCとRecallを確認します。ベースラインとして「ランダムな選定と比べてどれだけ解約を先読みできるか」を数値で把握します。
3. （1〜2週間） スコアを既存のCSツールへ出力し、CSMが週次でレビューできる状態にします。表示設計・閾値・プレイブックの初版を合わせて整備します。
4. （継続） CSMのフィードバック（「このスコアは実態と合っていなかった」等）を受けながら変数を追加・精度を改善します。モデルの性能監視と再学習もこの段階から計画的に組み込みます。

まとめ：チャーン予測モデルを「使い続ける」ための判断軸

ルールベース管理から予測モデルへの移行は、「精度向上」そのものが目的ではありません。本来の目的は「アクションの根拠を標準化し、CSMが個人判断なしに適切なタイミングで動ける状態を作ること」です。この目的を見失うと、精度の高いモデルを作りながらCSMに使われないまま終わるという失敗に陥ります。

モデル選択は、最初から複雑なアルゴリズムに頼らず、解釈可能性を優先する段階を経てから精度改善に進みます。スコアはプレイブックとセットで運用設計し、CSMのアクションに直結させます。定期的なパフォーマンス監視と再学習の計画は、構築時点から組み込んでおくことで、モデルの陳腐化を防げます。

データドリブンCSの体系全体・組織設計・指標の優先順序については、データドリブンCSの全体像と組織設計を合わせてご参照ください。

よくある質問

チャーン予測モデルを構築するのに最低どのくらいの解約データが必要ですか？

解約事例が少ない状態では、モデルを学習させても学習データへの過学習が深刻になり、未知の顧客への予測精度が確保できません。解約事例が少ない段階では、ロジスティック回帰のような単純なモデルを使い、変数を絞ることで対応します。また、ダウングレードや一部機能停止を「解約」に含める定義に広げることで、サンプル数を補う方法もあります。

機械学習の専門知識がないCSチームでも予測モデルを構築できますか？

ロジスティック回帰やランダムフォレストの初期モデルであれば、Pythonの基礎的な操作ができる担当者が1名いれば着手できます。ただし実際の難易度はデータの整備状況や組織の技術環境によって大きく異なります。より高度なモデル（XGBoost・LightGBM・SHAP統合）には機械学習の実務経験が必要です。専門知識が社内にない場合は、初期構築をデータアナリストや外部パートナーに依頼し、変数選定とプレイブック設計にCSMが主体的に関与する分担が現実的です。

ヘルススコアとチャーン予測スコアは別々に管理すべきですか、それとも統合すべきですか？

運用の目的が異なるため、初期は別管理が整理しやすいです。ヘルススコアは「顧客の現在の状態」を多角的に可視化する指標であり、チャーン予測スコアは「一定期間内に解約する確率」を出力するものです。両者は補完的な関係にあり、ヘルススコアの構成変数がチャーン予測モデルの特徴量として使われることが多いです。運用が成熟してきた段階では、予測スコアをヘルススコアの一要素として組み込む統合設計も選択肢になります。

チャーン予測モデルの予測精度はどの程度あれば実務で使えますか？

精度の適切な水準はデータの質・顧客数・クラス不均衡の程度によって異なります。実用的な判断基準は「ランダムに選んだ顧客に介入するより、モデルが選んだ顧客に介入したほうが解約を防げているか」です。精度が低くても、ランダム比で解約検知率が向上しているなら実務的な価値があります。精度そのものより「CSMのアクション改善につながっているか」を評価指標にすることを推奨します。

予測モデルを導入したCSチームはどのような効果を得ていますか？

予測モデルの導入効果として報告されることが多いのは、「解約の早期検知による介入リードタイムの確保」「CSMが対応優先度をスコアで判断できるようになったことによる属人化の低減」「ハイリスク顧客への集中対応によるチャーン率の改善」の3点です。ただし、効果の大きさは自社のデータ品質・CSMのアクション設計・プレイブックの整備状況に依存します。モデルを導入するだけで自動的に効果が出るものではなく、スコアに紐づいたプレイブックとCSMのオペレーション変更がセットで必要です。