顧客ヘルスの評価と管理

このページでは、顧客のヘルスを考慮するための要素、適切な評価の選択ガイドライン、コミュニケーションガイドライン、CSMの責任、アカウントトリアージのIssue作成手順について説明します。

CSM関連のハンドブックページについては、CSMハンドブックホームページを参照してください。

このページでは、顧客のヘルスを考慮するための要素、適切な評価の選択ガイドライン、コミュニケーションガイドライン、CSMの責任、アカウントトリアージのIssue作成手順について説明します。

GitLabにおける顧客ヘルススコアリングの定義と計算方法の概要については、顧客ヘルススコアリングを参照してください。

CSMの責任

CSMはアカウントのリスクに対処するための計画を策定するために、関連するすべての関係者と調整する責任があります。通常、アカウントチームとコミュニケーショングループ（コミュニケーションガイドライン）、および製品マネージャー、マーケティング、エグゼクティブ、エンジニアリングチームメンバーなどの関連するステークホルダーが含まれ、リスクに対処するための計画を策定・実行します。CSMはその後、戦略の実行を推進し、定期的な更新をログ記録する責任があります。リスクが解消されて顧客がヘルシーなグリーン状態になった場合、アカウントチームはアカウントをトリアージから外すことに同意できます。

顧客ヘルスの追跡

CSMは赤、黄、緑を使用して、顧客ヘルスに対するセンチメントを反映できます。以下は、顧客のヘルスの考え方についての説明です。

グリーン

ダウンセルやチャーンの既知または推定リスクなしに、顧客が更新および/または拡大する可能性が非常に高い状態。顧客のエクスペリエンス: エンゲージメント、採用、エクスペリエンスが期待どおりまたはそれ以上であり、顧客のジャーニーにおけるステージに適した価値と成果を提供しています。例:

  • サクセスプランで定義されたGitLabユースケースの段階的な採用（ジャーニーのステージを考慮）
  • 望む成果を推進できるステークホルダーとのアライメント
  • ミーティングにおける定期的なコミュニケーションとエンゲージメント
  • 製品とエクスペリエンスへの肯定的なフィードバック、および/またはNPSアンケートでの高スコア
  • チケット作成（月1〜5件）で定義されたサポートサービスの利用
  • 他のプログラムやイベント（Commitなど、諮問・エグゼクティブ顧客プログラム）を通じたGitLabとのフィードバック提供とエンゲージメントへの関心

イエローとイエロー「要トリアージ」

潜在的なリスク、または不確実性につながる重大な情報不足。克服すべき課題はあるが、チャーンやダウンセルのリスクは低い状態。顧客のエクスペリエンス: エンゲージメント、採用、および/またはエクスペリエンスが期待より低く、GitLabが顧客価値と成果を提供し、将来の収益成長を促進する能力が危ぶまれます。例:

  • 顧客のサクセスプランをサポートするGitLabユースケース採用の遅れ、遅延、またはブロック
  • 顧客の目標や成功基準の定義の欠如
  • サポートケース数が多い、重大/ブロッカーとなる製品Issue、または顧客の期待に基づく不良体験
  • ミーティングや/またはイベントへのエンゲージメント、応答性、参加の欠如
  • 役割や組織の変更または買収によるスポンサーまたはチャンピオンの喪失
  • リリースの採用の欠如（Self-Managedのみ）で、現在のリリースより1つ以上メジャーリリースが遅れている場合
  • テクニカルサポートサービスを利用していないか、大量のケースや/または高重大度ケースがある（月6〜15件、またはCSMによりサポートが最善の解決策であると指示された後もチケットを開かない）
  • サポート、Professional Services、またはGitLabの他の部門との不良エクスペリエンス
  • 会社の単一コンタクトとのみ連携している（シングルスレッド）

アカウントチーム内で、顧客がライフサイクルの現在のフェーズにおいてイエローとフラグが立てられている理由が十分に理解されている場合があります。CSMがCSMグループ外のチームメンバーからの是正措置とフォローアップが必要と判断した場合、CSMはリスクありタイムラインエントリを作成する必要があります。

レッド

アカウントの維持や今後のオポチュニティに対する具体的な既知のリスク、または更新に向けての無応答のような圧倒的な情報不足。顧客のエクスペリエンス: エンゲージメント、採用、および/またはエクスペリエンスが期待を大幅に下回り、顧客によって定義された期待どおりの価値、成果、または良好なエクスペリエンスを提供するGitLabの能力を阻害する問題があります。 例:

チャーン予定

非常にまれに、顧客がアカウントチームとリーダーシップが顧客の縮小またはチャーンを受け入れる段階に達することがあります。Gainsightが「グレー」カラー（または標準的なグリーンからレッドのヘルススコアリング以外のカラー）をサポートしていないため、will churn（チャーン予定）ライフサイクルステージは360ºの属性に適用できます。

