カスタマーオンボーディング

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

カスタマーオンボーディングは、カスタマーライフサイクルの開始フェーズです。

概要

カスタマーオンボーディングフェーズは、顧客が GitLab との成功への旅を始めるうえで非常に重要です。これは、顧客が GitLab の利用開始から価値と成功を確実に享受できるようにするための機会です。

オンボーディングの手順

オンボーディングプロセスは、顧客のオポチュニティがステージ「5-Negotiating」に達した時点（予約 ARR）から開始する必要があります。これは、クローズに向けて高タッチなエンゲージメントが続いている間に CSM を紹介するためです。CSM アラインメントの対象となる新規顧客のオポチュニティがステージ 5 に達すると、CSM マネージャーが顧客を CSM に割り当てるための Gainsight CTA が作成されます。割り当てられた CSM は、残りのアカウントチームとともにオンボーディングプロセスを開始する必要があります。

⚠️ 注意: 目標完了タイムラインについては、タイム・トゥ・バリューの指標をご確認ください。

内部引き継ぎ

最初のステップは、プリセールスからポストセールスへの引き継ぎを完了することです。これにより、アカウントチーム全体が顧客の状況を把握し、CSM を顧客に適切に紹介できるようになります。アカウントの背景情報を共有するこの同期は 不可欠 であり、CSM が顧客とコール中になる前に必ず実施する必要があります。CSM がすべての背景を把握したうえで、アカウントチームが一枚岩として顧客の目標を理解し、その達成に向けて取り組む体制を整えるためです。

顧客が Dedicated を利用する場合、CSM は Dedicated 顧客向け CSM のベストプラクティスを確認する必要があります。

CSM 紹介メールとオンボーディング

Digital Programs が、CSM の役割を説明する GitLab CS プログラムへのイントロダクションを自動化し、続いて PubSec を除く CSM 割り当て顧客全員向けのオンボーディング有効化メールを送信します。これは、オンボーディングプレイブックが作成された際に顧客へトリガーされます。すべてのメールは汎用の Customer Enablement GitLab メールアドレスから送信され、各メールには CSM 名がトークンとして埋め込まれています。顧客はメールに直接返信することができ、その返信は CSM に転送されてコールのスケジュール設定や質問の対応が行われます。また、各 CSM は自分の顧客に送信されるすべてのメールに CC されます。

  • メール 1: GitLab CS エクスペリエンスのご紹介（CSM の役割について）
  • メール 2: オンボーディングメール - ご挨拶、最初のステップ、サポートの利用方法
  • メール 3: オンボーディングメール - セキュリティ、バックアップと復元
  • メール 4: オンボーディングメール - GitLab の監視、API とレート制限
  • メール 5: オンボーディングメール - 追加のトレーニングとサポート

これらのメールは GitLab Admin のラベルが付いた顧客の連絡先に自動的に送信されます。少なくとも 1 つの連絡先がプリセールスプロセスの一環としてラベル付けされている必要があります。有効化コンテンツが確実に受信されるよう、可能な限り複数の連絡先に GitLab Admin のラベルを付けることを推奨します。

メールの内容はこちらでご確認ください（内部向けのみ）。

キックオフコール

⏰ 目標時間: 顧客の開始日から 14 日以内

キックオフコールは、CSM と顧客との最初の会話です。CSM は自分の役割を顧客に説明し、内部引き継ぎで得られなかった詳細情報を収集するための独自のディスカバリープロセスを開始します。これにより、効果的なエンゲージメントを開始し、サクセスプランを作成します。

キックオフコールの目的は、望ましいビジネス成果、主要な今後のマイルストーンについて合意し、CSM としてのパートナーシップを明確にすることです。

キックオフコールにはどのデッキを使用しますか？

CSM は、顧客の引き継ぎ状況に応じて以下のテンプレートから選択します。

  1. SA との間で ストラテジーロードマップ が完成している場合は、このキックオフスライドデッキを使用してください（内部向けのみ）。デッキの最適な活用方法については、こちらのビデオ概要をご覧ください（GitLab Unfiltered のプライベート動画）。
  2. 上記に該当しない場合は、このキックオフスライドデッキを使用してください（内部向けのみ）。このデッキはオンボーディング CTA の一部としても利用可能です。

CSM はキックオフコールの前に、顧客についてすでに把握している情報と、まだ理解が必要な情報をもとにこのデッキを確認・修正する必要があります。

キックオフコールから何を把握すべきですか？

