顧客ヘルススコアリング

顧客アカウントスコアリングの概要と方法論フレームワーク。顧客のジャーニーと ROI 達成に対する理解を深めます。

ビジョン

顧客ヘルススコアは、GitLab アカウントチームがライフサイクルジャーニーを通じた GitLab 採用と顧客エンゲージメントの相対的なヘルスを理解するのに役立ちます。顧客の製品採用、リスク、GitLab とのエンゲージメントを理解することで、拡大と維持の取り組みを支援します。

方向性

アカウントヘルススコアリングのエピックで当初概説したように、ヘルススコアリングの目的はチームが顧客の GitLab 採用をより良く理解できるようにすることです。

成功基準

  • 95% 以上の顧客がヘルススコアを持つ（FY24 年次目標に合わせて）
  • 顧客ヘルススコアリングフレームワークがバックテストされ、有効で有益であることが検証された
  • 顧客ヘルスが CSM、Sales、Product、および広範な組織によって、顧客の GitLab 製品採用レベルと GitLab 企業とのエンゲージメントを評価するための会社レベルのレポートメトリクスとして使用されている

![Early Warning Segmentation Framework](https://lucid.app/publicSegments/view/1d7cb4c0-392c-41d8-afeb-569fa48440dd/image.png)

スコアリング方法論

製品使用統計は 3 つの異なるスコアに影響します。それぞれ異なる目的を持ち、異なるオーディエンス向けであり、異なるメトリクスを使用します。

名前目的オーディエンスメトリクス備考
顧客ヘルススコアチームが顧客の相対的なヘルスを理解し、リスクを特定し、更新の可能性を管理し、拡大の機会とその理由を特定できるようにするGitLab 内部チームアカウントヘルスは顧客の多角的なビューを提供する主要メトリクスの集約。詳細は Account Health Predictor を参照
バリューストリーム管理この顧客向けダッシュボードは DORA4 を含むバリューストリームアナリティクスメトリクスをホストGitLab 顧客DORA4 メトリクス、月次使用メトリクス
プラットフォーム採用スコア各顧客は、利用中のユースケースのレベルと顧客が GitLab アプリケーションから現在受け取っている価値を理解するための単一のプラットフォーム採用スコアを持つGitLab 内部チームユースケースごとに 3〜7 の製品使用メトリクス、Red/Yellow/Green スコアリングを使用。メトリクスはユースケースのスコアに集約され、ユースケーススコアがプラットフォーム採用スコアに集約されるPlatform Adoption Scoring
ユースケース採用スコアカード各顧客はユースケース（SCM、CI、CD…）ごとにスコアカードを持ち、採用進捗をハイライトして勝利を祝い、改善の余地を特定するGitLab 内部チームと顧客ユースケースごとに 3〜7 の製品使用メトリクス、Red/Yellow/Green スコアリングを使用。これらを使用してユースケースごとの採用レベルをハイライトするデッキを作成するUse Case Adoption Scoring
DevOps スコア顧客がパフォーマンス上位のインスタンスと比較した自社の DevOps ステータスを理解するため（セルフマネージドのみ）GitLab 顧客10 のユースケースにわたる 10 のメトリクス、過去 1 ヶ月に機能を利用したユーザーの%として表示、パフォーマンス上位インスタンスがその機能をどのように利用したかと比較（セルフマネージドのみ - GitLab 機能）ハンドブックリンク
DevOps 採用DevOps 採用は組織内のグループが GitLab の最も重要な機能を採用・使用する方法を示すGitLab 顧客SaaS ではグループとプロジェクトレベル、セルフマネージドではインスタンスレベルで設定が必要な Dev、Sec、Ops にわたる顧客の全体的な採用を示す特定のメトリクス（GitLab 機能）ドキュメントリンク
DevOps レポートこれは DevOps 採用と統合されており、最終的に顧客エグゼクティブダッシュボードに置き換えられるGitLab 顧客Dev、Sec、Ops の機能利用（ドキュメント）

アカウントヘルス

アカウントヘルスは、以下を特定する洞察を提供する主要メトリクスの集約です:

  • 拡大の機会 — 収益関連、製品ユースケース、異なるチーム内
  • リスク — 製品採用の弱点、コミュニケーション不足、または顧客成果の未達を特定
  • 採用ジャーニー — より良いパフォーマンスのために GitLab を活用するベストプラクティスについて顧客をコーチできる領域を特定
  • EBR とディスカッショントピック — 使用状況レポートなどの EBR や顧客ケーデンスの注力領域をハイライト

たとえば、顧客はすべてのサブスクリプションライセンスをデプロイしていても積極的に使用していない場合や、使用していてもすべてのサポートチケットが非常にネガティブな場合があります。

一つのレンズだけで見ることは限られたビューを提供します。より幸せな例として、顧客がほとんどのライセンスをデプロイし、現在のティアの高度な機能を多く使用し、ポジティブなビジネス成果（PBO）を達成している場合があります。この場合、メトリクスは拡大の機会を示します。顧客と私たち自身に価値を**証明（PROVE）**する必要があります:

P.R.O.V.E.

  • Product（製品）: ライセンス有効化 + ユーザーエンゲージメント + ユースケース: 50% ウェイト
  • Risk（リスク）: CSM センチメント + 機会の更新リスク: 25%
  • Outcomes（成果）: サクセスプラン + Verified Outcomes: 10%
  • Voice of the customer（顧客の声）（VoC）: サポート + アンケート: 5%
  • Engagement（エンゲージメント）: 顧客エンゲージメント + エグゼクティブスポンサーシップ + イベント + 認定: 10%

Customer Health Vision

顧客ヘルスのカテゴリーとリスク

ヘルスは主に、顧客への価値と成果の提供を評価することで GitLab へのビジネスインパクトを考慮します。以下のガイドラインは、CSM（Customer Success Manager）が顧客アカウントの適切なヘルス評価を選択するためのガイダンスを提供します。以下は評価するカテゴリーと各カテゴリーに関連するリスクです。

製品採用と利用

ライセンス使用状況、機能・ユースケース、製品バージョン（例: 最新バージョンを採用していない — セルフマネージドのみ）、および/または GitLab ステージによって測定される遅延、低い、または大幅に減少した使用状況（使用量の低下）があります。顧客への価値と成果の提供が顧客によって定義された期待を下回っています。これは、顧客が GitLab のベストプラクティスを活用してソリューションの価値を最大化していない方法（プロセス、運用、ポリシーなど）でも影響を受ける可能性があります。

製品体験

顧客が必要な機能強化やバグ修正を要求しているが、まだ提供されていません。リスクはリクエストの重要性、Issue の深刻度、および/または機能強化やバグ修正の数によって決まります。機能リリースへの期待の外れも製品体験に影響する可能性があります。

顧客エンゲージメント

顧客の連絡先が応答しない、ミーティングを欠席する、および/または EBR などのケーデンスコールや他のエンゲージメントに参加することを拒否する。これは間接的に、顧客がソリューションに価値を見出していない、またはソリューションの優先度が下がったことを意味する可能性があります。

エグゼクティブスポンサーやチャンピオン

スポンサーやチャンピオンが会社を去る、組織の別の部門に移動する、および/または影響力の範囲が縮小する。

顧客センチメント

顧客が GitLab との経験（セールス、プロフェッショナルサービス、サポート、製品など）について、直接の会話、アンケート（例: NPS）、ソーシャルメディア、または他のコミュニケーションチャネルを通じて懸念や不満を表明した。

競合の脅威

更新プロセスの前後に競合他社が関与していることが判明し、顧客が代替手段を検討した結果としてダウングレードやチャーンが発生する可能性があります。

その他の組織的要因

顧客のビジネスパフォーマンスが大幅に影響を受け、低下している。会社が買収される、別の会社と合併する、分割される、または顧客ビジネスの他の構造的変化。

ヘルス評価ガイドライン

CSM がどのように、いつ顧客のヘルスを追跡するか（アカウントをいつ Yellow、Red、または Will Churn に設定するかを含む）については、顧客ヘルス評価と管理の詳細を参照してください。

以下の項目は、CSM が顧客のヘルスを評価・記録するためのガイドラインとして機能し、顧客がライフサイクルジャーニーのどこにいるかを考慮する必要があります。アカウントヘルスはオープンな更新機会に影響します。

Gainsight がメジャースコアを Red、Yellow、または Green として計算する方法の理解:

Gainsight スコアリングフレームワーク:

  • Green: 75〜100 ポイント
  • Yellow: 50〜74 ポイント
  • Red: 0〜49 ポイント

Gainsight のメジャーグループスコアと総合スコアの計算

計算式: ((スコア * ウェイト) + (スコア * ウェイト)… / (最大潜在スコア * ウェイト)

スコアを表示するには、色付きの円にカーソルを合わせてください。 ウェイトはメトリクスの右上に表示されます。

ヘルスのレポートと表示

Customer Health（CSM Portfolio Dashboard）レポートを使用して、すべての顧客のすべてのメジャーのヘルスを一つのビューで確認します。

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

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

Gainsight

Gainsight スコアカード属性と計算

ヘルススコアの基準は、手動または自動的に適用されて全体的なメジャーを決定します。個々のメジャーが欠落している場合、ウェイトは完成したメジャーに再配分されます。

  • CSM センチメントを除いて、エンゲージメントなどの不十分な統計や不正確な結果により、すべてのヘルスメジャーは通常、顧客のオンボーディング最初の 30 日間は NULL になります。
  • メジャーが N/A の場合、パーセンテージのウェイトは他のヘルスメジャーに再配分されます。
    • 例 1: すべての製品使用統計が欠落している場合、他のメジャー（エンゲージメント、ROI、CSM センチメントなど）に完全に再配分されます。CSM センチメントなどのウェイトが重いメジャーは、すでに最大であるため、より多くの配分を受けます。
    • 例 2: 製品使用統計を受け取っているが、Continuous Delivery（CD）が NULL の場合、製品使用統計のメジャーの中で再配分されます。そのため、CI ヘルスは例えば 5% から 7% に増加します。
グループ（PROVE）メジャー説明方法計算メジャーウェイトグループウェイトセグメンテーション
Product運用メトリクスが利用可能な場合、採用の深さと広さに基づいて顧客をスコアリングする自動顧客ユースケース採用を参照50%
ライセンス利用率30%All
ユーザーエンゲージメント10%All
SCM 採用15%All
CI 採用15%All
DevSecOps 採用15%All
CD 採用15%All
RiskCSM センチメントCSM が顧客の認識されたセンチメントを示すために更新する定性的メジャー手動/自動すべての CSM 所有アカウントについて、CSM が手動で red/yellow/green を決定する100%25%Tech Touch には N/A
OutcomesROI顧客は目標とメモを持つサクセスプランを持っているか？自動すべての CSM Prioritization = 1 アカウントおよびオープンなサクセスプランを持つすべての CSM 所有アカウントについて:
- Green: 1 つ以上の目標があり戦略/ハイライト情報がないアクティブなサクセスプラン
- Yellow: ドラフトのサクセスプラン OR 1 つ以上の目標があり戦略/ハイライト情報がないアクティブなサクセスプラン
- Red: サクセスプランなしまたは目標なし		100%10%Scale と Tech Touch には N/A
Voice of the customer5%
サポート Issueサポートインタラクションのヘルスを評価する。現在のバージョンは MVC で v2 が予定されている。自動- Green: 月 1〜5 チケット
- Yellow: 月 5〜15 チケット
- Red: 月 15 件以上のチケット		100%All
サポート緊急チケットオープン/クローズチケットの数に基づく。
優先度: 緊急チケット		自動- Yellow: 過去 7 日間に 1 件以上のクローズされた緊急チケット
- Red: 1 件以上のオープンな緊急チケット		0%All
Engagement10%
ミーティングケーデンス顧客との最後の通話またはミーティングの最近性に基づく自動CSM Prioritization = 1 アカウントについて:
- Green: <= 35 日

- Yellow: > 35 日かつ <= 60 日

- Red: > 60 日


CSM Prioritization = 2 アカウントについて:
- Green: <= 65 日

- Yellow: > 65 日かつ <= 90 日

- Red: > 90 日		50%Scale と Tech Touch には N/A
ペルソナエンゲージメントアカウント内の正しいペルソナと会議しているか？自動ペルソナエンゲージメントは、タイムラインエントリに追加された外部出席者の役割に基づく
- Green: Dev Lead と Security Lead の両方が過去 3 ヶ月のタイムラインエントリで外部出席者としてリストされている
- Yellow: 2 つのペルソナのうち 1 つが参加

- Red: どちらのペルソナもミーティングに参加したとしてリストされていない		50%Growth、Scale、Tech Touch には N/A

CSM センチメント

CSM は全体的なアカウントヘルスを決定する際に CSM センチメントを更新します。ガイドラインは以下の通りです:

  • CSM センチメント: CSM が顧客の認識されたセンチメントを示すために更新する定性的メジャー。これは上記で言及されたすべての要素を考慮し、ヘルス評価（green、yellow、red）の基準によって測定される必要があります
  • 全体ヘルススコアの CSM センチメントオーバーライド: CSM センチメントスコアが red になると、全体スコアは自動的に red になります。CSM センチメントが green または yellow スコアに戻ると、メジャーとグループの標準的なウェイト付けが通常通り再適用されます。

CSM センチメントスコアは、タイムラインアクティビティを記録するごびに CSM センチメントドロップダウンから値を選択することで更新されます。アクティビティをタイムラインに記録すると、Gainsight は CSM センチメントスコアカードメジャーの値を更新し、タイムラインアクティビティのメモをスコアカードに表示します。スコアカード値を設定するルールは 2 時間ごとに実行されます。

顧客ヘルス評価を更新し、その評価に影響するアクティビティをログに記録する方法については、いくつかのイネーブルメント動画を視聴できます。

古くなったヘルスメジャーのクリア

製品 Gainsight への使用データの受信が停止すると、ヘルスメジャーは 60 日後に “NA” に移行します。これは古いデータに基づく分析とアクションを防ぐためです。この場合、古いデータよりも何も表示しない（“NA”）ことを優先します。

CSM センチメント CSM センチメントヘルススコアは、更新されてから 90 日後に古くなります。これはヘルススコアダッシュボードでスコアの横に感嘆符として反映されます。アカウントが古くなっているとマークされているが、90 日以内に CSM センチメント を更新した場合は、gainsight-users に連絡してください。古くなった CSM センチメント を持つアカウントは、Gainsight の CSM バーンダウンダッシュボードでも監視され、アカウント計画ミーティングで議論されます。センチメントスコアは、古い値を削除するために 120 日以上更新されていない場合は NA に設定されます。

サポートメジャー サポートメジャーは 30 日以上更新されていない場合、古くなったと見なされます。30 日間更新がない場合、自動的に NA に設定されます。

複数の本番インスタンスのヘルススコアリング

アカウントに複数の GitLab インスタンスが本番として識別されている場合（セルフマネージドインスタンスタイプの更新の手順）、製品使用ヘルスはプライマリインスタンスではなく最後に更新されたインスタンスを測定し、スコアリングの不一致が生じます。注: アカウントの大多数は単一の本番インスタンスを持つため、これは 5% 未満の頻度です。

解決策

Gainsight でインスタンスデータを更新して製品使用ヘルスメジャーに 1 つのインスタンスのみを含める動画の手順。

  1. アカウントの C360 でインスタンスと Namespace の詳細セクションにスクロールする
  2. 右にスクロールして「Included in Health Measure」列を確認する
  3. インスタンスを除外するには、3 つのドット、「Edit」をクリックし、Included in Health Measures で「Opt-Out」を選択してインスタンスを除外する。注: null ではなく「Opt-Out」を選択していることを確認してください。システムが更新を上書きする可能性があります。次に「Update」をクリック
  4. ヘルススコアリングのプライマリインスタンスを選択するには、3 つのドット、Edit をクリックし、「Included in health Score」をクリックして「Update」をクリック

重要な注意事項:

  • ベストプラクティスは Included in Health Measure としてマークされたインスタンスを1 つのみにすること
  • すべての本番インスタンスは、Opt-Out としてマークされない限り自動的に Included in Health Measure としてマークされる
  • null ではなく Opt-Out を選択すること、さもなければシステムが更新を上書きする可能性がある
複数の本番インスタンス: Gainsight 管理プロセス

DevSecOps ヘルスメジャーはアカウントを Ultimate として参照するため、複数のサブスクリプションが存在する場合に正しい本番インスタンスがスコアリングされることを確認するためにこのステップが追加されました。

CSM が Premium サブスクリプション下の本番インスタンスをマークした場合、DevSecOps ヘルスは NA と表示されます。つまり、Premium と Ultimate の 2 つのサブスクリプションがある場合でも、CSM が Premium のものをヘルススコアリング用にマークした限り、アカウントに DevSecOps ヘルススコア（一般的に red）が表示されなくなります。

Gainsight ルール:

  • NEW: Admin: Update Plan Name on Product Usage Instance Metrics
    • 顧客サブスクリプションオブジェクトから製品使用インスタンスメトリクスオブジェクトへ Plan Name をプッシュする
  • Set Score: DevSecOps Adoption Individual Measures
    • このルールは Company オブジェクトの Products Purchased ではなく、Product Usage Instance Metrics オブジェクトの Plan Name を参照する

セグメンテーション

セグメンテーションは主にサービスレベル（CSM Priority 1、2、3）に従い、次に以下に示す他の要因によります。

  1. CSM 管理 vs. 非 CSM 管理
  2. セグメンテーション: エンタープライズ、ミッドマーケット、SMB
  3. 地理的
  4. 部門別（WW またはパブリックセクター）

ヘルススコアのコメンタリーと用途

アカウントヘルススコアは、顧客にとって重要なものを測定し、顧客がアクセスして利用できる機能を測定するという目標のもと、グループごとおよび個々のメジャーごとに異なるウェイト付けで多くの要因を含んでいます。

注: ヘルスメジャーの統計が欠落している場合、値ではなく（つまり red ではなく）NULL としてカウントされます。

ティアベースの製品使用統計

顧客の現在のティアと機能アクセスに基づいて顧客の使用状況を評価します。

たとえば、顧客が Premium を利用している場合、採用レベルを理解するためにプレミアムレベルの機能に基づいてヘルスを評価します。ヘルスが red または yellow の場合、リスクを意味します。green の場合、拡大またはフラット更新を意味する可能性があります。

先行指標と遅行指標

いくつかのメトリクスは先行指標または遅行指標です。予測ソリューションを重視しますが、過去のパフォーマンスを評価するために遅行メトリクスも組み込まれています。

以下のグラフ（Early Warning Segmentation Framework）は、使用する戦略とどのリソースを活用するかのフレームワークを提供するために使用されます。顧客はアカウントヘルスと成長ポテンシャルによってグループ化されます。Renewal Operations アナリストは、時間をどこに費やすかを特定するためにフィールドのトリアージをサポートします。

方法論

ヘルススコアリング

出発点

最初のアプローチは「ブラックボックス」アプローチを作成するための複数のメトリクスの計算でした。これはエンドユーザー（CSM、SA、セールス担当者）には役立たず、計算を理解するのが簡単ではなく、Gainsight のロジックが不十分で、ユースケースのどの側面が優れていてどの側面が改善が必要かを知るためのアクション指向でもありませんでした。

PROVE コンポーネント

カテゴリーヘルスメジャー例なぜ？メトリクスアカウントタイプ成熟度
Productライセンス有効化顧客がすべてのライセンスを割り当てた顧客はライセンスをデプロイしたか？これはシート削減/拡大の指標ライセンス利用率All100%
Productユーザーエンゲージメント73% のユーザーが月次アクティブユーザーユーザーはログインして製品を使用しているか？ユニーク月次アクティブユーザー / billable_user_countAll100%；進行中
Product採用（ユースケース）ユースケース採用顧客はユースケースを採用して GitLab の「よりスティッキーな」領域に進んでいるか？SCM —> CI —> DevSecOps 採用All100%
RiskCSM センチメント該当する場合は CSM が決定したセンチメントCSM はケーデンスコールから何を決定したか？CSM センチメントCSM 所有100%
OutcomesROI サクセスプランROI サクセスプランが顧客と合致していることを確認する欠落または不十分に構築されたサクセスプランは、GitLab と顧客の望む成果との間の整合性の欠如をハイライトする提供された Green サクセスプラン EBRCSM 所有100%
Outcomesポジティブなビジネス成果（PBO）完了したサクセスプランの目標失敗または未達の PBO は苦境の兆候となる可能性があり；成功した PBO は更新の拡大をハイライトできる毎年少なくとも 1 つの PBO を正常に完了することCSM 所有未開始
VoCサポート - エスカレーション緊急サポートチケット緊急サポートチケットは不幸や不満を示す可能性がある過去 90 日間に緊急サポートチケットがあるかどうかを測定するAll100%
VoCサポート - エンゲージメント顧客がチケットを送信する顧客がサポートとエンゲージしているかを判断する既存の方法論を維持しつつ、より多くのチケットを良いこととして許容するように調整するAll70%
VoCサポート - CSAT顧客が CSAT アンケートに記入しフィードバックを提供する顧客はフィードバックを提供しているか、スコアは何か（回答率 + 成果）green ヘルスに対する最低 XX% の回答率をベンチマークし、CSAT 結果を CSM に提供するAll未開始
VoCNPS アンケート顧客が回答し高スコアを提供するアンケートは製品と会社に対する顧客の認識の良い指標であるためアンケート回答率 + アンケートスコアAll未開始
EngagementエンゲージメントCSM ケーデンスコールの最近性顧客エンゲージメントの欠如最後の CSM ケーデンスコールの日付CSM 所有100%
Engagementエグゼクティブスポンサーシップステークホルダーは整合されてコミュニケーションしているか？整合性とコミュニケーションの欠如は、エグゼクティブと ROI の間の断絶を示す可能性がある整合されたステークホルダーコミュニケーションの最近性CSM 所有未開始
Engagementイベント顧客は GitLab イベントに参加しているか？イベント参加は顧客エンゲージメント、チームメンバーとの対話、対面でのやり取りを示すTBDAll未開始
Engagement認定アカウント内のユーザーは認定を取得しているか？認定を維持しているか？GitLab 認定を取得することは私たちと顧客の両方にとってポジティブです；また GitLab への関与、GitLab の使用に関する知識を示し、社内チャンピオンとしての推論を提供しますTBCAll未開始

予測分析

予測分析は万能薬ではありません。すべての問題を解決するわけではありません。代わりに、この方法論は確率論的であり、「ヘルシー」な顧客（拡大と更新）の典型的なジャーニーと「アンヘルシー」な顧客（ダウングレードとチャーン）を相関させるためにヘルスメジャーを組み込みます。たとえば、健全なセールスパイプラインはプッシュ（クローズ日の移動）が少なく、ステージを段階的に進みます（停滞しない）。逆に、複数のプッシュがあり長期間ステージに停滞している機会はリスクの指標です。

予測タイプモデル名ステータス説明
拡大Propensity To Expand（PTE）アクティブアカウントが拡大（ARR の増加）する可能性があるかを予測する
チャーンと縮小Propensity To Churn or Contract（PTC）アクティブアカウントがチャーンまたは縮小（ARR の減少）する可能性があるかを予測する

拡大する意欲と能力（シート、アップティア）

異なるイベントにはトリガーが使用されます:

  • ライセンス利用率の低さによるダウングレードを防ぐための行動促進
  • 高い CI 使用率はビジネス成果を達成しており、次のステージについて話す準備ができていることを示す、または
  • 顧客は成長がほとんどないが成功しており、フラット更新を目指すべき。

これらのメトリクスはそれぞれ、顧客が次のマイルストーンに近づいているか達成したかをアカウントチームが把握するためのガイダンスとして使用されます。以下に示す項目は、生産的な顧客との会話のために洞察を引き出すためにアカウントチームが見ることのできる例です。

シート拡大

ライセンス利用率

  1. ライセンスを急速に消費している（成長率を測定）
  2. 90% のライセンス利用率

ユーザーアクティビティ

  1. 高い UMAU（80% 以上）

アップティア

  • ゲストユーザーへの要望
    • 高数のプレミアムライセンスを購入したが、多くをゲストに移動できる
  • Ultimate につながる Free/Premium 機能を消費している
    • DevSecOps
    • Agile Planning
  • サクセスプランの目標が Ultimate レベルの機能セットに整合している
    • DevSecOps
    • Agile Planning

シート削減

  • 75% 未満のライセンス利用率（オンボーディング中の顧客を除く）
  • 有効化されたユーザー数の継続的な減少（月次で無効化されたユーザー数）
  • CSM 更新リスク == シート損失

ダウンティア

  • Ultimate レベルの機能を使用していない
    • DevSecOps
    • Agile Planning
  • サクセスプランの目標が Ultimate レベルの機能セットに整合していない
  • CSM 更新リスク == ダウンティア

チャーン

シート削減またはダウンティアからの指標に加えて:

顧客体験

  • 顧客がコミュニケーションを取らなくなった
  • 社内チャンピオン/ステークホルダーの喪失
  • CSM 更新リスク == チャーン

更新機会

  • ステージが進行していない
  • プッシュ
  • 機会の顧客アクティビティの欠如

参考資料

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