4つの生の入力ストリーム（製品の利用状況、リレーションシップのエンゲージメント、サポート負荷、サーベイのセンチメント）を、アカウントごとの単一の加重ヘルススコア、緑/黄/赤の tier、そして CSM チームが上から順に処理する優先順位付きの remediation キューに変換する Claude Skill です。要点はスコアそのものではありません。ほとんどの CSP はすでにスコアを提供しています。要点は、この Skill がすべての重み・しきい値・tier の区切りを、あなたが編集する config ファイルの中で明示的にすること、そして各アカウントのスコアを、最も大きい負の driver とその実際の値を名指しする1文で説明することです。キューを開いた CSM は、誰も信頼しない色付きのピルではなく、「Acme — 48、赤 — サポート負荷: 30日で 11 件の P1 チケット、baseline は 2 件」を目にします。artifact バンドルには SKILL.md に加えて3つのリファレンスファイル、すなわち記入式の scoring config スキーマ、tier とアクションの playbook テンプレート、そして作り込まれたサンプル output が含まれます。
artifact バンドルは apps/web/public/artifacts/cs-health-score-builder-skill/ にあります。最初の実行の前に SKILL.md を読み、references/ の3ファイルすべてを適応させてください。
いつ使うか
あなたは QBR で擁護できるヘルススコアモデルを必要とする CSM または CS Ops のリードであり、現在のスコア（Vitally、Planhat のデフォルトであれ、スプレッドシートであれ）はチームが信頼するのをやめたブラックボックスです。この Skill は設計と反復のフェーズ向けです。アカウントのバッチについて4つの入力ストリームを渡すと、明示的な config に対してスコアを計算し、キューとアカウントごとの説明を返します。あなたは説明を読み、重みが現実と一致するか判断し、config を編集して再実行します。すでに理解しているアカウントに対して3〜4回反復すれば、すべての区切りを正当化できるモデルが手に入ります。
最も効果を発揮するのは、スコアリングするアカウントが少なくとも 50 件あり（それより小さい book は CSM が手で読めます）、CSV か CSP の API として取得できるクリーンな利用シグナルがあり、理想的には重みを backtest するための12か月分のラベル付き churn 履歴がある場合です。remediation キューが最も役立つのは、チームがそれを上から順に処理すると約束したときです。スコアが信頼を得るのは、上位の赤いアカウントが実際に churn するアカウントである場合のみです。
使わない方がよいとき
この Skill を Vitally や Planhat に配線した夜間のライブ scoring エンジンとして使わないでください。これはモデル設計ツールであり、本番インフラではありません。信頼できる config ができたら、重みとしきい値を CSP のネイティブ scorecard か、schedule で動く n8n フローに移植してください。Skill の仕事は config を正しくすることであり、永遠に動き続けることではありません。
利用テレメトリが信頼できない場合は使わないでください。一貫性なくタグ付けされたイベントの上に構築されたスコアは、行動の変化ではなくタグ付けの変化を反映した低下を浮かび上がらせ、説明文は自信を持って誤った driver を名指しします。まずデータを直してください。
churn の定義もラベル付き履歴もない場合は使わないでください。backtest なしでは重みを推測しているだけであり、推測したモデルはモデルがないより悪いです。数字としての権威を帯びるからです。backtest の入力をスキップすると、Skill はキューのヘッダーに UNBACKTESTED 警告を返しますが、あなたが推測を出荷するのを止めることはできません。
約50件未満のアカウント、売上の forecasting、または個々のユーザーの scoring（これはアカウントを採点し、シートは採点しません）には使わないでください。
セットアップ
初回はおおよそ 45〜90 分で、そのほぼすべては、何かを配線するのではなく、データに合わせて scoring config を埋めることに費やされます。
- Skill をインストールする。
apps/web/public/artifacts/cs-health-score-builder-skill/のバンドルを~/.claude/skills/cs-health-score/に配置します。認証情報は不要です。Skill はあなたが提供するファイルを読むだけで、Vitally や Planhat を直接呼び出しません。あなたがデータをエクスポートし、Skill がそれをスコアリングします。 - scoring config を埋める。
references/1-scoring-config.mdを開き、アカウントセグメントごとに、4つの入力の重み（合計が 1.0 でなければなりません）、利用の baseline ウィンドウ、緑/黄/赤の区切りを設定します。テンプレートには初期値が入っています。Enterprise はエンゲージメントを 0.35、利用を 0.30 と重み付けします。リレーションシップの健全性が renewal を左右するからです。PLG は利用を 0.55 と重み付けします。製品が deal そのものだからです。これらはあなた自身の backtest に対して編集するための出発点であり、推奨値ではありません。 - アクション playbook を適応させる。
references/2-tier-playbook.mdを開き、placeholder の plays をチームの実際の motion に置き換えます。アカウントがサポート負荷で赤になったときと利用で赤になったときに CSM が行うことは異なる motion であり、キューが役立つのは各赤い行が1つを指している場合のみです。 - データを提供する。 アカウントごとにエクスポートします。利用 CSV（account_id、直近28日のイベント数、baseline のイベント数、ユニークなアクティブユーザー数）、エンゲージメント CSV（最後の意味あるタッチからの日数、直近90日の会議数）、サポート CSV（オープンな P1 数、前期間比のチケット数、解決までの中央値時間）、そしてセンチメント入力（最新の NPS/CSAT/CES スコア、または Skill が分類するための最近のサーベイ verbatim）です。任意で、backtest 用のラベル付き churn CSV を提供します。
- 実行する。 config の path とデータディレクトリを指定して Skill を呼び出します。キューファイル（最悪を先頭に優先順位付けされたアカウントと、スコア、tier、1文の driver）と、セグメントごとのキャリブレーションレポートを書き出します。説明を読み、
1-scoring-config.mdを編集し、再実行します。知っているアカウントについて赤いアカウントが自分の直感と一致するまで繰り返します。
Skill が実際に行うこと
Skill は4つのステージで動きます。ステージ1 — 正規化。 4つの入力ストリームそれぞれが、config に対して 0〜100 のサブスコアにマッピングされます。利用は、現在の28日イベントとアカウント自身の baseline との比であり、0（比 ≤ 0.5）から 100（比 ≥ 1.0）まで線形で、ユニークなアクティブユーザーが3を下回ると 40 でハードキャップされます。単一ユーザーへの依存は、生のイベント量では見えない churn リスクだからです。エンゲージメントは、最後のタッチの recency に21日の半減期の減衰を適用します。サポートはチケット負荷を反転させ（オープンな P1 が多いほど低いスコア）、グローバル平均ではなくアカウント自身の前期間の baseline に対して正規化します。10チケットのアカウントと 200 チケットのアカウントでは normal が異なるからです。センチメントは最新のサーベイスコアをマッピングするか、数字の代わりに verbatim を渡した場合は、Claude が厳格なルーブリックでテキストを分類し、確信度が 0.4 未満のときは推測せず中立の 50 を返します。
ステージ2 — composite。 4つのサブスコアが config のセグメントごとの重みを使って結合されます。tier は config の区切りで割り当てられます（デフォルトで緑 ≥ 75、黄 ≥ 50、赤は 50 未満）。生の入力をブレンドするのではなく、重み付けの前にサブスコアを計算することが、説明文が単一の driver を名指しできる理由です。Skill はアカウントの composite から最も下に離れたサブスコアを選び、その実際の数字とともに報告します。
ステージ3 — 説明とキュー化。 アカウントは remediation キューに最悪を先頭に並べられます。各行には1文の driver（「今四半期に4回の会議があったにもかかわらず利用が baseline を22%下回っている」）が、サブスコアの入力のみから生成されます。プロンプトは与えられた数字を超えた推測を禁じているため、文がデータの裏付けのない原因を捏造することはできません。Claude が空を返した場合は決定的な数値フォールバックが動くので、キューが止まることはありません。
ステージ4 — backtest（任意）。 ラベル付き churn 履歴を提供した場合、Skill は churn 日付の90日前の時点で履歴アカウントをスコアリングし、何件が赤に着地したかを報告します。重みが本物か希望的観測かを教える lead-time と recall の数字です。
コストの実態
高価な呼び出しはセンチメント分類であり、数値の NPS/CSAT の代わりに verbatim を渡したときだけです。サーベイテキストの分類は Claude Sonnet でアカウントごとに入力およそ 600 トークン、出力 80 トークン、アカウントごとの driver 文は入力約 300、出力約 40 を追加します。verbatim センチメントの 200 アカウントのバッチでは、現在の Sonnet 価格でフル実行あたり $1.50 未満です。代わりに数値のセンチメントスコアを渡せば、Claude への呼び出しは driver 文だけになり、同じバッチで 40 セント未満です。200 アカウントを超える実行は2〜4分で完了します。Skill はレート制限内に収めるためアカウントを 25 件のバッチで処理します。
実際のコストはトークンではなく、反復にかける時間です。キューがチームの読みと一致するまで、config 編集を2〜3ラウンド（1週間にわたり合計2〜3時間と見積もる）見込んでください。これは代替案より安価です。200 アカウントの book を CSM が手作業でトリアージすると1パスあたり1日かかり、毎週はできません。
成功とはどう見えるか
3つの数字を追跡します。第一に、キューの一致 — 上位 20 件の赤いアカウントについて、担当 CSM にランキングが彼らの読みと一致するか調査します。3回目の config 反復までに 70% を超える一致を目標にします。50% 未満なら、モデルではなく重みが間違っています。第二に、churn の lead time — backtest とライブ利用から、churn 通知の前にスコアが赤だった中央値日数です。30 日を超える中央値を目標にします。第三に、driver 文の精度 — 20 文をサンプリングし、実行可能・正確だが曖昧・誤りに分類します。80% を超える実行可能を目標にします。「誤り」の率が高い場合は、プロンプトではなく汚れた入力データを指しています。
代替案との比較
CSP のネイティブ scorecard（Vitally、Planhat、Gainsight、Catalyst、ChurnZero）との比較。 どの CSP もヘルススコアを備えており、本番ではそこで自分のスコアを動かすべきです。彼らがうまくやらないのは設計フェーズです。ネイティブ scorecard は、backtest ループも、数字がなぜ動いたかのアカウントごとの説明もなしに、目隠しで重みを設定させます。Skill は config を解決する作業台であり、CSP はそれをデプロイする場所です。両者は競合ではなく順次的です。Skill で設計し、その後重みを CSP の scorecard に書き写してください。
スプレッドシートモデルとの比較。 スプレッドシートはほとんどのチームが始める場所であり、計算には問題ありません。壊れるのは説明です。スプレッドシートは composite のセルを返しますが、CSM が行動できる文は返さず、スプレッドシートでの backtest は誰も保守しない churn 日付に対する手作業の VLOOKUP を意味します。Skill は説明と backtest を自動化します。モデルが安定していてチームがすでにスプレッドシートを信頼しているなら、切り替えないでください。Skill が真価を発揮するのは設計と反復の最中であり、その後ではありません。
専用の予測 churn 製品を購入することとの比較。 予測製品は、設計する必要のないモデルを約束します。トレードオフは、QBR でブラックボックスを擁護できないこと、そして説明できないモデルは CSM が回避するモデルだということです。まず明示的なバージョンを構築してください。それが頭打ちになり、ML を正当化する量があるなら、すでに理解している config の上に予測レイヤーを購入してください。
注意点
- 合計が 1.0 以外になる重み。 4つの重みの合計が 0.9 や 1.1 になる config は、すべてのスコアを静かに再スケールし、セグメント間の比較を無意味にします。ガード: Skill はロード時にセグメントごとの重みの合計を検証し、もっともらしく見える誤ったキューを生成する代わりに、違反するセグメントとその合計を出力してスコアリングを拒否します。
- 薄い verbatim でのセンチメントの幻覚。 Claude は制約がなければ、2語のサーベイコメントに対して自信を持ったセンチメント数値を生成します。ガード: 分類プロンプトは 15 語未満の入力や単一節の断片に対して確信度 0 を要求し、Skill は確信度 0.4 未満のものすべてを中立の 50 に折りたたむため、薄いセンチメントは捏造されたシグナルとしてではなく「不明」としてその重みを寄与します。
- driver 文が因果関係を捏造する。 加重 composite には最大の movers はありますが、原因はありません。ガード: 説明プロンプトには4つのサブスコアの値だけが与えられ、それ以外を参照することは禁じられています。実際の数字を引用しなければなりません。「利用が22%低下」を読む CSM はそれを検証できますが、「champion が去った」と推測した文は検証できず、決して生成されません。
- backtest なしのモデルを出荷する。 backtest の入力をスキップすると、権威ありげに見えてランダムかもしれないモデルができます。ガード: キューのヘッダーは、ラベル付き churn CSV が提供され backtest ステージが動くまで
UNBACKTESTEDバナーを掲げるため、キューを共有された誰もがモデルが未検証だとわかります。 - ドリフトするイベントに対して計算された baseline。 利用 baseline が、upstream で変わったイベント定義に対して実行ごとに再計算されると、すべてのアカウントが低下したように見えます。ガード: config は baseline を、Skill が再計算する値ではなく、あなたが一度計算して監査する凍結された入力カラムとして受け取るため、タグ付けの変化は艦隊全体の赤ではなく、データ品質のフラグとして現れます。
スタック
- Claude — センチメント分類（Sonnet、厳格な確信度フロアのルーブリック付き）とアカウントごとの1文の driver。scoring の計算そのものは決定的です
- Vitally — 利用、エンゲージメント、サポートのデータソース。完成したスコアの本番の住処
- Planhat — 代替の CSP ソースおよび本番ターゲット。Skill は CSP 非依存で、どちらからエクスポートした CSV も読みます
- scoring config ファイル — セグメントごとの4つの重み、baseline ウィンドウ、tier の区切り。反復を通じて編集されます。このファイルが実際の成果物です