理想的には、以下の情報はプリセールスプロセスで収集済みであり、キックオフではその確認と知識の深化を行います。これらの情報が不明な場合には、必ずキックオフで以下を把握するよう努めてください。

  1. GitLab を購入した理由は何ですか？ プリセールスの引き継ぎでこの質問に既に回答している場合は、質問を言い換えて、顧客が X の理由で GitLab を購入したという理解を確認し、顧客が解決しようとしている課題についての理解を確認してください。
  2. 他にどのようなツールを使用していますか？ 顧客のツール状況を把握することは、顧客が希望するユースケースに関連して GitLab の導入を支援するうえで非常に重要です。以下の各ユースケースについてのツールを書き留めてください: SCM, CI, CD, Package, Security, Monitoring, Agile
  3. ビジネス目標は何ですか？ GitLab を使って当面の目標を達成した後、次のステップは何ですか？
  4. 他に関与すべきステークホルダーはいますか？ GitLab とのビジネス上の議論から恩恵を受ける可能性のある他の関係者はいますか？CSM は常に少なくとも 2 名の定期連絡先を持つべきであり、理想的にはターゲットペルソナに沿った担当者であることが望ましいです。

上記の質問に加えて、最初のカデンスコールのタスクリストを確認し、サポートやトレーニングなどの追加の重要事項をカバーしてください。また、特にセルフマネージドの顧客に対しては、GitLab のセキュリティアラートへのサインアップを確実に行うことが重要です。サインアップはこのページの「Sign up for security notices」セクションにメールアドレスを入力することで行えます。CSM は、連絡先（ほとんどの顧客が該当）とリードに関連する SFDC レポートを確認することで、顧客がセキュリティアラートにサインアップしているかどうかを監視できます。元のレポートを誤って変更しないように、効率化のために SFDC の Personal Custom Reports フォルダに希望するフィルター付きの版を保存することをお勧めします。レポートを開いて「Save As」を選択し、レポートの名前を変更して「My Personal Custom Reports」に保存することで実行できます。その後、レポートを変更して希望するフィルターを追加できます。キックオフコールと最初のカデンスコールの間に顧客がセキュリティアラートにサインアップしない場合、CSM はその後の会話でこのトピックを再度取り上げ、これらの通知にオプトインすることでインスタンスのセキュリティを維持するために必要なアクションを把握できることを強調してください。

キックオフコールの最も重要なアクションアイテムの 1 つは、カデンスコールの確立です。CSM はキックオフコールの終わりまでに顧客との継続的なカデンスコールのスケジュールを決定し、最初のカデンスコールの計画を立てておく必要があります。

CSM ジャーニースプレッドシート

CSM は、Customer Journey Spreadsheet（内部向けのみ）を活用して、顧客のエントリーポイントを特定し、必要な有効化を把握することができます。このスプレッドシートは、インフラの構築レビューから必要な移行ステップ、DevSecOps への拡張まで、CSM として対応する複数のオンボーディングステップをカバーすることを目的としています。Scale および Growth CSM には、これらのスプレッドシートの作成・維持は推奨されません。

サクセスプランの策定（主要属性の記録）

キックオフコールが完了したら、CSM はサクセスプランの策定を開始するのに十分な情報を持っているはずです。これは、オンボーディングの成功と長期的な顧客エンゲージメントにおける重要なステップです。

⚠️ 注意: この時点で CSM はサクセスプランの効果的な最初のイテレーションを作成できるはずですが、サクセスプランは生きたドキュメントであるため、CSM はカスタマーライフサイクル全体を通じてサクセスプランを継続的にイテレーションしていく必要があります。

詳細については、サクセスプランのハンドブックページをご覧ください。

第 1 回カデンスコール: 将来の成長に関するディスカッションとチェックリスト

⏰ 目標時間: 顧客の開始日から 30 日以内

最初のカデンスコールは、通常 CSM と顧客の 2 回目の会話であり、信頼できるアドバイザーとしての取り組みを通じて価値を提供し始める機会です。

この 2 回目の顧客コールが完了することで、必要な情報がすべて収集され、顧客が今後成功するために必要なツールを提供されたことになり、カスタマーオンボーディングの完了を意味します。

オンボーディングが完了したら、オンボーディング CTA をクローズし、Gainsight で顧客をカスタマーライフサイクルの Adoption フェーズに移行させます。

