Content last updated 2026-05-08

カスタマーサクセスプラン

カスタマーサクセスプランは、GitLab 採用を通じて価値を実現するための、顧客向けかつ相互合意のロードマップです。これは GitLab ソリューションアーキテクチャと顧客の協働の成果であり、顧客が成功することを確実にすることを主目的としています。このプロセスは、製品スコープの会話（特定の機能・機能群に焦点を当て、DevSecOps の特定のステージのサブセットに限定された議論）から、ソリューション（特定のペインポイントの解決）または戦略（トップレベルの戦略イニシアチブに紐づく、組織横断のプロセス革新と変革を通じてビジネス成果を形作る）スコープへのシフトを支援するように設計されています。このサクセスプランは販売前プロセスから始まり、販売後のサクセスプランへと引き継がれることを意図しています。場合によっては、販売後のサクセスプランに明確な GitLab オーナーがいないことがあります。これがあるからといって、必要な場合にソリューションアーキテクトがサクセスプランを作成し、顧客レビューを行うことを妨げてはなりません。カスタマーサクセスプランは動的であることが意図されており、合意された頻度で定期的にレビューされるべきです。

相互カスタマーサクセスプランとは

相互カスタマーサクセスプランテンプレート は、Pre Sales Customer Success Plan と Post Sales CSM Customer Success Plan テンプレートを統合したものです。以下の内容を含みます。

顧客背景
- 顧客のビジネス成果
- 主要なビジネスステークホルダー
- 現状と望ましい状態 / ワークフロー
- 計画済みまたは完了済みの技術アクティビティ
- 技術評価プランリスト
顧客フェーズ別サクセスプラン & 採用ジャーニー
提案されたイニシアチブとマイルストーン

すべての Strategic および Enterprise の商談には、相互カスタマーサクセスプランテンプレート を使用してください。

すべての High Velocity または Commercial の商談には、コマーシャルカスタマーサクセスプランテンプレート を使用してください。

なぜ相互カスタマーサクセスプラン（CSP）を使うのか

主要な目的

相互カスタマーサクセスプランの目的は以下です。

顧客にとって: GitLab のフェーズ別の採用成功について、アーキテクチャの推奨、デプロイ、移行、統合、ユーザーやアプリケーションの大規模なオンボーディング、自動化プロセスの推奨、ダッシュボードとモニタリングについて、規範的なガイドを提供します。SA として、相互サクセスプランを作成するために常に顧客と協働し、AI を活用した DevSecOps 統合プラットフォームとして GitLab を採用することが、技術やデプロイの観点だけでなく、人とプロセスの観点からも何を伴うのかを、予備的に理解してもらうよう支援すべきです。
カスタマーサクセスマネージャー（CSM） にとって: 適切な閾値（現在は 100k Net ARR）を超えるすべての商談について、販売前から販売後への移行時に CSM と協働します。CSM が関係を引き継ぐ際に、すべての関連するコンテキストを CSM に提供することが重要です。SA として、CSM が顧客の目的、次の30 日、60 日、90 日、そして次の6 か月のマイルストーンを理解できるよう協働します。CSM はその後、頻度とイネーブルメント計画を策定できます。CSM は、販売後に相互カスタマーサクセスプランを更新・維持する責任を負います。これは顧客向けのドキュメントとなり、顧客がイニシアチブと目的を達成するのを促進します。CSM が割り当てられていない場合でも、CSP は作成され、顧客とレビューされるべきです。
プロフェッショナルサービスチーム にとって: ステートメントオブワークを決定するために使用できる、イニシアチブのスコープとともにカスタマーサクセスプランを提示します。
Go To Market チーム にとって: GitLab エグゼクティブスポンサーや GTM、カスタマーサポートの誰かが関与する必要がある場合、相互 CSP は顧客と GitLab のインタラクションの間にコンテキストを提供する真実の情報源として機能します。

相互カスタマーサクセスプランをいつ作成するか

相互カスタマーサクセスプランは、ステージ 2（スコーピング）の間に開始されるべきで、最初のバージョンはステージ 3（技術評価）に入る前に存在しているべきです。これは、SA が見込み顧客や顧客の目的に対して GitLab ソリューションを規範的に提示し始める時期で、顧客との協働においてフェーズ別の採用と顧客採用ジャーニーがどのようなものになるかを示します。

