Content last updated 2024-06-27

顧客との価値を築くためのベストプラクティス

GitLab フィールドチームの、顧客との価値を築くためのベストプラクティスの概要。

以下のページでは、顧客との価値を築くためのベストプラクティスの概要を示します。Sales Operating Procedures の完全な概要については、こちら の 4 つのフェーズをご覧ください。

最大の価値をもたらすために顧客とプロスペクトのアカウントを研究する

GitLab の顧客は皆ユニークです。 そのため、私たちは彼らのどの問題を GitLab が解決できるかを理解する時間を費やし、私たちがどのようにして、また役立つかどうかを示さなければならないと考えています。

それは、顧客が取り組んでいる大局を理解することから始まります。これは、技術的な要件から一歩離れて、なぜそれらがビジネスにとって重要なのかを理解することを意味します。

Value Deck を構築する

Value Deck は、より多くの時間を費やすフォーカスアカウント専用です。 これは、Corporate Objectives、Business Strategies、Key initiatives、Challenges に関する高レベルな情報を含むデッキです。

次に、この情報を使用して、顧客の Challenges と、Business Strategies、ひいては Corporate Objectives が達成されない場合に何が起こるかを要約する Problem Statement を作成します。

これに時間を費やすことで、顧客をより理解し、賢く協力して働くことができ、Commercial Validation 段階でビジネス価値を作成するのにも役立ちます。

Value Deck はどの段階でも紹介できますが、プロスペクティングを開始する前に行うのが常にベストです。なぜなら、異なるアカウント向けにカスタマイズしたメールを構築するのに役立つからです。

協力的にしましょう: 顧客と一緒に取り組む（または空白のバージョンを印刷して記入してもらう）か、調査結果をレビューしてもらい追加するものがあるかを確認しましょう。 あなたのチャンピオンはそれを高く評価し、Uncle Google よりも自分の Challenges と Key Initiatives についてより詳細に共有できます。

標準的な実装シーケンス

GitLab 製品は、顧客のニーズに非常によくマッチしています。 実際、顧客が単に 1) 本気で試して、2) 理解すれば、ほぼ常に顧客を獲得し急速に成長します。 つまり、私たちのベストなセールスモーションは、両方を同時に達成することを確実にすることです。 私たちは、最初の会話から最初の拡張決定、より高いティアへの移行、さらには将来の更新まで、顧客が理解し良い決定を下すのを支援する最良の方法はハンズオンワークショップであることを学びました。 すべてのステップで、ワークショップは顧客にサービスを提供する最も効率的かつ効果的な方法です。

顧客とのすべての会話のゴール:

  • ワークショップに合意する
    • ワークショップは、プロスペクトに 価値を提供 し、GitLab について文脈に沿った会話をする素晴らしい方法です。プロスペクトが GitLab に進まなくても、ワークショップを行ったことで常により良い状態になるはずです。これはどのような種類のワークショップでもかまいませんが、a) アカウントのキーパーソンが文脈の中で GitLab の完全な機能について学んでおり、b) 製品でハンズオン（スライドだけでなく）で学んでいる必要があります。顧客が適切な人々を 1 か所に集め、ハンズオンで何が可能かを確認すると、GitLab はほぼ常に顧客との採用または成長プロセスの次の段階に進みます。製品は信じられないほどフィットしており、彼らは単にライブで自分たちの文脈で見る必要があります。ワークショップは、顧客にとっての価値実現までの時間と、独自の環境で GitLab を理解するまでの時間の両方を大幅に加速できるため、「トライアル」の機会よりもはるかに効果的です。