以下のタスクを達成することで、オンボーディングを完了したことを確認できます。

  • 内部引き継ぎの完了: CSM が SAE/AE および SA とともにコマンドプラン、導入目標、優先事項、ステークホルダーを確認する
  • 主要な連絡先に GitLab Admin やその他のペルソナロールを割り当てる
  • キックオフコールの完了: CSM が以下を実施する
    • 自己紹介（5 分以内）
    • 顧客の購入理由を確認する
    • 顧客が持つ追加の目標について確認する
    • 顧客の DevSecOps ツールスタックについて確認する
    • 追加の顧客ステークホルダーについて確認する
    • サポートの利用方法とセキュリティアラートへのサインアップ方法を顧客に案内する
    • プラットフォーム/サービスの変更とお知らせのページ（https://about.gitlab.com/blog/categories/bulletin-board/）をブックマークするよう顧客に伝える
  • サクセスプランの初期ドラフトを完成させる（目標: 関連するステージ有効化プレイブックを活用した主要ユースケースの達成）
  • 第 2 回コール（最初のカデンス）の完了: CSM が以下を実施する
    • 成功指標の収集、マイルストーン/タイムライン、次のステップの確立を通じて、顧客の目標達成に向けた協働方法を話し合う
    • 有効化の機会（例: ワークショップ、Professional Services、GitLab ドキュメントなど）を話し合う
    • ワークショップやウェビナーの利用可能なコンテンツを共有し、GitLab 入門や主要ユースケースに関するセッションへの参加を促す
    • リリースの月次アップグレードサイクルについて話し合う
    • （セルフマネージドの場合）使用状況ピングについて話し合う
  • Gainsight の Customer 360 の Attributes タブにある関連フィールドをすべて記入する

2 回目のコールが終わるまでにこれらすべてを達成できなかった場合は、遅延の理由を記録し、次のコールまでに完了を目指してください。オンボーディング CTA では、サービスピングが有効になっていない場合に First Value Date（#time-to-first-value）をログ記録するよう求めていることに注意してください。この情報がまだない場合でも、他のすべてが完了している場合は、オンボーディングを完了として印を付け、引き続き顧客の最初の価値達成に向けた進捗の把握に取り組み、判明した時点でログ記録してください。

タイム・トゥ・バリューの指標

タイム・トゥ・バリューの KPI は、顧客へのサービス提供状況や改善の可能性についての主要な事実を把握するために策定されています。以下は、CSM がタイム・トゥ・バリューの KPI を更新・追跡するためのプロセスです。定義については、タイム・トゥ・バリューの KPI をご参照ください。データの可視化については、Customer Onboarding Dashboard をご覧ください。

タイム・トゥ・エンゲージ

目標: 14 日

CSM に必要なアクション: 最初の Timeline エントリ（コールまたはミーティング）をログ記録する

計算方法: タイム・トゥ・エンゲージは、オンボーディング CTA 開始日 と最初の Timeline コールまたはミーティングエントリの日付との差（日数）です。タイム・トゥ・エンゲージ の計算式 = Timeline コールまたはミーティングエントリの日付 - オンボーディング CTA 開始日。例: オンボーディング CTA 開始日が 2020-01-01 で、最初のコールが 2020-01-12 の場合、タイム・トゥ・エンゲージ は 11 日となります。

注意: 最初の Timeline コールまたはミーティングの日付がオンボーディング CTA 開始日と同日の場合、タイム・トゥ・エンゲージ = 0 となります。最初の Timeline コールまたはミーティングの日付がオンボーディング CTA 開始日より前の場合、そのアカウントはレポート上「0」として表示されます。

この指標が重要な理由: 顧客との最初のエンゲージメントにかかった時間を把握するのに役立ちます。エンゲージメントは、顧客との最初の CSM ミーティングとして定義されます。

タイム・トゥ・ファーストバリュー

目標: 30 日

CSM に必要なアクション: Gainsight に Cloud License データがあることを確認し、ない場合は First Value Date を手動で更新する

計算方法: タイム・トゥ・ファーストバリューは、Original Contract Date から First Value Date（顧客の C360 の Attributes セクションへの手動入力）を引いて計算されます。

Cloud License データが Gainsight にある場合、Known License Utilization が 10% 以上になった時点でシステムが First Value Date を自動的に入力します。Cloud License データが利用できない場合は、CSM が最善の見積もりに基づいて日付フィールドを手動で更新する責任を負います。

この指標が重要な理由: GitLab の顧客の使用状況を把握できます。本番環境ライセンスの少なくとも 10% が有効化された時点で、顧客はファーストバリューを達成したとみなされます。

セルフマネージド顧客向けの最善の見積もりを判断するためのポイント 注意: これは包括的なリストではありません

  • GitLab がインストールされ、顧客が使用できる状態になっているか？
  • ユーザー管理が正しく設定されており、ユーザーが製品を使用できるか？
  • 移行の場合: 移行が完了しているか、または移行が進行中で移行済みユーザーがすでに製品を使用できるか？
  • 顧客が CE/Starter からアップグレードした場合、または成長により CSM が割り当てられたが既存の顧客だった場合、タイム・トゥ・バリューは CSM が割り当てられた日と同じになります。

タイム・トゥ・オンボード

目標: 45 日

CSM に必要なアクション: オンボーディング CTA をクローズする

計算方法: タイム・トゥ・オンボードは、オンボーディング CTA 開始日 とオンボーディング CTA がクローズされた日付との差です。例えば、オンボーディング CTA 開始日 が 2020-08-15 で、オンボーディング CTA が 2020-09-18 にクローズされた場合、タイム・トゥ・オンボードは 34 日となります。