顧客がwill churnステージに移行するには、以下を完了する必要があります。

  1. ヘルスレビュー中に話し合われたすべての選択肢が尽きた
  2. CSMがマネージャーと話し合い、will churnへの移行について合意を得た
  3. RM/AEがオポチュニティをWill ChurnまたはWill Contractとしてマーク
  4. CSMがGainsight C360 > Attributes > Lifecycle StageのライフサイクルステージをWill Churnに更新

顧客ヘルスの報告と表示

Customer Health（CSMポートフォリオダッシュボード）レポートを使用して、一つのビューですべての顧客のすべての指標のヘルスを確認します。

CSMセンチメントが更新されたタイムラインエントリを表示するには:

  1. グローバルタイムラインに移動
  2. Sentiment = Green、Yellow、またはRedでフィルタリング
  3. 他の特定のフィルター（CSM名、タイムライン日付など）を適用

Gainsightにおける責任

CSMはすべてのアカウントリスクに関してGainsightを最新の状態に保つ責任があります。

月次ヘルス更新

CSM/A担当の各アカウントについて、現在のアカウントヘルス状況に関わらず、毎月ヘルス更新を顧客のタイムラインに送信してください。これは、アカウントがレッドまたはイエローである場合のリスクありタイムラインエントリとは別のものです。以下の手順でアクセスできるテンプレートが作成されています。

  1. アカウントのタイムラインで Health Update アクティビティをログ記録します
  2. Apply Template を選択します
  3. Monthly Health Update をクリックして適用します
  4. アカウントのGainsightの状態を更新するため、正確な CSM Sentiment を必ず追加してください

以下は例を含むテンプレートのサンプルです。

現状

  • 使用状況: 顧客は現在2,300ユーザーのうち1,868ユーザーを利用中。残りのユーザーはオンボーディング、オフボーディング、ゲストユーザーのために循環しています。
  • センチメント: 顧客はエグゼクティブの賛同が高まる中、Ultimate\Duoの評価に向けて積極的に取り組んでいます。

考慮事項

  • 顧客は最近いくつかの組織を買収し、GitLabとパートナーの拡大に関する会話が遅れています。
  • 顧客の主要コンタクトが、会社のAIオプションを評価・推薦する内部AIボードに加わりました。このボードはエグゼクティブチームに直接報告しています。

ウォッチ項目

  • 更新会話が間もなく始まります。前回の複数年更新からいまだに緊張があります。
  • Duo POVに関する拡大された会話が進行中です。
  • 主要コンタクトが別の組織を引き継ぎ、翌月またはその後に始まるイネーブルメントを活用する予定です。

次のステップ

  • Duoワークショップ
  • エグゼクティブアライメントコール
  • Premiumの更新とDuo\Ultimateを含む更新のための見積もりオプションの作成

リスクありタイムラインエントリ

レッドまたはイエローのアカウントについては、リスクありタイムライン更新のための以下の手順が必要です。

  1. アカウントのタイムラインで、CSMセンチメントをRed（またはYellow）とした Health Update をログ記録します。また、Risk Reason と Risk Impact フィールドの値も選択してください。
  2. 顧客ヘルスの結論:
    1. 顧客を取り戻した場合:
      1. CSMセンチメントをGreenとした最終メモのアカウントレベルタイムライン Health Update タイプをログ記録します
      2. 顧客のライフサイクルステージをAdoptingに変更します
    2. 顧客を失った場合:
      1. 最終更新のアカウントレベルタイムライン Health Update タイプをログ記録します
      2. 顧客のライフサイクルステージを変更します: チャーン顧客にはWill Churn、ダウングレード顧客にはAdopting

これらは、アカウントレビュー中にアカウントチームと話し合うことができます。

顧客ヘルス更新フォーマット

ヘルス更新の説明は以下のフォーマットに従ってください。Gainsightでアクティビティをログ記録する際、ヘルス更新アクティビティの「Apply Template」ボタンをクリックすることでこのフォーマットを自動インポートできます。

  1. 今日リスクにさらされているのは何か? - 具体的なチャーンリスクと重要な指標・データポイントを1〜2文で説明します。
  2. リスクの緩和計画は何か? - リスクに対処するために取られている主要なアクションを1〜2文で概説します。
  3. 次のステップのオーナーは誰か? - [名前と役割]
  4. 次のステップのタイムラインは? - [具体的な日付 - MM/DD/YYYY]

以下はヘルス更新のサンプルです。

リスク: ライセンス利用率が35%に低下し、5部門のうち2部門のみがプラットフォームを積極的に使用中。主要チャンピオンが月末に離職することを表明。

緩和策: 新しいチャンピオンを特定するためのエグゼクティブアライメントコールを来週スケジュールし、利用されていない部門向けのターゲット研修を開始します。

オーナー: Jane Smith、CSM

次のステップのタイムライン: 06/15/2025