相互カスタマーサクセスプランは、ステージ 4より前のいずれかの時点で顧客とレビューされ、受け入れられる必要があります。

相互カスタマーサクセスプランを作成・レビューする商談の閾値？

ステージ 2（技術評価）以降にあり、$100k net ARR 以上のすべてのファーストオーダーまたは成長商談。（SA が DRI で、CSM に引き継がれます）
SA が SA Validated Tech Evaluation に関与しているすべての商談。これは、ソリューションアーキテクトが真のテクニカルウィンに向けて取り組んでいることを意味します。

SA マネージャーには、追加の商談を含めるかどうかの裁量があります。さらに、SA ディレクターは、SA が顧客のために CSP を作成することが不可能または不合理である特定のケースで例外を提供できます。

上記の基準を使用してカスタマーサクセスプランが必要であると特定された商談については、ソリューションアーキテクトはステージ 3技術評価の終わりにこれを開始し、URL を Sales Force の商談のカスタマーサクセスプランフィールドに配置すべきです。

その後、SA は SFDC の商談レベルのカスタマーサクセスプランセクションの関連フィールドがプロセス全体を通じて維持されていることを確認します。

CSP 例外プロセス

SA が顧客のために CSP を作成することが不合理または不可能な場合、SA ディレクターはその商談を CSP 例外が必要であるとマークできます。これにより、顧客エンゲージメントモデルを反復するためのフィードバック駆動のアプローチが提供され、特定の商談の実現可能性に関する対話が促進され、SA 組織の管理下にある SA 顧客サクセスプランニングへの KPI ベースのアプローチが提供されます。

CSP を作成することが不合理である可能性のある理由:

SA が顧客とエンゲージできず、何度も顧客に試みた。
必要性と利点を説明した後、顧客が CSP に取り組むことに興味がない。
セールスリーダーシップ（VP+）が、商談の動態に基づいて CSP を行わないことを支持している。

SA と SA リーダーシップは、例外としてマークする前に、CSP に取り組む方法を見つけるためにセールスチームと協力すべきです

商談に CSP 例外をマークするには、以下のカスタマーサクセスプラン作成とレビューの追跡のガイダンスに従ってください。

カスタマーサクセスプラン作成とレビューの追跡

可視性、説明責任、コラボレーションを促進するため、CSP と関連する顧客レビューは Salesforce の関連商談に記録される必要があります。以下のフィールドを使用してください。

Customer Success Plan: プランへの URL のフィールド。CSM Exception がチェックされている場合、このフィールドには例外の根拠が含まれます（CSM 例外の根拠専用フィールドが実装されるまでの一時的な方法としてこのフィールドを使用）。
CSM Exception: SA Director 以上は、SA が顧客のために CSP を作成することが不可能または不合理な場合にこれをチェックできます。
Customer Accepted: CSP が顧客とレビューされた場合にチェックします。これをチェックするために、顧客が CSP を正式に「受諾」する必要はありません。

高レベルではカスタマーサクセスプランプロセスとは何か

カスタマーサクセスプランプロセスはこちらに記載されています。

カスタマーサクセスプラン URL を適切な形で Sales Force の商談に更新する SA の責任に注意してください。

カスタマーサクセスプランの構築方法

SA の1 日の生活をもう少し詳しく説明しましょう。顧客と行うすべての会議は、顧客の課題と望ましい成果を理解する機会です。以下は、商談を会議ごと、ステージごとに進める方法と、最初にカスタマーサクセスプランを構築するために収集すべき情報の推奨事項です。

