「ヘルススコア導入しました」「Excelで毎週手計算してます」

ヘルススコアの実装

利用ログ×サポート履歴×関係性データの合成スコアをパイプライン化し、閾値割れで自動アラート→CSタスク生成につなげる

オンボーディング自動化

契約→キックオフ→初期設定→アクティベーション達成のマイルストーン管理とTTV（Time to Value）計測

ヘルススコアの構成要素を1行ずつ設計するフォーマットです。

利用量の上限接近、新部署ユーザーの追加、上位機能の試用といった動きは、アップセル機会として営業に自動ルーティングする対象になります。逆に、ログイン減少やキーパーソン離脱といった動きは、チャーン予兆として介入プレイブックを起動するトリガーにします。同じ顧客行動データでも、見る角度によって拡大機会にも解約リスクにもなる点が、この設計の面白さであり難しさです。

更新期日から逆算したタスク生成や、QBR資料の自動生成（利用実績データの差し込み）も、CSチームの工数を最も消費する定型業務の自動化対象です。成果指標は、TTV、ヘルススコアと実際のチャーンとの相関、予兆検知からの救済率です。ヘルススコアが実チャーンと相関していなければ、そのスコアリングモデルは見直しが必要というシグナルになります。

例えば、CS担当者が数百アカウントを人手で巡回してヘルスチェックをしていると、対応が後手に回りがちです。利用ログとサポート履歴を合成したスコアが閾値を割った時点で自動的にCSタスクが生成される仕組みにしておけば、担当者は「今どのアカウントを優先すべきか」を毎朝確認するだけで済みます。これは、火が出てから消火するのではなく、煙が出た時点でアラームが鳴る仕組みに近い発想です。

ここで、先に反論しておきます。「アカウント数が少ないうちは、人手のほうが顧客の機微まで見られて丁寧なのでは」という指摘はもっともです。実際、少数の重要顧客についてはハイタッチな人手対応が適しています。ただし、それは全アカウントを人手で巡回すべき理由にはなりません。自動化はむしろ「どのアカウントに人手をかけるべきか」を絞り込むためのフィルターであり、人手対応の質を落とすものではなく、質を上げるための前段階として機能します。

ヘルススコアと実際のチャーンが相関しない場合、何を見直すべきですか

スコアを構成する項目（利用ログ、サポート履歴、関係性データ等）の重み付けや、そもそも対象としている行動指標が的外れになっていないかを見直します。相関の弱いスコアを運用し続けると、CS担当者の優先順位付けそのものが機能不全になります

エクスパンションシグナルとチャーン予兆シグナルは同じデータから作れますか

はい。同じ顧客行動データでも、見る角度によって拡大機会にもなり解約リスクにもなります。例えば利用量の増加はアップセル機会、ログイン頻度の減少はチャーン予兆というように、指標の方向性で使い分けます

オンボーディング自動化はどこまで自動化すべきですか

契約からアクティベーション達成までのマイルストーン管理とTTV計測は自動化に向いていますが、初期の要件確認やカスタマイズ相談など、個社ごとの事情が絡む部分は人による対応が必要なことが多いです。定型部分と個別対応部分を切り分けて設計します

今、CS担当者が「このアカウント危ないかも」と気づくきっかけは、システムのアラートですか、それとも担当者自身の勘や経験ですか。もし後者に頼っている割合が大きいなら、その担当者が休んだ日に見逃されるリスクが常にあるということです。