この指標が重要な理由: 顧客に関連するすべてのオンボーディングタスクを完了するのにかかった時間を把握するのに役立ちます。

インスタンス/ネームスペースのタイム・トゥ・バリュー指標

各タイム・トゥ・バリュー指標は、サブスクリプション開始日 と製品使用指標が達成された日付との差によって計算されます。すべての指標はサブスクリプションレベルで計算されます。これらの指標は過去に遡って実行されず、2022 年 2 月以降に開始したサブスクリプションのみが対象です。

  • タイム・トゥ・ライセンス利用率（10%、50%、80%）: インスタンスが 10%、50%、80% のライセンス利用率に最初に達した日付。
  • タイム・トゥ・DevSecOps デプロイメント: インスタンスが DevSecOps デプロイメントの健全性グリーン（>= 20%）に最初に達した日付。
  • タイム・トゥ・SCM デプロイメント: インスタンスが SCM デプロイメントの健全性グリーン（>= 40%）に最初に達した日付。
  • タイム・トゥ・CI デプロイメント: インスタンスが CI デプロイメントの健全性グリーン（>= 25%）に最初に達した日付。

注意: タイム・トゥ・バリュー指標が負の値になるケースがあります。これは、サブスクリプション開始日より前にインスタンスの使用を開始してタイム・トゥ・バリュー指標を達成した場合（つまり、トライアル中または無料インスタンスで価値を達成した場合）に発生する可能性があります。

コマンドプラン

コマンドプランは、生きたプリセールスドキュメントとして使用され、アカウントオンボーディング時にその目標が Gainsight サクセスプランの目標に変換されます。

Gainsight でのコマンドプラン達成状況レポーティング

顧客が当初の購入意図を達成するための確認として、現在フィールドチームは Gainsight の Customer Health Dashboard を使用して、アカウントのコマンドプランに関連する以下のフィールドと情報のスナップショットを把握できます。

  • Solution（例: Platform、Security、Automate Software Delivery など）
  • Primary Capability（例: Agile、CI、DevSecOps など）
  • Primary Value Driver（例: セキュリティとコンプライアンスリスクの軽減、運用効率の向上など）
  • Associated Score Color（例: Red、Yellow、Green）
  • Metrics - Sales が記入（ビジネスケースとは何ですか？顧客が直面している課題とその組織への影響を定量化しましたか？定量化できる指標や測定値は特定しましたか？ソリューションのビジネス上のメリットをどのように証明しますか？）
  • Identify Pain - Sales が記入（顧客の現状によって生じている問題。最大のビジネス上および技術的な課題は何ですか？これらの課題により生産性の低下、収益の減少、コストの増加などが生じていますか？課題の深刻度はどの程度ですか？顧客は変化の苦痛が現状維持の苦痛より少ないと認識していますか？苦痛を増大させる強制的なイベントはありますか？）
  • Date CP Use Case Turned Green - 顧客が当初の購入意図を達成した正確な日付を記録するスタンプ日。

このレポートにより、CSM と Sales は Salesforce のコマンドプランに記録された顧客の目標達成状況を追跡しながら、顧客とアカウントチームが顧客の主要ユースケースの達成状況を把握するための支援ができます。

オンボーディングの遅延

顧客のジャーニーと成功を推進する能力における、オンボーディングの重要性を考慮すると、できるだけ早く進める必要があります。GitLab 側または顧客側のいずれかの理由でオンボーディングが遅延する場合は、その理由を記録し、適切なアクションを取る必要があります。

遅延の記録

オンボーディングが遅延している理由の詳細を、以下の箇所に記録する必要があります。

リスクとトリアージ

遅延が顧客側の原因（例: 興味の欠如、エンゲージメントの不足/「連絡が取れない」状態）による場合、アカウントにはリスクがありますので、フラグを立てる必要があります。

オンボーディングのための Gainsight

CTA 作成基準

CSM 割り当てアカウント: 顧客が CSM 割り当ての閾値に達するか超えると、Gainsight 内でコール・トゥ・アクション（CTA）がトリガーされます。

CSM フィールドが入力されていない場合、CTA は CSM マネージャーに対して作成されます。入力されると、CSM のオンボーディング CTA が開始されます。オンボーディング CTA の開始は自動化されたプロセスですが、Cockpit に移動して + CTA をクリックし、オンボーディングプレイブックを選択することで手動で作成することもできます。

CTA のコンテンツとプロセス

CTA は、このハンドブックページで説明したトピックをカバーする最初の顧客エンゲージメントを通じて CSM をガイドします。

CSM および CSM マネージャーは、Gainsight ダッシュボードを使用して現在オンボーディング中の顧客を管理し、進捗が確実に図られているかを確認するとともに、各四半期末に達成された指標についてのレポートを作成できます。

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