カスタマーサクセスプランドラフト（ステージ 1: ディスカバリーからステージ 3: 技術検証）
- 会議1 - ディスカバリー - 望ましい課題成果を発見する [なぜ変えるのか？]
  - 会議中
    - 「1. 会社背景」 を調査・確認する
    - 「3. 主要ステークホルダー」 が誰かを理解する:
      1. エグゼクティブな意思決定者 / エコノミックバイヤー、
      2. テクニカルチャンピオン / コーチ / バイヤー、
      3. プロセスまたは運用オーナー、そして紹介を受ける
    - 「4. ビジネス成果 / 戦略的イニシアチブ」 について尋ねる
    - 各ステージのツールチェーン / プロセスなどに関するディスカバリーを開始する
    - GitLab の価値について非常にハイレベルなホワイトボードまたはプレゼンテーションを行う
  - 会議後
    - 最初の会議から以下の内容でカスタマーサクセスプランを作成する
      - 「1. 会社背景」
      - 「2. これまでに聞いたこと」
      - 「3. 主要ステークホルダー」
      - 「4. ビジネス成果 / 戦略的イニシアチブ」
    - 非常に重要: Sales Force の商談のカスタマーサクセスプラン URL を更新する。
    - 顧客の技術的な質問への回答に時間の大半が費やされて上記の情報がない場合は、情報を集めるために別のディスカバリー会議をスケジュールする。
  - 次のステップ:
    - 現状と望ましいワークフローのディスカッション
    - さらにディスカバリーを促進するための短い5 分間のデモ「ドライブバイ」デモも可能です
- 会議2 - スコープ - 望ましい成果を達成するためのワークフローのスコープを定める [なぜ今なのか？]
  - 会議中
    - これまでの 「2. これまでに聞いたこと」 を提示する
    - 「5. 現状と提案されたワークフロー図」 の基礎を形成する各ステージのツールチェーン / プロセスなどに関するディスカバリーを継続する
    - すべての望ましいユースケースが達成されない場合、すべての 「6. アプリケーション & ユースケース / リスク & 緩和策」 について尋ねる
    - GitLab のユースケースと価値をプレゼンテーションまたはホワイトボードで示す
  - 会議後
    - カスタマーサクセスプランを以下で更新する
      - 「2. これまでに聞いたこと」
      - 「5. 現状と提案されたワークフロー図」
      - 「6. アプリケーション & ユースケース / リスク & 緩和策」
      - テクニカルウィンと意思決定を達成するために行うことについて、「8. 技術評価プラン & アクティビティ」 を開始する。
  - 次のステップ:
    - 現状と望ましいワークフロー図を提示する
    - オプション（ワークショップやデモを提案）。
- 会議3 - スコープ - 価値を資格付けする [なぜ GitLab なのか？]
  - 会議準備
    - 会議準備のために、アカウントエグゼクティブと協力して、これまでの 「2. これまでに聞いたこと」 を補強する。
    - 「8. 技術評価プラン & アクティビティ」 の作成を開始する。これは、テクニカルウィンと意思決定を達成するために正確に何が行われるかである。
  - 会議中
    - 3 回目の会議中に、これまでの 「2. これまでに聞いたこと」 を更新して提示する
    - 「5. 現状と提案されたワークフロー図」 を提示し、フィードバックとディスカッションを求める。
    - 「6. アプリケーション & ユースケース / リスク & 緩和策」 を提示し、フィードバックとディスカッションを求める。
    - 顧客が、顧客の成果とプロセスに対応する私たちの価値を理解していることを確認する。
    - 技術的意思決定がどのように行われるかを判断し、「8. 技術評価プラン & アクティビティ」 に文書化する。技術的意思決定への道について顧客から合意を得る。
  - 次のステップ:
    - SA と AE がビジネスおよび技術検証のための次のステップを提案する: ワークショップ / デモ / POV / バリューストリームワークショップ / ビジネス価値評価
- 会議4 - ビジネス & 技術検証アクティビティ - ビジネスと技術の価値を検証する
  - 会議準備
    - 会議準備のために、アカウントエグゼクティブと協力して、テクニカルウィンと意思決定を達成するために行われる 「カスタマーサクセスプランアクティビティ」 をレビューする。
  - 技術評価中
    - GitLab と顧客の間で決定された技術評価プランとアクティビティを実施する。例: ワークショップ、POV、デモ、リバースデモ、Day in the Life
    - テクニカルウィンに向けて取り組む（複数の会議が必要な場合があります）
  - テクニカルウィン中・後
    - 「計画済み / 完了済みアクティビティ」 を更新する
    - テクニカルウィンの後、「価値成果マップ / メトリクス」 を作成する。
    - 成果マップは、達成すべき顧客の成果を、その戦略的イニシアチブとともに、GitLab の機能とそれがもたらす価値にマッピングしてトレースします。これは提案で使用されます。
  - 次のステップ:
    - テクニカルウィンを確保した後、AE と提案について協働する
    - カスタマーサクセスプランを開始する（以下を参照）
