解約予兆を見逃さないヘルススコア設計プロンプト｜指標・重み・判定基準を一度に整理
カスタマーサクセスのヘルススコアを設計したいものの、「ログイン回数を何点にするか」「問い合わせ増加を危険信号として扱うか」で止まってしまう担当者向けのテンプレートです。
このプロンプトを使うと、顧客データの候補から次の項目をまとめて整理できます。
- スコアに採用する指標と採用理由
- 指標ごとの重み
- Green・Yellow・Redの判定基準
- データ不足や例外の扱い
- 検証方法と見直し条件
最も重要なのは、AIに点数を決めさせるのではなく、点数の根拠と検証方法まで出させることです。ヘルススコアは完成品ではなく、解約・更新・活用拡大との関係を確認しながら調整する仮説として設計します。
何に使えるプロンプトか
このテンプレートの用途は、散在している顧客情報を「担当者が次の行動を決められるスコア仕様」に変えることです。
ヘルススコアは、顧客の利用状況や満足度などを一つの値や段階にまとめたものです。ChurnZeroのハンドブックでも、数値、文字、Green・Yellow・Redといった表示方法が紹介されています。
ただし、色を付けるだけでは実務で使えません。たとえばRedになった顧客について、担当者が「利用促進を提案するのか」「決裁者との面談を設定するのか」を判断できる必要があります。
このプロンプトでは、次の完成物を狙います。
- 人が確認しやすいMarkdown形式の設計書
- システム実装へ渡しやすいJSON形式の計算定義
- スコア別の推奨アクション
- 過去データで検証するための手順
ここがポイント: ヘルススコアは顧客の評価表ではありません。支援の優先順位と次の行動を決めるための業務ルールです。
コピペ用プロンプトテンプレート
以下をChatGPTなどの汎用LLMへ貼り付け、{}内を自社の情報に置き換えてください。顧客名や担当者名は不要です。集計済み、または匿名化した情報を使います。
あなたはB2B SaaSのカスタマーサクセス業務とデータ分析を支援する設計者です。
以下の情報を基に、顧客ヘルススコアの初期設計案を作成してください。
# 目的
{例：契約更新の90日前までに、解約リスクの高い顧客を発見する}
# 対象顧客
- 契約形態：{月次契約／年次契約など}
- 主な利用者：{利用部門や役割}
- 契約規模の区分：{区分と定義}
- 導入段階：{オンボーディング中／定着期など}
# 予測・判定したい結果
- 主要な結果：{更新／解約／利用定着／アップセルなど}
- 判定時点：{例：更新日の90日前}
- 観測期間：{例：直近30日、直近90日}
# 利用できるデータ
{指標名、定義、更新頻度、欠損の有無を列挙する}
例：
- 週次アクティブユーザー率：契約ID数に対する週1回以上利用したID数、週次更新
- 主要機能利用率：対象機能を月1回以上使ったユーザーの割合、月次更新
- 問い合わせ件数：直近30日の件数、随時更新
- NPSまたは満足度：回答がある顧客のみ、四半期更新
- 定例会参加状況：実施、延期、連続欠席の3区分
- 契約更新日までの日数：日次更新
# 既知の業務知識
{更新や解約との関係が社内で確認されている事実。なければ「未確認」と書く}
# 制約
- 合計点は0〜100点とする
- Green、Yellow、Redの3段階に分類する
- 指標は最大{5〜8}個に絞る
- 相関が強そうな重複指標を二重加点しない
- データがないことと、状態が悪いことを区別する
- 根拠のない数値は「初期仮説」と明記する
- 個人情報や自由記述の感情推定は使わない
- 顧客規模や導入段階で基準を分ける必要があれば、その理由を示す
# 作業手順
1. 目的に直接関係する指標候補を選ぶ
2. 各指標について、採用理由、除外理由、重複リスクを説明する
3. 指標ごとの配点と判定基準を作る
4. 合計点の閾値と、単独でRedにする重大条件を分ける
5. 欠損値、データ遅延、新規顧客の扱いを決める
6. 各判定に対応するカスタマーサクセスの行動を定義する
7. 過去データを使った検証計画を作る
8. 最後に、確定できない点を質問として列挙する
# 出力形式
次の順番で出力してください。
## 1. 設計方針
目的、判定時点、スコアが支援する業務判断を短く説明する。
## 2. 指標設計表
列は「指標名」「意味」「観測期間」「配点」「加点・減点条件」「採用理由」「注意点」とする。
## 3. 総合判定
Green、Yellow、Redの点数範囲、重大条件、担当者の推奨アクションを示す。
## 4. 欠損・例外ルール
新規顧客、未回答、データ遅延、障害発生時の扱いを示す。
## 5. JSON計算定義
次のキーを含む有効なJSONのみをコードブロックで示す。
- score_name
- objective
- observation_window
- metrics
- critical_rules
- bands
- missing_data_policy
- version
metricsの各要素には、name、definition、weight、scoring_rule、data_sourceを含める。
## 6. 検証計画
過去データで確認する項目、見直し条件、更新頻度を示す。
## 7. 未確定事項
人が判断すべき点と、追加で必要なデータを質問形式で示す。
# 最終確認
- 配点合計が100点か計算する
- 同じ事象を複数指標で重複評価していないか確認する
- 各指標の定義が計算可能な粒度か確認する
- JSONが構文上有効か確認する
- 入力にない事実を断定していないか確認する
入力時に変える項目
最初に決めるべきなのは、何を予測するスコアなのかです。 「顧客の健康状態を知りたい」だけでは、採用すべき指標も観測期間も決まりません。
必ず変更する項目
{目的}：誰が、いつ、何を判断するためのスコアか{予測・判定したい結果}：更新、解約、定着など、一つの結果{判定時点}：更新90日前、導入30日後など{観測期間}：直近7日、30日、90日など{利用できるデータ}：実際に取得できるデータだけを記載{既知の業務知識}：社内で確認済みの事実と担当者の仮説を分ける
たとえば「契約更新の90日前に解約リスクを見つける」なら、更新後に確定する請求情報だけでは間に合いません。判定時点より前に取得でき、担当者が行動へ移せる指標を優先します。
固定した方がよい条件
運用中に基準が揺れないよう、次の条件はプロンプト内に残します。
- 合計点の範囲
- 指標数の上限
- 欠損と低評価を分けるルール
- 重大条件と合計点を分けるルール
- 初期仮説を明示するルール
- 出力順とJSONのキー
出力形式まで具体的に指定する理由は、AIの回答を比較しやすくするためです。OpenAIの公式ガイドも、明確な指示、十分な文脈、望ましい出力形式の指定を推奨しています（Prompt engineering best practices for ChatGPT）。
失敗しやすい指示と改善例
ヘルススコア設計で起きやすい失敗は、データを渡す前に「最適な重み」を求めてしまうことです。
NG例：いきなり配点を決めさせる
顧客のヘルススコアを作ってください。
ログイン回数、問い合わせ件数、NPSを使い、100点満点で重み付けしてください。
この指示では、何を予測するのか、いつ判定するのか、問い合わせが多い理由は何かが分かりません。AIが示す配点は、もっともらしい数字の組み合わせにとどまります。
問い合わせ件数も単純には評価できません。不具合による問い合わせ増加は危険信号になり得ますが、導入初期に積極的な利用者が質問している可能性もあります。
改善例：目的と検証条件を先に置く
年次契約の顧客について、更新日の90日前に解約リスクを発見する初期スコア案を作ってください。
利用できるデータは、週次アクティブユーザー率、主要機能利用率、問い合わせ分類、定例会参加状況、満足度です。
各指標について、次を示してください。
- 更新判断との関係についての仮説
- 観測期間
- 初期配点
- 欠損時の扱い
- 誤判定が起きる条件
- 過去12か月分の更新・解約結果で検証する方法
入力から判断できない数値は確定値にせず、「初期仮説」と表示してください。
改善点は明確です。
- 「顧客の健康」ではなく、更新前の解約リスクに目的を限定した
- 指標名だけでなく、誤判定の条件も求めた
- 配点を確定値ではなく検証対象にした
- 過去の更新・解約結果との照合を作業に含めた
出力を安定させる3つのコツ
一度の回答で完成を狙わず、設計、点検、検証の順に進めると扱いやすくなります。
1. 指標名ではなく計算定義を渡す
「利用率」だけでは、分母と分子が分かりません。次のように定義します。
主要機能利用率：
直近30日間に主要機能Aを1回以上使った有効ユーザー数 ÷ 契約中の有効ID数 × 100
データ更新：毎日
欠損条件：契約ID数が取得できない場合
これなら、AIは閾値案だけでなく、計算不能時の扱いまで検討できます。
2. 合計点と重大条件を分ける
平均化すると、緊急性の高い事象が他の加点に埋もれることがあります。そのため、通常の合計点とは別に重大条件を置きます。
例として検討できる条件は次の通りです。
- 契約終了の意思が記録された
- 主要な利用部門が一定期間利用していない
- セキュリティや重大障害に関する未解決案件がある
実際に何を重大条件とするかは、自社の契約プロセスと運用データで決めます。自由記述をAIに推測させるのではなく、CRMや問い合わせ管理で分類済みの項目を使う方が、判定理由を説明しやすくなります。
3. AIに自己点検させ、人が承認する
プロンプト末尾の確認項目は省かないでください。特に見るべき点は次の通りです。
- 配点合計が100点になっているか
- 利用頻度とアクティブ率など、似た指標を二重評価していないか
- データ欠損を0点としていないか
- 更新前に取得できない指標が混ざっていないか
- Red判定に対応する具体的な行動があるか
AIの初回出力を確認して指示を調整する反復も重要です。公式ガイドでは、最初の回答を確認し、文脈の追加や指示の調整を行う方法が推奨されています。
活用例：設計後のレビューにも使う
同じ入力データを使い、役割の異なる二つのプロンプトへ分けると、設計案の弱点を見つけやすくなります。
データ担当者として点検する
以下のヘルススコア案をデータ担当者としてレビューしてください。
確認項目：
- 各指標を現在のデータから計算できるか
- 観測期間と更新頻度が一致しているか
- 欠損率が高い指標に大きな重みがないか
- 未来の情報が混入していないか
- 同じ事象を重複評価していないか
問題ごとに「問題点」「起きる誤判定」「修正案」を出してください。
対象の設計案：
"""
{AIが作成したヘルススコア案}
"""
CSマネージャーとして点検する
以下のヘルススコア案をCSマネージャーとしてレビューしてください。
Green、Yellow、Redの各判定について、担当者が次の営業日から実行できる行動になっているか確認してください。
曖昧な行動は、担当者、期限、顧客への働きかけ、完了条件が分かる形に修正してください。
また、スコアだけでは判断できず、人による確認が必要な場面を列挙してください。
対象の設計案：
"""
{AIが作成したヘルススコア案}
"""
一つ目は計算可能性、二つ目は現場での実行可能性を点検します。両方を通過して初めて、スコアを試験運用へ進められます。
運用開始前のチェックリスト
最後に、次の項目を確認してください。
- [ ] 予測する結果が一つに絞られている
- [ ] 判定時点と観測期間が明記されている
- [ ] 各指標の計算式とデータソースが分かる
- [ ] 重みと閾値が初期仮説として管理されている
- [ ] 欠損、遅延、新規顧客の扱いが決まっている
- [ ] 重大条件が合計点とは別に定義されている
- [ ] 各判定に担当者の行動が紐づいている
- [ ] 過去データで更新・解約結果との関係を検証できる
- [ ] バージョンと変更日を記録できる
- [ ] 個人情報をAIへ不必要に入力していない
最初の分岐点は、AIが提案した重みが妥当かどうかではありません。過去データでRed判定が実際の解約・更新結果に先行していたか、さらに担当者が間に合う時点で検知できたかです。この二つを確認できなければ、指標を増やす前に目的、判定時点、観測期間を見直してください。