セールスモーションとシーケンス:

  1. 最初の会話: 顧客がまだ GitLab について学ぼうとしている初期の会話で、意思決定者と関与するチームメンバーと ワークショップに合意 し、ハンズオンワークショップでエンドツーエンド DevOps について学び、自分たちの環境で何が可能になるかを確認し、評価して 5 倍のスピードで DevOps を、同時により良いセキュリティと品質をよりよく理解するための動作する例を持って退出します。
    1. 配信: DevOps Best Practices ワークショップ
    2. 顧客に、自分たちの会社が自分たちの環境でエンドツーエンドの DevOps と GitLab で成功できる方法の完全な理解を提供する
    3. 顧客自身の環境での GitLab のハンズオンセットアップ => これが現在運用されている PoC デプロイになる
    4. 成功を測定し、現実世界での経験について報告するためのフレームワークで PoC を開始
    • 完了時に、初期デプロイメントと顧客になる機会に移行します。
  2. 初回購入: PoC が成功裏に完了したとき: _別のワークショップに合意する
    1. 配信: フェーズ 1 デプロイで GitLab を使用する方法のデモ。望ましい最終状態を顧客に示す。
    2. GitLab のベストプラクティスについて顧客にトレーニングする
    3. 共有コンピュート（接続された Runner と Kubernetes クラスター）で顧客をセットアップする
    4. 合意されたデプロイメントプラン、タイムライン、およびターゲット結果を持ってデモを終える
    • 完了時: 顧客がサブスクリプションを購入する
  3. CI 拡張の会話: 最初のデプロイメントになかった場合は、できるだけ早く CI ワークショップに合意
    1. 配信: CI ベストプラクティスワークショップ、顧客向けトレーニングおよびハンズオントレーニング
    2. ワークショップ中に毎回顧客のために共有 Runner をセットアップする。ワークショップを完了する前にこれが整っていることを確認する
    3. 顧客のより広いチーム向けに CI トレーニングをスケジュールする
    • 完了時: ティアを上げることなく、CI の使用からより広い価値を得るにつれて、顧客のサブスクリプションユーザーベースを拡張
  4. 部門拡張の会話: 顧客が会社の一部で GitLab で大きな成功を収めているが、他の部門/組織がまだ採用していない場合: 時間を節約するために新しい組織と ワークショップに合意 します。4 時間のワークショップで、その新しい組織は開発者、DevOps マネージャー、統合チームなど全員が以下とともに退出できます:
    1. 自分たちの会社が自分たちの環境でエンドツーエンドの DevOps と GitLab でどのように成功してきたかの完全な理解
    2. 自分たちの環境で実際の開発を評価するための動作する例
    3. 成功を測定し、現実世界での経験について報告するためのフレームワーク
    • 完了時: すでに実装されたインスタンスに本番ユーザーをデプロイし、すべてが完全にトレーニングされ成功していることを確認します。
  5. ティアアップの会話: 顧客がより高いティアの機能（例えば Ultimate のセキュリティ）に興味がある場合は、最初のコミットからセキュリティを伴うエンドツーエンドの DevOps の利点を見ることができるよう ワークショップに合意 します。これらは 1 日のワークショップで、私たちの顧客の成功への大きな投資です:
    1. DevSecOps ワークショップ: Dev、Ops、Security チームメンバーが DevSecOps とその実装方法を完全に理解する。セキュリティ自動化、auto DevOps など。ハンズオン体験と結果を可能にするためにワークショップで Ultimate を実装する。
    2. Kubernetes ワークショップ: 高速なサイクルタイムと高いセキュリティと品質を伴う完全に最新の開発のためのクラウドネイティブベストプラクティスワークショップ。私たちの顧客が Kubernetes のエキスパートになるのを支援します。
    3. エンドツーエンド DevOps: DevOps のすべてのステージを使用する。可能な限り高速なサイクルタイムと可能な限り高いセキュリティと品質のために GitLab の残りのステージを使用する。
    • 両方のワークショップで、特定の文脈で重要な合意されたケースで、成功を測定し証拠を提供するフレームワークを提供します。
    • 成功時、より高いティア（この場合は Ultimate）で顧客を更新し、すべてのユーザーがトレーニングされ、新しい機能を完全に活用していることを確認します。

Proof of Concept（POV）の追跡

Stage 3-Technical Evaluation で、プロスペクトまたは顧客は評価の一環としてプルーフオブコンセプトに関与する場合があります。 関与することを決定した場合は、現在 POV に関与している既存のオポチュニティを追跡するためと、POV に関与した顧客と関与しなかった顧客の勝率を追跡するためにこれを使用するため、以下の情報を入力してください。

  1. オポチュニティで、3-Technical Evaluation セクションに移動します。
  2. POV Status フィールドで、POV のステータスを入力できます。オプションは、Not Started、Planning、In Progress、Completed、または Cancelled です。
  3. POV Start および End Dates を入力します。
  4. POV Notes を入力します。
  5. POV Success Criteria、つまりプロスペクト/顧客が POV が成功したかどうかを判断する方法を入力します。
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License