相互カスタマーサクセスプラン（ステージ 3: 完了）
- 技術検証が完了したら、相互カスタマーサクセスプランを更新する
  - 「会社背景」
  - 「これまでに聞いたこと」
  - 「主要ステークホルダー」
  - 「ビジネス成果 / 戦略的イニシアチブ」
  - 「現状と提案されたワークフロー図」
  - 「アプリケーション & ユースケース / リスク & 緩和策」
  - 「計画済み / 完了済みアクティビティ」
  - 「価値成果マップ / メトリクス」
会議5 - 提案 - （ステージ 4: 提案以降） - 顧客の成果を達成するための提案と推奨事項
- 以下を含む提案 / チャンピオンデッキについて AE と準備する
  - 「これまでに聞いたこと」
  - 「ビジネス成果 / 戦略的イニシアチブ」
  - 「現状と提案されたワークフロー図」
  - 「価値成果マップ / メトリクス」
- 提案プレゼンテーションの後、引き続き相互カスタマーサクセスプランを更新・完成させる
- 非常に重要: Sales Force の商談のカスタマーサクセスプラン URL が更新されていることを確認する。
- 次のステップ:
  - 交渉が進行する間、SA として、顧客と CSM との会議をセットアップして、以下を相互カスタマーサクセスプランに追加する:
    - 「ユーザー / 購入された / 推奨されたもの」
    - 「フェーズ別サクセスプランと採用ジャーニー」
    - 「成果、目的 & アクティビティ - ビジネス / 技術マイルストーン（3/6/12 か月）」
    - 「アーキテクチャノート: プロデューサー（デプロイ、設定、統合）; コンシューマー（オンボーディング、管理、モニタリング）」
100k 超の場合の CSM への相互カスタマーサクセスプランハンドオフ / または AE と SA がクローズ後に維持
- CSM は SA が開始したサクセスプランを引き継ぎ、以下を追加または更新します:
  - 「成果、目的 & アクティビティ - ビジネス / 技術マイルストーン（3/6/12 か月）」
  - 「イネーブルメントプラン」
- ARR 基準が 100k 超の更新商談についても、CSM は 「13. 成果、目的 & アクティビティ - ビジネス / 技術マイルストーン（3/6/12 か月）」 から相互 CSP を開始することがあります。
- これらのケースでは、CSM が Sales Force の更新商談のカスタマーサクセスプラン URL を更新する 責任者です。
- SA はオプションとして、事後にカスタマーサクセスプランを作成し、なぜ以前に GitLab が購入されたのか、GitLab に対する顧客の価値期待は何かを理解するために、残りのすべてのコンテキストを追加することがあります。
- さらに CSM は、顧客との定期会議を実施する際に、相互カスタマーサクセスプランに以下を記録することが期待されます:

	コンテンツ要素	相互サクセスプラン	キックオフコール / オンボーディング EBR
1.	機能 / 能力ごとの利用率	定期会議で利用率を更新	X
2.	本番環境でのユースケース採用	定期会議でユースケース採用を更新	X
3.	サポートチケット / 強化 / Issue	定期会議でチケット / Issue を更新	X
4.	ステータス付きの進行中 / 計画イニシアチブ	定期会議でマイルストーンを更新	X
5.	成果 / メトリクス更新	定期会議でメトリクス / 顧客を更新	X
6.	PS SOW と Runbook	添付	X

CSM とカスタマーサクセスプラン

カスタマーサクセスプランに対する CSM の責任について詳しく学ぶにはこちらをクリック。

リソース

この Google Drive フォルダには、相互カスタマーサクセスプランの開始テンプレート、手順説明のウォークスルー、Ultimate と Dedicated の参考用カスタマーサクセスプランの例が含まれています。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)

ページのソースコードを見る - ページの編集 - please contribute.