このフォーマットはいくつかの要件を満たすためのものです。

  • 状況とアクションの明確さを前面に（重要な詳細を先頭に）
  • 同期・表示される他のシステムで最も重要な情報が容易に確認できるようにする
  • 非同期プロセスを改善するための一貫性

リスク解消に向けたヘルス更新

顧客のリスクが緩和され、もはやリスク状態でなくなった場合、CSMはヘルス更新タイムラインエントリを作成して以下を伝えます。

  1. 顧客がもはやリスク状態でないこと
  2. リスクを緩和したことについての重要な詳細
  3. 次に何が来るか
  4. 現在のヘルス状態を反映するCSMセンチメントの更新

これはすべての人が最新の詳細を把握し、リスク解消をシステムとチーム全体で明確にコミュニケーションするためのものです。

以下はリスク解消のサンプルエントリです。

顧客Xはもはやリスク状態ではありません。サポートとProfessional Servicesとのエンゲージメントを通じてアップグレードとインフラの課題を解決し、GPTを使用してインフラをテストしながら現在の最新のGitLabバージョンに移行しました。合意されたサクセスプランに沿って、CI採用に取り組んでいます。

リスクありタイムラインエントリの頻度

  1. 顧客の更新が今会計四半期または次の会計四半期の場合:
    1. 毎週ヘルスタイムラインを更新します
      • エントリには、過去1週間のリスク緩和に向けた進捗と次の週の計画を含める必要があります。
  2. 顧客の更新が次の会計四半期より後の場合:
    1. 毎月ヘルスタイムラインを更新します
      • エントリには、過去1ヶ月のリスク緩和に向けた進捗と翌月の計画を含める必要があります。

GitLabリスクあり顧客プロセス

アカウントエスカレーションを開くタイミング

CSMがアカウントをレッドとマークし、製品、サポート、またはマネージャー以上からの追加支援が必要な場合、アカウントエスカレーションを開いてください。

リスクの影響の定義

  1. Customer Churn（顧客チャーン） - アカウントを完全にチャーンする
  2. Tier Downgrade（ティアダウングレード） - ティアを下げる
  3. Seat Churn（シートチャーン） - ライセンスシート数を削減する
  4. Customer Sentiment（顧客センチメント）（影響不明） - 顧客が不満であり、影響が定量化されていない
  5. Competitor（競合他社） - 競合インテリジェンス
  6. Stage Name（ステージ名） - ステージへの影響、例えば、製品の欠陥、方向性、またはニーズ。

リスク理由の定義

採用の欠如

顧客が製品や特定の機能を採用しなかったため、価値を得られなかった。組織のサイロや社内リソースの不足が原因の場合があります。価値を見出さなかった・体験しなかったために採用しなかった場合は、「製品価値/ギャップ」に該当します。

製品価値/ギャップ

見込み客または顧客が製品や機能を使用した（トライアル、POV、または購入済み製品）が、価値を見出せなかった。製品が顧客の要件を満たさなかった。また、期待される価値を体験しなかった見込み客の場合もあります。

製品品質/可用性

見込み客または顧客が製品や機能を使用した（トライアル、POV、または購入済み製品）が、見込み客や顧客のニーズや期待を満たさなかった。欠陥、パフォーマンスの低下、または稼働率/可用性の問題が含まれます。Self-managedとSaaS製品の両方が含まれます。

エンゲージメント/スポンサーの欠如

見込み客または顧客チームとのエンゲージメントを失った、またはそもそも得られなかった。チャンピオン/スポンサーが去ったか、責任が変わったか、または反応がなくなった。新しいスポンサーまたはチャンピオンとの再接続ができなかった。

予算の喪失

見込み客または顧客がビジネスの縮小、優先事項の変更、従業員の削減、またはその他の理由で予算を失った。競合による喪失ではない。

企業上の決定

経営上の決定またはポリシーにより、見込み客または顧客が製品ギャップや採用などではなく別の製品を選択した。これはトップダウンの決定（例: ELA、単一プロバイダーにコミットする決定）です。

  • その他 - 更新のブロッカーとなる他の会社上の問題

緩和戦略

リスク緩和に関するCSMのガイダンスについては、リスクタイプ、発見、および緩和戦略ページを参照してください。

リスクありコミュニケーションガイドライン

以下は、アカウントがイエローまたはレッドの場合に通知する相手に関するガイドラインです。それぞれの顧客ヘルス評価に応じて、以下の方々に通知してください。

イエローヘルス評価

  • アカウントチーム（つまり、アカウントエグゼクティブとソリューションアーキテクト）
  • 地域CSMマネージャー
  • CSMディレクター（Public Sector以外のすべての顧客）またはPublic SectorカスタマーサクセスのディレクターDirector of Customer Success Public Sector（Public Sector顧客向け）

レッドヘルス評価

  • 上記のリストに加えて…
  • エリアセールスマネージャーとリージョナルディレクター
  • カスタマーサクセス担当バイスプレジデント

関連プロセス

カスタマーサクセスエスカレーションプロセス

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License