customer health score とは、通常は 0-100 または赤/黄/緑のバンドで表される単一の合成スコアであり、5 つのシグナルファミリー（製品の利用、engagement、sentiment、サポート、成果）を 1 つの指標にまとめたものです。アカウントが更新、拡大、または churn する可能性をどれだけ示すかを表します。これは、40-80 アカウントを担当する CSM が各アカウントを手作業で読まずに注力先を判断できるようにするため、また CS のリーダーシップが net revenue retention を勘ではない何かから forecast できるようにするために存在します。
これが何でないか：churn 予測モデルではなく、NPS でもありません。churn モデルは学習済みの分類器から確率を出力しますが、health score は CSM が顧客に説明できる、透明で手作業で重み付けされた rollup です。NPS は health への 1 つの sentiment 入力であり、その代替ではありません。スコアを優先順位付けの補助ではなく絶対的な真実として扱うことが、チームが最もよくこれを誤用する形です。
5 つのシグナルファミリー
- 利用 — ログイン、feature 採用の幅、プロビジョニング済みに対する有効化された seats、自社の価値提案にマッピングされる feature の深さ。ほとんどの SaaS で最も強力な leading シグナルです。
- Engagement — QBR 出席、email の開封/返信、exec sponsor の反応性、コミュニティや training への参加。
- Sentiment — NPS、CSAT、CES に加えて、CSM が記録した定性的な sentiment。最も柔らかく操作されやすい入力です。
- サポート — チケット数、重大度、解決までの時間、エスカレーション、このアカウントに対する bug の件数。
- 成果 — 顧客は success plan のマイルストーンに到達したか、購入時に求めた ROI を実現したか、time-to-value（TTV）を達成したか。最も計装が難しく、更新を最もよく予測します。
数式
health score は、正規化されたコンポーネントスコアの加重和です。
Health = Σ (component_score_i × weight_i) ここで Σ weight_i = 1.0各コンポーネントはまず 0-100 に正規化され（生のログイン数と生の NPS が同じスケールに乗るように）、その後で重み付けされます。seats ベースの B2B SaaS 製品に対する、擁護できる初期の重みセット：
| シグナルファミリー | 重み |
|---|---|
| 利用 | 0.35 |
| 成果 | 0.25 |
| Engagement | 0.15 |
| Sentiment | 0.15 |
| サポート | 0.10 |
バンド：70-100 は緑、40-69 は黄、40 未満は赤。カットオフは自社の更新データに対して較正してください。過去 12 か月の更新と churn に対してスコアを遡及的に計算し、緑/黄の境界を更新する顧客と churn する顧客を実際に分ける位置に動かします。
Leading と lagging
これがスコアを有用にする区別です。leading シグナルは更新の結果より前に動き、介入可能です。週次のアクティブ利用の低下、退職した champion、低下する QBR 出席などです。lagging シグナルはすでに起きたことを確認します。悪い四半期の後に提出された CSAT、非更新の通知などです。leading シグナルをより高く重み付けしてください。利用と成果の進捗は leading であり、クローズされたサポートチケットとアンケートの回答は lagging です。lagging 入力に支配されたスコアは、アカウントが churn する週に不健全だと教えてくれますが、それでは行動するには遅すぎます。
計算例
あるアカウント：利用を 80、成果を 50、engagement を 90、sentiment を 70、サポートを 60 に正規化。
Health = 80×0.35 + 50×0.25 + 90×0.15 + 70×0.15 + 60×0.10
= 28 + 12.5 + 13.5 + 10.5 + 6
= 70.5 → 緑（ぎりぎり）スコアは緑ですが、成果が 50 であることが重要な弱点です。強い製品利用と満足した sponsor が、顧客が購入時に求めた ROI をまだ実現していないという事実を覆い隠しています。これはまさに、利用のみのスコアが安全だと誤ってラベル付けするアカウントです。CSM のアクションは check-in ではなく、success plan のリセットです。
よくある落とし穴
- 利用のみのスコア。 計装が簡単なので、チームはこれを出してそこで止まります。onboarding 途中のヘビーなパワーユーザーは、欠けている成果によって更新がすでに失われているのに高い利用を示すことがあります。ガード：プロキシしか使えない場合でも、ゼロでない成果の重みを強制します（success plan のマイルストーン達成度）。
- 設定したら放置の重み。 製品とセグメント構成が変わると、重みは現実から乖離します。ガード：四半期ごとに実際の更新/churn の結果に対してスコアを再計算し、重みを再フィットします。緑のバンドが更新する顧客と churn する顧客を分けていない場合、それは較正が誤っています。
- スコアロンダリング。 CSM が入力する sentiment が重い入力である場合、reps は自分の book を緑に保つためにそれを水増しします。ガード：主観的な入力を 0.15-0.20 の範囲に制限し、sentiment を客観的なシグナルに対して監査します。
- 全セグメントに 1 つのスコア。 12 seats の SMB アカウントと 4,000 seats の enterprise アカウントは利用曲線を共有しません。ガード：単一のグローバルな数式ではなく、セグメントごとの重みセットとバンドを維持します。
- アクションのマッピングなし。 誰も行動しないスコアは dashboard の飾りです。ガード：すべてのバンド遷移（緑→黄、黄→赤）が、単なる色の変化ではなく、オーナーを持つ名前付きの play を発火させます。
関連
- NRR vs GRR — health score が予測するために構築される retention の指標
- Gainsight と Planhat — 設定可能な health スコアカードを持つプラットフォーム
- ChurnZero と Vitally — 利用駆動の health と playbook の自動化