Gainsight の週次アカウントエクスポートを CSM がすぐ使えるダイジェストに変える再利用可能なプロンプトです。今週動いたアカウント、リスクバンドに入ったアカウント、そして月曜にどの 3 件に触れるべきかの優先順位付きリストを返します。CSM は CSV（またはプロンプトの 3 ブロック入力）を Claude に貼り付けると、movers・リスク・推奨アクションで整理されたダイジェストが返ってきます。各アクションはアカウント名・trigger・次のステップを明示します。構築する integration もなく、保守する n8n の workflow もありません。Claude.ai または Claude Code に貼り付けるプロンプトであり、apps/web/public/artifacts/customer-health-digest-prompt/ にある artifact バンドルにはプロンプトのテキストと、プロンプトが期待する列マニフェストが含まれます。
これは composite health score を n8n で という workflow のエントリーレベル版です。あちらは夜間スケジュールで防御可能なスコアを構築して書き戻しますが、こちらは既にあるスコアを読んで月曜朝の ToDo リストに変えます。まずここから始めてください。数字そのものを信頼できなくなったときに n8n の flow へ卒業します。
いつ使うか
あなた（または運営する CS ポッド）が既に Gainsight に概ね信頼している health score を持っていて、ギャップがスコアではなく「週が始まる前に誰もそれを読まない」ことである場合に使います。これが直す最も一般的な失敗パターンは次のとおりです。40-80 アカウントを持つ CSM が月曜に Gainsight を開き、色付きの pill の壁を見て、動いたアカウントではなく最後にメールしてきたアカウントから優先順位を付けてしまう。ダイジェストは「ダッシュボードを眺めて祈る」を、優先順位付きの 3 アカウントのリストと、各アカウントがそこにある理由に置き換えます。
おおよそ 30-120 アカウントの CSM book に適合します。30 未満では各アカウントを自分で読めるのでダイジェストの節約は小さくなります。~150 を超えると CSM ごとのエクスポートが十分長くなり、手動貼り付けよりも n8n の flow のバッチ処理とアラートが欲しくなります。チーム全体で一貫したダイジェスト形式を望み、月曜の CS スタンドアップをどの book でも同じ artifact から回したい CS Ops リードにも適合します。
いつ使わないか
health score そのものとして使わないでください。プロンプトはスコアを要約しますが、計算はしません。Gainsight のスコアが信頼されていない場合（CSM が既にそれを無視して生の使用状況を引いている場合）、誰も信じていない数字のダイジェストは、ノイズをより速く浮かび上がらせる手段にすぎません。まずスコアを直し（それが n8n workflow の仕事です）、それからダイジェストにしてください。
週次の delta 列がないエクスポートに向けないでください。ダイジェスト全体は動き、つまり「先週から何が変わったか」に依存するので、エクスポートには現在のスコアと前期間のスコア（または事前計算された delta）の両方が必要です。delta がないとプロンプトは絶対スコアでランク付けし、80 から 55 に落ちたアカウント（まだ「黄」だが急落中）を、1 年間安定して赤だったアカウントの下に埋めてしまいます。バンドルの列マニフェストはまさにこの理由で delta 列を必須として挙げています。
顧客へ何かを送るために使わないでください。出力は社内向けの CSM ダイジェストです。リスクを率直に名指しします（「ACME の使用状況が週次で 41% 減、単一ユーザー依存」など）が、これはアカウントの前には決して出さない言葉です。月曜準備の artifact であり、顧客コミュニケーションのドラフトではありません。
1 回の貼り付けで ~150 アカウント行を超えて与えないでください。それを超えるとモデルはリストの中間を圧縮し始め、ランク付けが劣化します。大きな book は 2 回の貼り付けに分けるか、バッチ処理の n8n flow に移ってください。
セットアップ
おおよそ 20-30 分で、そのほとんどは Gainsight のエクスポート列を一度マニフェストに一致させることに費やされます。
- エクスポートを構築する。 Gainsight で Company オブジェクトに対し、次の列を持つレポートを作成（または再利用）します。アカウント名、アカウント ID、現在の health score、前週の health score（または delta を直接）、ARR、renewal 日、CSM owner、そして持っていれば 2-3 個の sub-score（使用状況、sentiment、アクティビティ）。CSV にエクスポートします。バンドルの
column-manifest.mdには、プロンプトが読む正確な列名と、どれが必須でどれが任意かが挙げられています。 - プロンプトを配置する。
apps/web/public/artifacts/customer-health-digest-prompt/prompt.mdのプロンプト本文を Claude.ai の Project（または Claude Code セッション）にコピーします。役割・入力形式・タスク・避けるべきこと・出力形式の 5 部構成です。言い換えないでください。避けるべきことのセクションこそが、データが裏付けない churn の理由をモデルが作り出すのを止めます。 - データを貼り付ける。 プロンプトの下に CSV を貼り付けます。列名がマニフェストと異なる場合は、レポートで改名するか、貼り付けの先頭に 1 行のマッピングメモを追加します（「
Score_Prevを前週スコアとして扱う」）。プロンプトはマッピングメモは許容しますが、delta の欠落は許容しません。 - しきい値を一度設定する。 プロンプトのタスクブロックには 3 つの調整可能な数値があります。バンドのカットオフ（デフォルトは緑が 75 以上、黄が 50 以上、赤が 50 未満。安全に貼り付けられるよう、意図的に「50 未満」と書き、決して小なり記号のグリフは使いません）、「mover」と数える delta（デフォルト 5 ポイント）、推奨アクションリストに載せるアカウント数（デフォルト 3）です。初回使用前にこれらをチームのキャリブレーションに編集し、その後は週次ダイジェストが比較可能になるよう安定させてください。
- 週次で実行する。 同じプロンプト、新しいエクスポートを毎週月曜（または翌週分は金曜）に。プロンプトは構造が決定論的なので、2 人の CSM が自分の book で実行しても同じダイジェスト形状を生み、これがスタンドアップを標準化する CS Ops リードにとっての要点です。
プロンプトが実際に行うこと
プロンプトは 4 つのことを順に行い、その順序が設計です。まず現在のスコアからあなたのカットオフを使って各アカウントをバンドに分類し、ダイジェストは集計の 1 行（「緑 12、黄 9、赤 4」）で始まります。次に movers を計算します。週次の delta が mover のしきい値を超えるアカウントを、絶対 delta でソートし、最大の swing が上下どちらでも先に表れます。上向きの movers を名指すことは下向きと同じくらい重要です。20 ポイント跳ねたアカウントは expansion のシグナルであり、単なる非問題ではありません。
3 番目に、バンドの越境を生の movers とは別に印付けます。黄から赤へ越えることは、緑の中で 5 ポイント落ちることとは別のイベントだからです。バンドの越境は play を発火させる線であり、バンド内の揺らぎは通常そうではありません。両者を別セクションに保つことで、CSM が 5 ポイントの下落のたびに緊急事態として扱うのを防ぎます。
4 番目（これがレポートではなく ToDo リストにする部分です）に、優先順位付きの推奨アクションリストを生成します。各エントリはアカウント、最大の寄与シグナル 1 つ（sub-score があればそこから引く。例「使用状況 41% 減」「38 日間 CSM の接触なし」）、そして具体的な次のステップ（「チェックインを設定」「22 日後の renewal で AE を巻き込む」）を名指します。ランク付けはまず赤へのバンド越境、次に大きな下向きの movers、次に renewal の近さで重み付けします。避けるべきことのブロックは、列が示さない原因をモデルが作り出すことを禁じます。composite だけが動き、どの sub-score も説明しない場合、エントリは作り話の理由ではなく「composite が 11 減、データ内に単一のドライバーなし —手動でアカウントを引く」と読めます。
出力形式は固定です。集計行、Movers のテーブル、バンド越境のテーブル、そしてあなたの N に上限を付けた番号付きの推奨アクションリスト。その固定形状こそが、CS Ops リードが今週のダイジェストを先週と差分比較でき、月曜のスタンドアップが再整形なしにそこから回ることを可能にします。
コストの実態
60-100 アカウントの典型的な book は、おおよそ 3,000-6,000 入力トークン（CSV）と ~600 トークンのプロンプトの 1 回の貼り付けで、返ってくるダイジェストは 400-900 出力トークンです。現在の価格の Claude Sonnet では 1 回あたり 1 セントを大きく下回り、CSM ごとに週 $0.02-0.04、10 人の CSM チームで年に数ドルといったところです。インフラコストはありません。n8n のエグゼキューターも、ローテーションする認証情報も、保守する warehouse ビューもありません。唯一の経常コストは CSM がエクスポートを引いて貼り付けるのに使う 2 分で、これは置き換えるダッシュボード凝視の 15-30 分よりはるかに少ないです。
n8n の flow に対する正直なトレードオフ。このプロンプトは何も書き戻せず、無人のスケジュールでは実行できず、Slack にアラートできません。人間が介在する貼り付けです。これはこの規模では feature であり（CSM が各ダイジェストを読む）、~150 アカウントを超えるとボトルネックです（貼り付けが扱いにくくなる）。卒業のコストは ~2 時間の n8n セットアップ、留まるコストは週 2 分の貼り付けです。
成功の姿
最初の 1 か月で 3 つの数字を見てください。第 1 に ダイジェストからアクションまでの遅延。推奨アクションリスト内のアカウントのうち、ダイジェストから 48 時間以内に記録された CSM の接触を得た割合。3 週目までに 70% 超を狙います。それ未満ならダイジェストは読まれて無視されており、通常はランク付けが CSM の直感と合わず、しきい値の調整が必要です。第 2 に バンド越境の捕捉率。四半期に churn または escalate したアカウントのうち、ダイジェストで少なくとも 30 日前に赤へのバンド越境に現れた数。これは先行指標のテストです。ダイジェストがそれらを早期に印付けなかったなら、問題はダイジェストではなく基礎となるスコアです。第 3 に スタンドアップ時間。CS Ops リードは、全員が同じダイジェスト形式で来るようになると月曜の CS スタンドアップが短くなるのを見るはずです。そうでなければ、ダイジェストは実際には会議を駆動するために使われていません。
代替案との比較
Gainsight のダッシュボードを直接読むこととの比較。 ダッシュボードは現在の状態を示しますが、ランク付けせず、動きを前面に出さず、ToDo リストを生成しません。規律ある CSM は delta 列でソートして下に読むことでダイジェストを手動で再現でき、30 アカウントの book では、それは Claude に貼り付けるより本当に速いです。プロンプトは、手動のソートして読むが 20 分かかり水曜までに劣化する 60 件以上で本領を発揮します。
Gainsight 自身の CTA と Cockpit との比較。 Gainsight はスコアがしきい値を越えると Call To Action を発火でき、これはここのバンド越境セクションと重なります。CTA は、誰かがダイジェストを読むかどうかに関係なく workflow を発火させなければならないイベント（top-20 アカウントの赤への越境）に使ってください。このダイジェストは、CTA が与えてくれない週次のトリアージ、つまり book 全体での「まずこの 3 件に触れる」という優先順位付けの判断に使ってください。両者は補完的です。CTA はハードな割り込み、ダイジェストは週次の読み物です。
composite health score の n8n flow との比較。 あの flow は、スコアそのものを作り直す必要があるとき、夜間の write-back と Slack アラートが欲しいとき、または手動貼り付けがスケールしないほど book が大きいときに正しいツールです。このプロンプトは、スコアが問題なくギャップが純粋に「月曜の計画に変える」ことであるときに正しいツールです。ほとんどのチームはこのプロンプトから始め、スコアが要約されるだけでなく変わる必要があるという証拠を得てから初めて flow を構築すべきです。
注意点
- delta 列がなければダイジェストは無用。 週次の delta がないとプロンプトは movers を計算できず、静かに絶対スコアでのランク付けに後退し、慢性的な赤を浮かべて新たに落ちたものを埋めてしまいます。ガード：バンドルの
column-manifest.mdは delta（または前週スコア）を必須として印付け、プロンプトの入力形式ブロックはモデルに、絶対スコアのランク付けへ劣化させるのではなく「delta 列が欠落 —movers を計算できない」と止まるよう指示します。 - 作り出された churn の原因。 スコアの下落を説明するよう求められると、モデルは列が裏付けないもっともらしく聞こえる理由を喜んで捏造します。ガード：避けるべきことのブロックは、名指しされた sub-score に追跡できない因果の主張を一切禁じ、composite だけが動いたときには「データ内に単一のドライバーなし —手動でアカウントを引く」という文字どおりの出力を強制します。捏造された原因に基づいて動く CSM は、見に行くよう言われた CSM より悪いです。
- 古いエクスポートを最新として読む。 CSM が誤って先週の CSV を貼り付け、既に解消した動きに基づいて行動する。ガード：プロンプトは貼り付けの先頭に「as-of 日」の行を要求し、それをダイジェストのヘッダーに反映するので、古いエクスポートは盲目的に行動されるのではなく一目で見えます。
- 長すぎる貼り付けが中間を圧縮する。 ~150 行を超えるとモデルはリスト中間のアカウントを圧縮し、ランク付けが静かに劣化します。ガード：入力形式ブロックは行数に上限を設け、切り詰めたリストを静かに要約するのではなく、拒否して分割を求めるようモデルに指示します。
- 週をまたぐしきい値のドリフト。 CSM が実行の間にバンドのカットオフや mover のしきい値を編集すると、今週のダイジェストは先週と比較不能になり、「何が動いたか」のフレーミングが壊れます。ガード：しきい値は貼り付けたデータではなくプロンプトのタスクブロックに存在し、まさに実行をまたいで固定されるようにしています。列マニフェストは、しきい値はセットアップ時に一度設定し、プロンプトとともにバージョン管理すべきだと記しています。
スタック
- Claude —エクスポートを読み、movers とバンド越境をランク付けし、推奨アクションリストを書く（Sonnet で十分。タスクは構造化された要約であり、深い推論ではない）
- Gainsight —週次アカウントエクスポートのソース（現在のスコア、前週スコアまたは delta、ARR、renewal 日、sub-score）
- 任意の CSV ソース —プロンプトは Gainsight ではなく列を読む。マニフェストを Catalyst、Vitally、ChurnZero のエクスポートに向け直せば同じように動く