Commercial Sales

Commercial Sales ハンドブックへようこそ

Commercial Sales 部門は、GitLab Salesディビジョン全体の一部です。私たちは、SMB および Mid-Marketのお客様が GitLab と共に歩むジャーニーを通じて、最大の価値を提供することに注力しています。

Commercial チームのグループ

• SMB Account Executives
• Mid Market Account Executives
• Area Sales Managers

新入社員としてのスタート

Commercial Sales オンボーディングページを必ずお読みください。

素早くオンボードするためのトップヒント

1. ご自身のリージョン向けの関連する SalesForce ダッシュボードをブックマークしてください。これは成功に不可欠です。初めて参加するときにマネージャーがリンクを共有します。
2. Commercial Sales で使用されるクローズ日の慣例に慣れてください。
3. Required 7を完全に理解してください。必要に応じて、チームメイトやマネージャーがこの理解を喜んでサポートします。
4. お客様が製品について何を考えているかを把握するため、GitLab のレビューに目を通してください。出発点として良い 2 つの場所はSoftwareadvice.comとGartner Reviewsです。
5. 動画の視聴はオンボーディングの中心です。YouTube や Chorus の動画を 1.5 倍または 1.75 倍速で視聴することで、効率的に進められます。情報は保持しつつ、より短時間で済ませられます。Settings ウィジェット > 再生速度に移動してください。
6. 入社直後は、Slack で検索することが有用な情報を見つけるのに最適な方法です。これは会社で質問したり情報をアナウンスしたりするための主要な方法です。情報源として特に良いチャネル: #questions #sales #competition
7. BuiltWith.comを使用して、お客様が現在使用しているテクノロジーを把握しましょう（ただし、お客様と必ず確認してください）
8. 最初の 30 日間で学んだことをすべて記録するために Google ドキュメントを作成すると役立つかもしれません。覚えるべき情報がたくさんあるため、ノートを取る習慣を身に付ける良い機会でもあります。これはGitLab カルチャーの重要な一部です。
9. 同僚とのコーヒーチャットは、いくらやっても多すぎることはありません。許可を求める必要はなく、相手のカレンダーに時間を入れるだけで結構です。
10. SDR からミーティングが入った際に動かす必要がないよう、カレンダーは常に最新の状態に保ってください。
11. 可能な限り多くのChorusコールを聞いてください。これらはオンボーディングの優れた方法です。
12. このページにあなた自身のヒントを追加して、次の新人にとっての助けにしましょう！
13. GitLab に慣れ、Issue、マージリクエスト、ハンドブックページを検索できるようになってください。これは、オンボーディングの進捗を大幅にスピードアップします。

継続的な学習

以下は、GitLab の Commercial Sales チームメンバーが継続的な学習と成長に非常に有用と考えているリソースのリストです。これらの一部のリソースは公開されていないため、必要に応じてチームメイトに相談してアクセスしてください。

• GitLab Direction GitLab のビジョン、フレームワーク、計画された機能、およびPaid Tiersの各リリース日が含まれます。
• GitLab Blog リリース、エンジニアリング、オープンソース、カルチャー、その他人気のトピックに関する月次記事。
• GitLab Unfiltered YouTube 会社のミーティング、イネーブルメントセッション、その他のトピックに関する動画とプレイリストを含む、GitLab の従業員専用の YouTube チャネル。GitLab のSales Enablement プレイリストにアクセスしてください。
• Chorus Recordings 私たちのチームの通話とデモ録画の履歴は、新規および既存のセールスチームメンバーにとって貴重なトレーニングリソースです。
• Sales & SDR Enablement Sessions セールスとマーケティングチームメンバーが選んだ人気の製品、市場、セールストレーニングトピックをカバーする週次トレーニングセッション。
• Product Study Guide GitLab の各ティアで現在提供されている機能の全体像と、ティアアップグレードの理由をチームメンバーが理解するための学習コース。
• Sales Trainingページ
• Commercial Sales Enablementページ

イベント

出張時は、コストと時間の両方の ROI を考慮してください: イベントに行くときはまず次のことを考えてください:

• 出張の総支出はいくらになりますか？
• 食事と宿泊にかかる総額はいくらになりますか？
• お客様との食事にかかる可能性のある総額はいくらになりますか（食事 x お客様 x 回数）？
• Salesforce から離れる総ビジネス時間はどれくらいですか？
• 8 時間: その場合、$に対して 5 倍のリターンが必要です。イベントのパイプラインは約 30%でクローズすることに留意してください
• 個人の生活時間からどれくらい離れることになりますか？

以上のおおまかな計算を考慮して、イベントに行く前に、十分な Net ARR をドライブ/予約することにコミットする必要があります。 注: これは、ミーティングを予約せずに出張承認を得られないという意味ではありません。出張承認を得たら、パイプラインを生成するために人々をイベント/ミーティングに参加させるのは自身の責任であるという意味です。

トリップノート

GitLab のフィールドイベントに参加する究極の目的は、洞察を得て価値を加えることです。共同創業者の Sid Sijbrandij は、カンファレンスやイベントの重要性についてここで語っています。彼は、GitLab チームの参加の主な目標は、プレゼンテーションへの参加のみではなく、お客様や見込み客とつながることであるべきだと信じています。トリップノートは、このデータを追跡・捕捉するための内部プロセスです。

なぜ、いつ?

トリップノートは、GitLab で働くチームメンバーが会社のために旅行する際は常に、Commercial Sales チーム全員に必須です。個人的な理由で旅行した場合でもトリップノートを共有することは楽しく価値のあることと考えていますが、それは皆さまの裁量に委ねられています。

トリップノートを適切に文書化する方法は？

ベストプラクティスのプロセスに従い、トリップノートテンプレートを、今後の出張準備のフォーマットとして使用してください。

トリップノートのベストプラクティス

1. Commercial 出席者は、Google ドキュメントでメモを書き上げます。
2. メモは Commercial チームレビュー用に GitLab 内部のみ読み取り専用としてCommercial Sales Drive Trip Notes Folderに保存してください。
3. 保存後、commercial_global_all チャンネルでメモへのリンクを Slack で共有し、最近の出張をチームに知らせてください。
4. 最後に、ポストトリップフィードバックを、会社全体および Field Marketing チームに対し、特定の Event Issue の「Post Event Recap & Feedback」スプレッドシートで直接共有してください。

Give Back Project

Give Back Project とは？

• Give Back Project は、Commercial Sales チームがより良い結果を達成するのを助けるための、自己選択型の機会です。完了時に Commercial Sales チームの 70%以上に採用され、少なくとも月に 1 回使用される有限プロジェクトです。
• Give Back Project は、すべての新しい Commercial Sales チームメンバーに割り当てられ、オンボーディングプロセスの一部として完了が必須です。

Give Back Project がある理由は？

• Give Back Project の目標は、新しいチームメンバーが Commercial Sales チームに即座に貢献できるようにすることです
• GitLab のコラボレーションと結果のバリューを育みます
• Give Back Project は、チームメンバーに今日のチームの問題に触れる機会を与え、チームが過去にどのように欠点に対処したかを振り返ることを可能にします

Give Back Project を適切に文書化する方法

• Give Back Project は、Commercial Sales issue trackerでチームメンバーによって記述・取り組まれます
• 繰り返す必要があるもの（カスタマー AMA など）の場合、新しい人がこれを達成する方法の説明と共に、関連するハンドブックエントリが作成されます
• Give Back Project は有限であるよう設計されていますが、GitLab では常にイテレーションの余地があります。別のチームメンバーが必要に応じてプロジェクトに追加できる方法に関する必要な指示を含めてください

Give Back Project の例

カスタマー AMA: GitLab チームメンバーが現在のお客様とのミーティングを開催し、GitLab での経験について何でも質問できる機会を提供します

カスタマーミーティング: GitLab で外部ミーティングを行うためのベストプラクティスの共有

トリップノート: チームの他のメンバーがインサイトを得られるよう、フィールドイベントに参加したチームメンバーがデータを追跡・捕捉できるようにします

パートナー/チャネルとのビジネス: これらの領域で価値を最大化するため、パートナーやリセラーとの協業方法に関するガイドライン

お客様の購入後の対応方法: お客様の購入範囲に基づき、新しい GitLab のお客様を扱うためのベストプラクティス

お客様の技術評価: GitLab が問題を解決する最良の方法を処方し、組織的アライメントを作成するために、お客様の現在の技術環境を適切に評価する方法

Give Back Project とチームが取り組んでいる他のオンボーディング課題の完全なリストについては、プライベートリンクこちらをクリックしてください。

Paid Time Off (PTO)と結果

以下のステップが、Sales にとって休暇プロセスを簡単にし、ビジネスの継続性を維持するのに有用であることを発見しました。これは、会社全体のGuide to Paid Time Offを置き換えるものではなく、Sick Time Policyにプロセスを追加するものでもありません。これはグループ固有に計画された休暇のための自分自身とチームを準備する拡張的なアプローチです。

• GitLab チームメンバーガイドの休暇に関する内容に従いマネージャーに通知
• 地域チームメンバーにカバレッジを依頼し、計画された休暇を共有
  • 理想的には類似の役割で、OOO 中にカバーする余裕がある人を選ぶ
  • アクションアイテムの共有ドキュメントを作成し、ハンドブックの参照に従うと有用な場合があります
  • 他に対応できる人がいない場合、ダブルカバレッジまたはマネージャーからのサポートが必要なケースもあり得ます
  • 注: Family & Friends Dayについては、GitLab の公開的に表示されるシャットダウンであるため、バックアップカバレッジは不要です。OOO の自動返信メッセージにその旨を記載し、ハンドブックページとテクニカルサポートの連絡先を含めてください
• Slack の Time Off by Deel で休暇を提出し、すべてのタスクのアサイニーロールとしてカバーしてくれるチームメンバーを追加してください。「即時および一般」のようなラベルを付けることができます
• 次のタイトルでカレンダー招待を作成:
  • 例: 「First and Last Name OOO - (First and Last Name) is Covering」。マネージャーとカバーする人へのオプションの招待。
• 復帰日の朝をカレンダーでブロックし、次のようなキャッチアップ時間を確保:
  • Clari での予測を再提出
  • 入ってきた新しいアカウントのランク付け
  • メール、サポートチケットへの返信、Required 7 経由
• オプションで、カバーする個人と同期するための時間を復帰日にスケジュール

オフィスにいない準備の役割の責任

• 現在クライアントに発行されている見積もりは、カバーする人を cc に含めて docusign で再送信してください。質問がある場合に備えて、カバーする AE をクライアントにメールで紹介してください
• このレポートを実行し、右上のdatesフィールドを編集して OOO 日付に変更し、「run report」を選択します。OOO 日付にネクストステップが一つも入っていないことを確認し、緊急ではない事項については PTO 前にカバーしてください。これによりバックアップや復帰後の自分に大きな作業負担を残さないようにします。
  • 緊急のネクストステップがスケジュールされている場合は、休暇前に連絡し、クライアントに OOO であることを伝え、紹介付きのメールでカバーする人またはマネージャーをcc:に含めます
  • 緊急性の低いネクストステップが近づいている場合は、休暇前または後に処理すべきか評価し、評価に基づいてネクストステップの日付を編集してください
• あなたをカバーする人のメールを含むメール OOO 自動返信を設定してください。あなたが不在の日にマネージャーが利用可能であれば、メールメッセージで他の緊急の対応のためにマネージャーも追加できます

休暇前日:

• すべての必要な Required 7 レポートが最新であることを確認
• Clari で予測を提出
• 仕事関連の電話通知のオプション:
  • 推奨: メールや Slack などの仕事関連のアプリを削除
  • これらのアプリを電話に戻すのが難しい場合の推奨: 仕事関連のアプリの通知をサイレントに
  • PC を閉じたままにして、楽しい時間を過ごしてください！

Area Sales Managers は休暇前に検討する追加のステップがあります:

• 1:1 とチームミーティングのカバレッジに関する期待を設定
• SFDC の見積もり承認ルーティングをカバーする人に更新。あなたの名前のドロップダウン - My Settings - Personal - Approver Settings に移動。Delegated Approver の隣でカバーする人を検索し、確認して Save を選択
• Navan で Settings - Account Details で Vacation Delegate を設定
• 予測を提出
  • 計画された休暇がガイドに記載された 25 連続日を超える場合、Sales Operationsプロジェクトで依頼を提出することで、Clari での予測のための一時的な ASM カバレッジを要請します。

チームメンバーのバックアップとしてカバーする役割の責任

• 連絡があった場合、不在の AE のお客様には 24 時間以内に応答してください。
• 不在 AE のチームの Required 7 ダッシュボードに表示される新しい Required 7 アイテムに対処してください。
• 設定された緊急のお客様コールや BDR/SDR コールを引き受けてください。何らかの理由で対応できない場合は、適切なバックアップが見つかるようマネージャーに伝える必要があります。カレンダー上のお客様や見込み客とのコールは遅らせたり、再スケジュールしたりすべきではありません。
• 不在 AE がいる間、そのテリトリーのディールに取り組み、クローズしてください。

バックアップ AE に必須ではないこと:

• 特定の AE 役割に関連しないタスクをカバー。たとえば、不在 AE がチームメンバーリソースグループ（TMRG）のメンバーである場合、TMRG ミーティングに出席する必要はありません。
• 不在 AE のお客様へのアウトバウンドキャンペーン（もちろんやりたい場合はやってもよいです）。
• 時間がない場合や複数のチームメンバーをカバーする場合は、バックアップになることに同意する必要はありません。他に助けられる AE がいます。
• 不在 AE に代わって予測する。必要に応じて彼らの商談を更新するだけにしてください。

Required 7

新しいチームメンバーはThe Required 7に慣れる必要があります。これは、優れた Commercial Sales Account Executive であるために必要な 7 つの戦術的スキルです。

1. アカウントをランク付けする - 動画はこちら
   • すべてのアカウントをランク付けし、なぜそうしたかを説明。将来の効率のためソースを記録。これはあなたの（最近の）ランキングであるべきで、以前のオーナーや前会計年度のランキングではいけません。変更されていない場合は、変更されていない理由を記載してください
2. SMB は$5k、MM は$10k を超える商談に対して、（デッキの変更を検討する）カスタムデッキをAmount（注: Net ARR ではなく Amount）で作成:
   • 次に最良の選択肢に対して GitLab を使用する ROI を計算（これは何もしないこととの比較かもしれません）
   • 今後お客様に提供する 2 つのオプションを提供 - 通常は GitLab のオプション（例: Ultimate または Premium）
   • お客様のためのカスタマイズされたビジョンを実演: 「単一アプリで DevOps をすべて GitLab で行ったらどうなるか？」
   • そのビジョンに対する完全な応答と、それが可能だと思う理由、または可能でない理由をお客様自身の言葉で捕捉。この捕捉はスピーカーノートで行うことができ、お客様が検証した後、コール後のアクティビティにコピーできます。
   • 動画はこちら、また効果的な ROI スライドデッキの作成についてこの動画、このサポートデッキを必ずご確認ください
3. 重要情報を捕捉:
   • お客様/見込み客は GitLab についてどのように知り、私たちが何をしているかについての理解は何ですか？
   • ディールに勝った/負けた理由に関する意味のある情報
4. コールノートの記録 ミーティング中に効率的にメモを取る動画とトップパフォーマーからのトップヒントこちら
5. ネクストステップを更新する - 動画はこちら
6. Command plans、入力する必要があるもの:
   • SMB $5k、MM $10k Amount - この Amount 閾値を超えるすべての商談概要フィールド（whys）とクローズプラン
   • SMB $10k、MM $20k Net ARR - この Net ARR 閾値を超えるフル Command Plan
   • まだ答えやデータがない場合は、その情報を取得するためのスクリプトとネクストステップで Command Plan フィールドに入力してください
   • Command Plan の例外: チャネル管理商談ではアクセスがない場合があります - 商談タイトルにChannel-Managedと記入してください
   • (トレーニングセッションはこちらとトレーニングデッキはこちら)
7. 商談を常に最新の状態に保つ 動画

アカウントランキング

Commercial Sales チームは、Account Object のフィールドを使用してアカウントを階層化する必要があります。これは、新規または拡大の見込み客を探す際に、追跡するアカウントを優先するのに役立ちます。SMB および Mid-Market AE に特有の定義を以下に示します。

ランキングのトレーニングと定義

Commercial Sales: Account Ranking Training Clippet

アカウントランキング用 SMB Account Executive 定義

• Rank 1: 今後 12 か月以内に新規ビジネスまたはアップセルの可能性がある上位 10 アカウント
• Rank 1.5: タイムラインのない販売機会があるため、見失いたくない将来の機会
• Rank 2: 機会があると考えますが、開く前およびセールスサイクルを始める前に追加作業が必要
• Rank 3: グリーンフィールド、SDR の注目 - 場合によりドリップキャンペーン
• SMB AE は Rank 1 および 1.5 のアカウントオブジェクトに潜在的ユーザーフィールドを記入する必要があります
• SMB AE はアカウントが Rank 2 または 3 である理由をノートセクションに記入する必要があります

アカウントランキング用 Mid-Market Account Executive 定義

• Rank 1: 今会計年度の Net ARR を最大化するために取り組んでいるアカウント。
• Rank 1.5: Rank 2 のうち、将来の Rank 1 になりそうな最良のサブセット。
• Rank 2: 成長させようとしているアカウントで、少なくとも月に 1 回は対話。
• Rank 3: 月次で GitLab および DevOps について情報提供を続けるアカウント。

クローズ日の慣例

まず、商談レベルまでの予測は、動機や願望ではなく正確性のためのルーチンな演習です。毎週水曜日、地域時間の業務終了時刻（午後 5 時）までに、Clari で 5 つの値を更新することが必須です。これらは Renewal Loss Best Case、Renewal Loss Best Case、Gross Net ARR Best Case、Gross Net ARR Commit、Net 50/50 です。この時、パイプラインの清潔さを再確認し、ここに記載されているクローズ日の慣例に常に従う必要があります。

1. クローズ日は、最もクローズする可能性が高いと考える月であるべきです（以下に記載される 1 つの例外を除く）。
2. 常に、Net ARR 金額は、クローズ日に反映された月に商談がクローズする際の実際の金額の最良の推定を反映する必要があります。オンサイト訪問からの戻り以外には例外はなく、アカウントと話していなくても同様です。新しい商談を取得した場合、アカウントを迅速に評価し、経験を考慮して、会社が取引する金額について教育的な推測をする必要があります。
3. ステージは、お客様が購入プロセスのどこにいるかを表しており、あなたと取った具体的なステップだけではありません。

3 つのクローズ日:

1. クローズする月の最終日 コンペリングイベントが定義されている場合のみ
2. 見積もりが署名のために送信されたときに商談がクローズする実際の日。署名が戻ってこない場合、期限切れと表示され、その週の金曜日にクローズすべきです。リニューアルはこの慣例にデフォルト設定されます
3. 次の月の初日、コンペリングイベントが定義されていない
   1. 月の初日にクローズ日を置くことは、最大 48 時間の一時的なステータスで、その間に AE はチャンピオン／エコノミックバイヤーと直接協力してコンペリングイベントとクライアントタイムラインを確認します。決定したら、AE は実際のクローズの月の最終日にクローズ日を移動します。
   2. このクローズ日は、入ると思われる時の約 60 日のウィンドウを持ちます

例: 4 月 23 日、従業員 410 人で不明な率で成長中（エージェンシーであるため不明確）の企業に対して、新規ビジネスの Mid-Market 商談が特定されています。会社は今月終了するトライアルで評価を完了し、解決しようとする問題が初期に定義されており、以前に GitLab を使ったことのある一部の人々がいます。

• AE と自分への質問は、4 月、5 月、または 6 月の購入確率は何%ですか？
  • 90% 4 月、10% 5 月

Chorus 録画

すべての Commercial Account Executives にとって Chorus 録画ライセンスは必須です。私たちは次の理由でお客様コールを録画することを意図しています:

• トレーニングのため、お客様に最高の体験を提供していることを確認するため
• お客様への会話の視覚的な記録として提供するため
• 会話で見逃した可能性のある詳細を確認するため

コールを録画するために必須のステップ

Chorus Schedulerの使用手順に従ってください

Deal Reviews

Project 35

組織として成長を続ける中、優れた営業体験を提供するための営業スキルの開発は、お客様体験の重要な要素です。その体験の質に応じて、お客様が GitLab との仕事を楽しむか否かが決まります。私たちは、皆さまの営業スキルの向上を支援するため、「Project 35」というプログラムを作成しました。私たちは、これらのスキルが他のすべての営業機会で価値があるという目標で、四半期の最大の機会を活用して営業スキルを磨いています。

Project 35 の一環として、次のコアな営業スキルに焦点を当てます:

1. 優れたセールスコールの実行とコール前準備の重要性
2. Command Plan（なぜ今、なぜ GitLab、なぜそもそも何かをするのか）を発見するための強いディスカバリー
3. ROI の構築
4. チャンピオンの発見と育成
5. 交渉
6. 複雑なディール管理
7. コラボレーション - ピアとリーダーシップ間
8. 次の役割と大規模ディール管理への準備

Project 35 コール中、自分の商談について話す AE は、次の質問に答えます:

1. ノーへの準備。「ノー」と言われるすべての質問または理由は何ですか？
2. 関係を構築していますか（オンサイト、その他）？
3. プロジェクト名とプロジェクトのタイミングを正確に決める（サービスを売る）
4. ROI スライドに対する販売
5. 前の質問で発見された情報に基づき、ライブでネクストステップを更新するための AE へのサポート理由を使用。マネージャーは、ライブまたは非同期でレビューするディールについて、Manager Notes セクションにコメントを入力する必要があります。
6. 広範な営業チームを巻き込みます。ディールの販売を支援している CSM、SA、パートナーは誰ですか。名前で挙げてください。ディスカッションのドキュメントで彼らをアサインし、コールに参加してディスカッションに貢献できるようにしてください。

Opportunity Consults と Lightweight Deal Reviews

Opportunity Consult (OCF)は、商談Command Planをレビューするための AE と ASM 間の徹底した双方向の会話です。AE は ASM に対して、Opportunity Overviewフィールド、お客様のペインポイントと望ましい結果、MEDDPPICC商談認定フレームワークに沿った認定の課題やギャップについてより詳細な情報を提供し、Close Planを明確に表現し、最大の商談リスクとそのリスクを軽減するアクションを特定することを期待されます。

Lightweight Deal Review (LDR)は、Command Planのギャップと具体的なネクストステップを特定するように設計された、より短い（5～10 分）ディールレビューです。LDR の最後に、AE と ASM は Command Plan にない情報を捕捉する計画と、次のコールまでとその前の具体的なアクション計画を立てるべきです。

Opportunity Next Steps ベストプラクティス

1. Next Steps Date および Next Steps を常に最新の状態に保ち、お客様の購入プロセスを続けるためにアクションを取るという、将来の自分への課題としてください。
2. 日の始まりには Email、Zendesk、リードキューなどのすべての入力をチェックして、その日の優先事項にこれらの依頼をトリアージできるようにしてください。
3. 1 日の時間を 4 つの方法で割り当てます:
   • 予定されたお客様ミーティング
   • プロアクティブな E メールと社内の取り組み
   • プロアクティブな電話の取り組み
   • 入力を再度チェックする時間
4. プロアクティブな時間ブロックを開始するとき、商談ビューを開き、Next Steps Date で並べ替えます。
5. Next Steps は具体的かつ説得力があり、読んでから 3 分以内にアクションを取れるようにすべきです。
   1. Next Stepsには行動を取る次のもののみを含むべきです: 日付なし、履歴なし、ネクストステップのみ
   2. Next Stepsを更新すると、Next Steps Historyが自動的に以前のNext Stepsを捕捉し、日付スタンプを適用して逆時系列順に保存します
   3. 注意: 以前にNext Stepsフィールドに履歴を含めていた場合、次回Next Stepsを更新する際にフィールドを完全にクリアし、ネクストステップのみを入力する必要があります

商談固有のスライドデッキ

合計金額（Net ARR ではなく）が$10,000（Mid Market）または$5,000（SMB）を超えるすべての商談で、お客様または見込み客と共有されるカスタムスライドデッキを持つことが必須です。カスタムデッキは、商談ホームページの SalesForce フィールド「Link to Custom Pitch Deck」にデッキリンクを貼り付けることで、商談に添付する必要があります。これにより、Mid Market Account Executives と SMB Account Executives は重要なアカウント情報を捕捉できます。さらに、機能ではなく価値に基づいた販売が促進されます。

カスタムデッキ要件

1. ビジュアル要件
   • デッキのメインカラーはお客様のものと一致または類似します。
   • 可能な場合はお客様のロゴを使用します。
   • お客様にブランクテンプレートを依頼することも適切です。
2. お客様が合意したアジェンダ
   • お客様と会う際は、共同販売を支援するため合意したアジェンダを活用します。
3. GitLab と次に最良の選択肢の ROI 計算
   • 新規ビジネスの場合、次に最良の選択肢は「何もしない」または競合となる可能性があります。

• リニューアルの場合、次に最良の選択肢は以前にやっていたことに戻ることになる可能性があります。

1. GitLab で進む 2 つのオプション（おおまかな計画）
   • 新規ビジネスの場合、これはTwo Lane Sellingの形を取り、高エンゲージメントと低エンゲージメントのオプションを提供します。
   • リニューアルの場合、1 年契約と 3 年契約のオプション、または Premium vs. Ultimate になる可能性があります。
2. お客様への非カスタム単一アプリピッチ
   • このスライドには、ソフトウェア開発ライフサイクル全体のための単一アプリケーションとして GitLab を使うビジュアル表現が必要です。
   • このスライドの意図は、お客様と「何が可能か」について会話し、彼らのフィードバックを捕捉することです
3. 「Single Application」スライドへのお客様のフィードバックの完全な捕捉
   • 「single application」スライドのスピーカーノートにお客様の実際の言葉を捕捉

Red / Green プロセスと手順

Red / Green の目的

ASM の効果的なコーチングが、なぜ今、なぜ何かをするか、なぜ GitLab、そして見込み客／クライアントに対して Account Executive が取る具体的なネクストステップをカバーする。Red/Green プロセスの目標は、各指定された会計期間（月／四半期）でクローズする商談を正確に予測することです。Red/Green プロセスは、お客様がクローズするのに最も快適なタイムラインを特定する周りのスキルを最も鋭く構築することを目的としています。

Red / Green 定義

各会計期間の終わりにクローズする可能性のある各商談を、Red（月末までにクローズしない）または Green（月末までにクローズする）のいずれかとして指定し、マネージャーノートを色の理由と次のチェックインまでに AE が完了する具体的なネクストステップ（通常は翌日）で更新します。コンテキストとして、グリーンのアカウントには、期間末までのクローズに対応する「なぜ今」があります。 - Red/Green でレビューされるアカウントの閾値（特に指定されない限り）は次のとおりです: - SMB: $2,000 NetARR 以上 - Mid-Market: $7,000 NetARR 以上

Red / Green 戦術

1. Red/Green ミーティングは、毎月 15 日（または 15 日前の最も近い平日）と、月の最終 5 営業日に開催されます。

2. Area Sale Managers は、各 Account Executive とライブでレッド／グリーンミーティングを実施する必要があります。この議論は非同期で行うべきではありません。以下の項目のチェックリストをこの順序で確認してください。前のものに自信があったら次の質問に進みます

   • この商談は Red か Green か？
   • そもそもなぜ何かをするのか？
   • なぜ GitLab か？
   • なぜ今か？（この商談が特定の時間枠内にクローズする時間駆動の理由があるか？）
   • あなたが最も近い関係を持つ人物のレベルは何か？
   • 彼らはあなたをどのように助けてくれるか:
     • お客様が GitLab を購入する理想的な時期に関する正確な情報を取得？
     • 上記情報にアクセスできる組織内の他の人へのアクセスを取得？
   • 上記の項目の答えに基づく AE の即時のネクストステップは何か？「アカウントがクローズからクローズドウォンに移行するまで待つ」以外であれば、「Why Now」の質問を参照してください。
     • 具体的なネクストステップの例は、最も近いコンタクトに「これを来月クローズしたら、あなたにとって少しでも楽になりますか？」と尋ねることです。

3. アカウントの Red/Green ディスカッションが完了したら、ASM は、ディスカッションとアカウントエグゼクティブが取る即時のネクストステップを反映するため、商談の「manager notes」セクションにメモを入力します。

4. 翌日、閾値を超えるすべてのアカウントに対して同じプロセスを繰り返します。

Red / Green の結果

コミットする予測を達成し、AE のためのより良い営業スキルと ASM のためのより良いコーチングスキルを構築します。 - 構築する必要のある理想的なスキルは: - お客様がクローズしたい理想的なタイムラインを知ることに関するコンセプトと実行を理解すること。 - ペインを特定し、GitLab に切り替えないことの負の影響と、GitLab に切り替えることによって実現されるポジティブなビジネス成果の両方をお客様に理解させること。 - 重大度またはお客様がプロジェクトにリソースを充てる能力に基づいて、お客様との時間制約のある相互成功計画を構築すること。

Red / Green Lookback プロセス

翌期間の最初の R/G ミーティングで、リーダーシップチームは前期間の実際のクローズドウォンと最終 R/G コミットメントを提出します。チームは、各自がどこで終わったかの理由と、コミットメントからのばらつきにつながった項目を特定するために議論します。

SMB Account Executives

SMB Account Executives「SMB AEs」は、SMB見込み客およびお客様に対する Account Executives およびとして、GitLab の顔として行動します。彼らは、従業員 1 名から 99 名を雇用する企業の主な連絡先です。

SMB の役割

SMB Account Executives は、以下のポッドポジションのいずれかに指定されます:

1. First Order
2. Pooled
3. Expand
4. Named

First Order の SMB Account Executives は、見込み客が最初の購入プロセスを通じて評価するのを支援します。アカウントに応じて、他の 3 つの役割は、リニューアルおよび拡大のディスカッションのためのお客様の主な連絡先となります。集合的に、チームは、テリトリー内の新規ビジネスに取り組むだけでなく、新規および既存のお客様向けのカスタマージャーニーを処理する責任があります。

AMER SMB Pooled Account Executives は、GitLab を使い始めた 1 日目の企業から、1 日目から GitLab を使用している企業まで、SMB お客様のサブセットを管理することを担当します。Pooled AEs は「プール型」のアカウント所有モデルで集合的に取り組みます。つまり、お客様はチームレベルで整列され、すべての AE がお手伝いできるよう装備されています。Pooled AEs はお客様と協力して製品を評価し、ニーズに基づいて GitLab との成功するリニューアルを保証する推奨を行います。

詳細については、以下およびSMB ハンドブックページをお読みください。

フォローおよびブックマークすべき重要な Salesforce レポート

• SMB AMER Required 7
• SMB APAC/EMEA Required 7
• SMB APAC/EMEA 1:1 Dashboard

新規ビジネス

• Commercial SDR チームからの Initial Qualification Meetings IQM’sに取り組む
• SAO Criteriaに従って Sales Accepted Opportunities を承認
• 商談承認後、トライアル評価中の見込み客を育成・支援
• Webdirect への誘導または Sales Order Process のサポート

カスタマージャーニー

• Inbound Queue Management
• Licensing/Subscription Management
• Troubleshooting Resource for Licensing/Subscription Management
• Quotes / Sales Order Processing
• Customer Health Check Process
• Gainsight Data in SFDC Definitions

Inbound Queue Management

Zendesk: support.gitlab.com 経由で受信する依頼の管理

SMB チームの Zendesk チケット対応の 目標と焦点 は、アップセルとリニューアルを支援することです

タイムゾーン内（WIP）、Support チームはUpgrades, Renewals, AR (refunds)キューに入ってくるすべての ZD チケットをリードする責任があります。営業時間外には、SMB チームはタイムゾーン中に違反するチケットをトリアージして処理します。

Support はキューに来るすべての依頼をリードし、以下の場合にのみ営業所有者に転送します:

• お客様からの Net ARR に影響を与えるイベントがある -OR-
• 営業マネージャーの承認が必要なクレジットまたはその他の依頼がある

Salesforce パイプラインアクティビティ

Salesforce での商談管理

• 新しい商談に取り組む前に、必ずアカウントのセグメンテーションが「SMB」であり、その会社の従業員数が 100 人未満であることを、datafox 情報を見て、LinkedIn で確認してダブルチェックします（特に AMER 以外）
• 毎日 Next Steps に自分自身を向けて、その日を優先順位付けし、整理する方法を知ってください。その日のネクストステップに取り組む方法に関する推奨事項:

1. ステージで並べ替え、最高優先度のステージを上に配置
2. ステージ、金額、クローズ日で最初に取り組む商談を優先順位付け
3. 「Next Steps」「Next Step Date」「Next Steps Owner」が、商談をパイプライン通して移動する方法を導くアクション可能で情報的な情報で最新であることを確認
4. アクションが必要な潜在的な将来の商談が 30 日以上先である場合、これがネクストステップフィールドに詳細に記載されていることを確認
5. Discovery から Awaiting Signature までのステージの商談が更新されたら、Pending Acceptance の作業を始めます。同じ基準で優先順位付けを続けます。

パイプライン生成

• 直属の経営陣との週次のコミュニケーションでパイプラインの健全性をレビューし、必要に応じてリアルタイムで記録を更新します。常にパイプラインの乗数を把握し、成功する月と四半期のためにより多くのパイプラインを作成する必要があるかどうかを知るべきです。チームの Pipeline Generation チェックリストドキュメントと、アクティビティを最新に保つことに関連する関連する SFDC レポートを参照してください。

Commercial Sales のステージのアクティビティと出口基準

• パイプライン管理は、予測可能でスケーラブルな収益達成の鍵であり、単に目標を達成することと、目標を超えることの違いを生むことができます。適切な営業パイプライン管理は、時間を正しく割り当て、ディール速度を増加させ、正確な予測実践を通じてディール全体のボリューム、サイズ、収益を増加させるのに役立ちます。
• よく管理された営業パイプラインには、ディールをディスカバリーからクローズドウォンに（または素早く認定外に）持ち込むためのロードマップとして機能する、定義されたアクティビティと出口基準を含む明確なプロセスが必要です。次のプロセスは Commercial Sales チームに固有のもので、クリーンなパイプラインと正確な予測を確保します。
• Detailed Exit Stage Criteria Google Sheet
• Exit Criteria at a Glance

• 詳細についてはCommercial Sales Opportunity Stages ハンドブックページをお読みください。

Salesforce での Web Direct Oppty 管理

• ご自身のテリトリーのすべての CFQ「current fiscal quarter」 Web Direct 購入のレポートビュー「SMB_Web Directs CFQ_name」を見つけてください:

1. アカウントの下にリストされている商談を見ることで、重複していた可能性のあるオープン商談がないか確認します
2. 重複でなければ、商談のメインコンタクトをアウトリーチシーケンス「SMB_Web Direct Outreach」に配置します - by: Madeline Hennessy
3. 商談と会社に応じて、個人的なアウトリーチが好ましい場合、活動をログし、フォローアップするためのネクストステップ日付を持つ必要があります

Licensing/Subscription Management

注: システムへのアクセスが必要な場合は、Access Request を開いてください

GitLab Trials & Subscription Management

• ユーザー、グループ、サブスクリプションへの変更を提供するため、CustomersDotにアクセスします。

Licensing & Subscription Management のトラブルシューティングおよびハウツーリソース

ライセンスやサブスクリプションに関する問題を扱う方法の詳細な手順は、これらの手順とリソースで見つけられます。

Quotes | Sales Order Processing

sales order processingの詳細は Business Ops ハンドブックセクションにあります。

Mid Market Account Executive

Midmarket Account Executives は、現在従業員 100 人から 1,999 人を雇用する企業と協力する、ミッドマーケットとして定義される空間内の GitLab 見込み客および既存のお客様間の主な連絡先です。これらの GitLab チームメンバーは、特定のビジネス成果を達成するため、GitLab との旅でアドバイスする小規模なアジャイル組織内の急成長中の小規模なチームから複雑なエンタープライズプロジェクトまで、プロジェクトサイズの範囲を管理します。

Mid-Market AEs はビジネス開発チームと営業マネジメントと密接に協力し、大きな商談額範囲にわたる広範なビジネスを管理し、クライアントの期待を超えることに焦点を当てます。

Mid Market の役割

1. New Logo AE: これらの AE は、現在 GitLab のお客様ではないBase Accountsに取り組みます。お客様が最初の契約に署名したら、お客様のサイズに応じて、SMB、MM、ENT セグメントに移行されます。
2. MM Key Accounts Named AE (MMKAN): これらの AE は、高消費（高 CARR）であると判断された、または高消費の可能性（高 LAM）を持つと判断された現在のお客様に取り組みます。MMKAN AE が成功するには、指名されたアカウントリストの標準的な拡大率を超えて、アカウントを拡大する必要があります。各 MMKAN AE の指名リストは、MMKAFO AE が新しい高潜在能力のお客様を獲得するに従って、会計年度を通じて成長します。
3. MM Territory AE: これらの AE は、New Logo AE または MM Key Account 名義 AE となることが審査されていないアカウントの地理的リージョンに取り組みます。この役割は見込み客と現在のアカウントの両方に売り込みます。

「MM Key Accounts」は、MM Key Accounts First Order と MM Key Accounts Named を集合的に指すために使用できます。MM Key Accounts は、より高いLAMと潜在的 LAM を持つ MM アカウントのサブセットです。

中核的な責任

• アカウントセットを所有 - 計画を構築・実行。
• ビジネスブックを管理: 新規ビジネス、拡大、リニューアル。
• インバウンド認定商談のクロージャへの進行のため、Sales Development チャネルと協力。
• アウトバウンドキャンペーンの実行。

新規ビジネス

• SDR チームからの Initial Qualification Meetings IQM’sに取り組む
• SAO Criteriaに従って Sales Accepted Opportunities を承認
• 商談承認後、トライアル評価中の見込み客を育成・支援
• Webdirect への誘導または Sales Order Process のサポート

マーケティング用のターゲットアカウントの選択

• Datafox または Sales Navigator にログイン
• テリトリー条件を入力
• アカウントのリストを確立し、会社の総従業員数で並べ替え
• DevOps などのキーワードで検索
• 各アカウントを調査し、実際にあなたのものかどうかを確認
• エンジニアまたはテクノロジー専門家である各従業員を調査
• その会社名をリストに追加
• このプロセスを通じて十分な企業がない場合は、以下を続けます:
• Datafox で収益と業種の交差を見る
• SFDC のアカウントを見て、CE ユーザーかどうかを確認
• Datafox を使用している場合はシグナルでフィルタリング
• 最近の資金調達発表があったかどうかを評価
• 選択したら、会社名、市、郵便番号をシートに追加

カスタマージャーニー

• Inbound Queue Management
• Licensing/Subscription Management
• Troubleshooting Resource for Licensing/Subscription Management
• Quotes / Sales Order Processing
• Customer Health Check Process
• Gainsight Data in SFDC Definitions

Commercial Sales 向けアカウント所有のルールオブエンゲージメント 2022-09-22 更新

Commercial Sales チームは、Account Ownership Rules of Engagementに従います。 このセクションでは、ROEに従う方法をステップバイステップで明確にしています。

従うプロセス

アカウントは次の 2 つのカテゴリーに整理されます:

1. 会計年度の 2 月 1 日より前のお客様だったアカウント
2. 会計年度の 2 月 1 日以降にお客様になったアカウント

会計年度の 2 月 1 日より前のお客様になったアカウントは、このプロセスに従います

アカウントを所有する Account Executive には、2 月 1 日より前にアカウントの従業員数を認定する責任があります。 2 月 1 日以前またはその時点で従業員数が 100 人未満のアカウントは、その会計年度は SMB が所有します 2 月 1 日以前またはその時点で従業員数が 100 人以上のアカウントは、その会計年度は Mid Market が所有します

• Account Executive として、アカウントを認定して、従業員数または企業住所によるルールオブエンゲージメントが不明な場合、レビューしているデータをスクリーンショットで撮り、アカウントの chatter に投稿し、Account Rank Notes を編集してください。@ メンションすることで、Area Sales Manager にリサーチが完了した旨をタグ付けして、さらなるレビューを依頼してください。ASM が Account Executive から提供されたデータをレビューし、独自の調査を行った後もルールオブエンゲージメントが不明な場合、調査をスクリーンショットで撮り、アカウントの chatter に投稿し、@ メンションすることで Regional Director をレビューにタグ付けする必要があります。最後に、Regional Director が提供されたデータをレビューし、独自の調査を行った後もルールオブエンゲージメントが不明な場合、調査をスクリーンショットで撮り、アカウントの chatter に投稿し、@ メンションすることで Regional Vice President をレビューと最終決定にタグ付けする必要があります。Commercial アカウントおよび商談所有のすべての最終決定は、Commercial Division の Regional Vice President の単独裁量にあります。

会計年度の 2 月 1 日以降にお客様になったアカウント

アカウントは次のカテゴリーに分けられます

1. Sales Assisted First Order
2. Web Direct First Order

Sales Assisted First Orders では、見込み客と初期ディスカバリーを行う Account Executive に、アカウントの従業員数と本社所在地を調査・認定する責任があります。 アカウントの従業員数が 100 人未満の場合、そのアカウントは会計年度の残りの期間 SMB によって管理されます アカウントの従業員数が 100 人以上の場合、そのアカウントは会計年度の残りの期間 Mid Market によって管理されます アカウントの従業員数が 500 人を超える、または 100 LAM dev 以上の場合、適切なリードルーティングについては、FY ‘23 の MMKAFO と Mid-Market Territory 間のルールオブエンゲージメントをご覧ください

Web Direct First Orders では、データを充実させるために使用されるツールに基づいて、システムが捕捉する内容と実際の従業員数の差異の程度があるかもしれないことを理解しています。Web Direct First Order 後に正しい従業員数を特定し、従業員数が「完全に間違っていない」ことを確認することは、First Order を所有する Account Executive の責任です。「完全に間違っている」は、自動化により初期割当時に割り当てられるアカウント、つまり最初のトランザクションでチームメンバーがレビューしなかったアカウントにのみ使用されます。

完全に間違っているとは、以下のように定義されます 従業員数が 80 人未満の Mid Market 所有のアカウント 従業員数が 120 人以上の SMB 所有のアカウント

アカウントが完全に間違っている場合、アカウント所有者は、@sales-support と chatter で、First Order とアカウントを正しいセグメントに再割当する責任があります。

アカウントが完全に間違っていないものの、セグメントラインの上または下（それぞれ）にある場合、アカウント所有者は、@sales-support と chatter で、翌会計年度の初めに適切なセグメントに移動するアカウントをフラグ付けする責任があります。

調査されていない、または間違ったセグメントに割り当てられていると特定されないすべてのアカウントは、再割当されます。

AE がこれを認定して保持する場合、これは懲戒処分につながる可能性があります。

認定プロセスの一環として、お客様を最善にサポートできるよう、会社本社の所在地と従業員数を認定することが期待されます。お客様体験を危険にさらすような方法で所在地と従業員数を認定することは受け入れられません。不確かな場合は、お客様を巻き込む前にデータをレビューするためマネージャーを chatter でタグ付けしてください。

FY ‘23 の MMKAFO と Mid-Market Territory 間のルールオブエンゲージメント

会計年度 2023 年のアカウント移動

2022 年 2 月 24 日時点で SalesForce.com にあるすべてのアカウントについて、Mid-Market Key Accounts First Order チームは、次のすべてのアカウントを所有します:

1. Mid-Market NORAM または EMEA にセグメント化されている
2. SalesForce で「First Order Available」とマークされている AND
3. SFDC の Account Demographics の「Account Demographic Max Family Employees」フィールドで 500 人以上のフルタイム従業員数がマークされている。 OR
4. LAM Dev Count Field で測定された潜在的ユーザー数が 100 ユーザー以上ある。

混乱を避けるため、ロジックは[1 AND 2 AND (3 OR 4)]です。

注: AE がデータソースの従業員数または潜在的ユーザー数が正確でないと疑う場合、ディスカバリーフェーズ中に従業員数と潜在的ユーザー数を発見することが AE の責任です。アカウントがいずれかのテリトリーまたは First Order に属することが特定され、もう一方の当事者が適切なデューデリジェンスを行わずにリードに取り組み続ける場合、アカウントは適切な当事者に再割当されます。

2022 年 2 月 24 日以降の SalesForce.com への新規アカウント

1. SalesForce.com にアカウントがまだ存在しないすべてのインバウンドMQL について、そのリードとアカウントのルーティングは、従業員数のみに基づきます。
   • アカウントの従業員数が 500 人以上の場合、MMKAFO チームにルーティングされます
   • アカウントの従業員数が 500 人未満の場合、Mid-Market Territory チームにルーティングされます
2. MMKAFO AEs は、Mid Market Key Accounts の定義基準に合致する SalesForce.com にまだないアカウントにアウトバウンドできます:
   • 500 人以上の従業員、または LinkedIn Engineering + IT スタッフ数で定義される 100 潜在的ユーザーを持つ Mid-Market アカウント。
3. MMKAFO AEs は上記の基準を満たすアウトバウンドアカウントを SFDC で作成し、Sales Operations に自分の名前にアカウントを移動するよう求めることができます。
   • 注: AE がアカウントを重複排除するために、当該アカウントに取り組むために要求していることが判明した場合、懲戒処分が取られます。

会計年度 2023 年中のアカウント移動

1. MMKAFO AE が、First Order にセグメント化された 500 人未満の従業員数のアカウントが実際には 100 人未満の潜在的ユーザーを持つことをディスカバリーで発見した場合、すぐにアカウントを Territory に移動するよう求めるべきです。
2. 「First Order Available」のアカウントが Territory にセグメント化されており、Territory AE がアカウントが実際には 500 人以上の従業員を持つことをディスカバリーで発見した場合、すぐにアカウントを First Order に移動するよう求めるべきです。
3. システムの新規アカウントの自動化は、500 人未満の従業員でも 100 人以上の潜在的ユーザーを持つアカウントが、四半期切り替え時にアクティビティがない限り、Territory にルーティングされ、そこに残されることを意味します。
4. AE が意図的にルール 1 または 2 を会計年度内に 2 回以上無視していることが判明した場合、懲戒処分が取られる可能性があります。

Co-Selling

Co-selling は、Account Executive とその Area Sales Manager の両方の責任で、共にセールスコールに参加します。これは、最高のクライアント／見込み客体験を確保し、そのアカウント内で最大の可能性を共同で見つけることを目的としています。 Area Sales Managers は、ローリング 7 日間で最低 5 回の co-selling コールをログすることが期待されており、ローリング 7 日間で 10～12 コールにより近く達成することを目指しています。

あなたの ASM と協業する際の Co-Selling の役割

• Primary Seller: この役割をメインのピッチパーソンと考えてください。会話を導き、デッキを共有し、ライブノートを取り、価値を追加し、決定したアジェンダに沿って進める役割です。
• Co-Seller: この個人は Salesforce の生のノート、時間管理、コメントの掘り下げを担当し、追加情報を見つけるべき領域を特定します。Co-pilot は、Pilot がペインを捕捉せずに進む際に、ペインのレベルと量を掘り下げる必要があります。 追加情報は、こちらのリインフォースメントモジュールを参照してください

Channel Partner との協業

GitLab パートナーネットワークは、Commercial Sales が提供するお客様の販売とサービスの能力を拡張するため、GitLab Account Executives と一緒に働く準備ができています。Channel のこのアプローチは、Partner Co-selling と呼ばれ、Partners との協業には、「誰がいつ何をするか」を確立する、シンプルで明確な相互お客様商談計画を構築することが含まれます。

パートナーと協業する主なメリットは何ですか？

• AE がパートナーと協業してお客様の価値と Net ARR を増加
• パートナーセールスとサービスの能力および GitLab トレーニング済みパートナー AE、SA、エンジニア、そしてしばしば GitLab のチャネルマネージャーがコーディネート／支援することによる、拡張されたリーチと能力
• 新しいお客様ロゴへの加速されたリーチ「Land」: パートナーは、顧客ベースをマイニングすることで GitLab に新しいロゴ商談をもたらし始めています。多くの場合、パートナーはすでにお客様との「信頼できるパートナーステータス」を持っており、これも新規ロゴエンゲージメントの加速に役立ちます。
• お客様の「Expand」成功の増加: 多くの場合、パートナーは、お客様が GitLab 技術投資から最大の価値を得て、ユーザーの成長と共にステージアドバンスを推進するのを確実にするため、求められる重要なサービスを販売・提供します。
• デプロイメントおよび関連サービス: より速いデリバリーと能力の増加のため、AE はこれらのサービス、CSM ライクのカスタマーサクセスサービスを販売・デリバリーするためにパートナーに頼っています。
• ディストリビューター経由の OPEN パートナーの場合、見積もりから注文プロセスに関連する管理ステップが劇的に削減されます。

AE はお客様の価値と Net ARR を増加させるためにどのようにパートナーと協業しますか？

GitLab には、GitLab トレーニング済みの営業および技術リソースを良好にカバーする成熟したパートナーネットワークがあります。AE がパートナーを含むお客様と協業する方法はいくつかあります。

• Approved Partner GitLab Deal Registrations これらがテリトリーで受信されるにつれて、多くの場合*、GitLab チャネルチームメンバーから連絡があり、パートナーと共有するシンプルなパートナー co-selling 計画を作成するための共同販売キックオフコールを手配します。GitLab Channel Managers はすべての OPEN Partners をプロアクティブに管理しているわけではありません。AE は、channel-sales または利用可能なコンタクトを Slack することで、Deal Registration のための Channel Manager サポートを常にリクエストできます。
• 1. 「パートナー SA がこのお客様要求の SA タスクを実行できる」と考える場合、または 2. AE に「パートナーサービスのアタッチエンゲージメント」から利益を得られるお客様がいる場合、関連するアカウントまたは商談へのリンク付きで、Slack で#channel-salesに Partner Engagement Request をすぐに送ってください。チャネルチームのメンバーが、依頼についてさらに学ぶためにすぐに連絡し、当面のタスクを迅速かつ適切に実行する事前認定済みのパートナーとあなたをつなぎ、その間も最新情報を提供します。
• AE はパートナーと GitLab Channel Manager のアラインメントとサポートを得て、共同商談／お客様追求の計画と実行をリードすべきです。計画はタスクとアクションアイテムで SFDC で追跡されるべきです。パートナーは、（AE または Channel Mgr を介して）割り当てられたタスクのメール確認を常に受け取るべきです。
• Channel Managers は次の方法で AE と協業します:
  • 新しい Deal Registration が AE のパイプラインに到着した時
  • AE が選択した共同のお客様の成功モーション用に、AE が協業する 2～3 のパートナーをレビュー:
    • Channel Manager はこのコール中に可能性を提示します
    • パートナーと協業する 2 つの例が、この LevelUp で取り上げられています
    • AE は、どのパートナー活動が自分のお客様のどれにとって最適かについて優先順位を付けて考えを共有すべきです
• ディストリビューション経由の Open パートナーの場合、商談の準備ができたら、AE は商談へのリンクと共に[email protected]にメールで、見積もりから注文サポートを依頼します（chatter alias は近日公開予定）

Channel Partners との協業について詳しく学ぶリソースは？

• AE の初めての場合、提供されている利用可能なトレーニングを視聴することをお勧めします。この Levelup 動画はChannel Partner ランドスケープの基本的な理解から始まります。
• 共同販売の成功についてさらに学ぶ AE 専用のMaximizing Value of Partners in a Dealの LevelUp 動画。
• パートナー共同販売のベストプラクティス、パートナーが AE の R7 と Command Plan の重要な要素の構築を支援する方法などの詳細は、Channel Sales Handbookで学べます。
• ご質問やサポートの依頼については、Slack #channel-salesまたは Channel Account Manager に連絡してください。チャネルは、共同販売の成功を様々な方法で支援するためにここにいるチャネルチームの複数のメンバーによって緊密に監視されています。
• GitLab トレーニング済みの OPEN および SELECT チャネルパートナーのリスト
• Channel Partner Finder **こちら

New Logo Team

New Logo Team は、MM および ENT アカウントでファーストオーダーディールをクローズすることに焦点を当てた、GitLab の High Velocity Sales & New Logo 組織内の専門化された営業チームです。 最初のトランザクションが New Logo チームによってクローズされた後、New Logo AEs はハンドオーバープロセスを開始する責任があります。以下は New Logo チームと Mid-Market Key Account Named チームの責任です。

アカウントを Mid-Market または Enterprise に渡すタイミング New Logo AE は、アカウントが有料のお客様になるまでアカウントを所有します。これが発生したら、アカウントはそれぞれのセグメント（SMB、MM、ENT）に卒業します。

ハンドオーバープロセス

New Logo AE の責任

役割と責任の詳細については、New Logo Team Playbookを参照してください。

1. 商談が「Closed-Won」とマークされていることを確認します。
2. お客様が動作するライセンスを持っていることを確認します。
3. 次の項目を詳細に記載したアクティビティを（命名規則: [NL AE NAME] NL Account Summary for Handoff）アカウントレベルで記録します:
   • お客様が GitLab を選択した理由（ユースケース）
   • 今後 12 か月で販売予定の NetARR
   • 次回購入の推定タイムフレーム
   • b および c がそうであると考える理由
4. 名指しまたはテリトリー AE、CSM（既知の場合）、お客様と協力してハンドオフコールを設定します
   • New Logo AE はこのコールのスケジュールをリードする必要があります
     • 注: NL Rep と Named または Territory AE が、メール紹介で十分であることを事前に合意した場合、チームはハンドオフコールをバイパスできます。
5. 初期金額 AND 次の商談の可能性の合計 NetARR が$10,000 未満、または継承 AE が同意した場合、ハンドオフメールが使用できます。
6. カスタムデッキなどのすべての材料が、Customers & Prospectsドライブの専用のお客様サブフォルダに追加されていることを確認します。
   • お客様アカウント名の最初の文字に基づき、A-Z とラベル付けされたフォルダの 1 つにサブフォルダを作成します。（例: Acme Inc.は「A」とラベル付けされたフォルダに入ります）
   • お客様向けまたはお客様に関連する内部ドキュメントをすべてフォルダに追加します。これにより、アカウントチーム全体が関連コンテンツすべてを表示できるようになります。
7. 事前のエンゲージメントがない Web Directs の場合: FO AE が何もエンゲージしていないため、ハンドオーバーはありません。

Digital Sales Room

Digital Sales Room は、AE がキュレーションされたコンテンツを共有し、見込み客と共同作業し、営業プロセス全体でバイヤーエンゲージメントを追跡できる、セキュアでパーソナライズされた Web ページです。すべての営業資料、プレゼンテーション、コミュニケーションを 1 つのブランドスペースに集中させ、散在するメールを排除し、シームレスなバイヤー体験を作成します。

1. Digital Rooms - Highspot Overview Training
2. Digital Rooms 101
3. Engage Buyers with Digial Rooms

Named/Territory AE の責任

1. New Logo AE、CSM、お客様と協力して、ハンドオフコール（またはメール）をスケジュールします。
   • 目標は、初回クローズの 1 週間以内にお客様と双方向のコミュニケーションを取ることです。
   • メールを使用する場合、Named または Territory AE は、新しい主要連絡先として自己紹介するために、できるだけ早く返信する必要があります
2. FO AE が記録したアクティビティをアカウントアクティビティで確認します。
3. 上記のメモに基づき、最初のリニューアル日より前にスケジュールされている場合、成長商談を開きます
4. (ii)のタグ付けされたすべてのメモ、カスタムピッチデッキ、command plan を通読し、アカウントとその可能性を理解します。
5. 戦略的アカウントの CSM を巻き込み、できるだけ早く彼らを参加させます
6. Web Directs の場合: 新しいお客様に連絡を取るのは Named/Territory AE の責任です。

Base から Named/Territory へのアカウント移動プロセス

New Logo Team のアカウント卒業について追加の情報は、Go-To-Market Rules of Engagementページを参照してください。

初期のディールが完了する前に Named または Territory AE を含めることを検討するタイミング

1. GitLab、見込み客、またはその両方にとって、最初のディールがクローズする前に Named または Territory AE を紹介することが有益な状況があります。これらの状況には、これらに限定されませんが、次のものが含まれます:
   • 戦略的アカウントに追加のサポートが必要な場合。
   • 最初の契約が署名される前に CSM が関与する必要がある場合。
   • オンサイトミーティングが必要で、Named/Territory AE がそれを処理するのにより適切な地理的位置にいる場合。
   • お客様が、最初の契約が署名された後にアカウントを担当する人物を紹介するように求めた場合。

この検討を行う際に従うべき一般的なガイドライン

1. 紹介を契約署名前に行うべきかどうかを決定するのは、常に New Logo AE の決定ですが、紹介を行う場合に従うべきいくつかの一般的なベストプラクティスがあります。
   • 理想的には、契約前紹介は、これがスケールの問題にならないよう、より高い LAM アカウントに制限されるべきです。

     • 99 LAMDev は Key Accounts ->49 LAMDev は Territory Accounts

   • Named/Territory AEs の時間を無駄にしないため、紹介はクローズの可能性が非常に高い場合にのみ行われるべきです。したがって、商談がステージ 5 または 6にあるときに紹介が行われるのが最適です。
2. Named/Territory AEs と New Logo AEs は、契約前の紹介が意味のあるアカウントを特定するため、頻繁に（平均で 2 週間に 1 回）会うべきです。

Commercial Leadership Development パイロットプログラム

このパイロットプログラムは、営業管理についてさらに学び、基本的なリーダーシップスキルを構築することに関心のある Commercial チームメンバーを対象としています。

このプログラムは、チームメンバーに次のことを提供するよう設計されています:

1. リーダーシップトピックへの露出と、基本的なリーダーシップスキルの発展
2. 自分のチームに修正・適用できるリーダーシップフレームワーク
3. 営業リーダーの期待と、個人貢献者の役割との違いの体験
4. ピアとクロスファンクショナルなステークホルダーとのネットワーキングの機会

プログラムは合計8週間実施されます。各週で新しいトピックに焦点を当てます。パイロットプログラムの提案されたトピックを週別に見る:

参加者への期待

• 時間コミットメント: 四半期中、同期ミーティングと非同期作業の間に専念する時間は合計約 40 時間。

GitLab Commercial 部門は、すべてのチームメンバーが GitLab の CREDIT バリューと調和した、最高レベルの道徳的および倫理的行動を遵守することを期待しています。GitLab のバリューと矛盾する活動への関与または促進は受け入れられません。登録するチームメンバーは、GitLab で働くことの記載および暗示されたバリューを遵守することが期待されます。これらの項目は次を含みますがそれらに限定されません:

• 他のチームメンバーとの良好な共同作業
• ポジティブな意図を仮定すること
• チームメンバーの現在のポジションで結果を提供し続けること
• クラスのディスカッション中にインクルーシブであること、代替的な見解を正解または不正解ではなく代替として受け入れて、他のチームメンバーの帰属意識を育む

さらに、プログラムに参加する場合、チームメンバーはミーティングと学習活動に参加するためのベストエフォートを行うことが私たちの期待です。参加できない場合、参加者はできるだけ早くファシリテーターに通知する必要があります。参加者がコースに不在の場合、彼らはプログラムから削除されます。

誰が参加できますか？ 良好なパフォーマンス状態（現在パフォーマンスや行動上の警告を受けていない）の、現在の役割で 3 か月以上いる Commercial チームメンバー誰でも。この最初のコホートには 12 人の参加者を選定します。このプログラムは、Commercial チームメンバーにスキルを伸ばす機会を継続的に与えるため、最初のパイロットプログラム後も継続することが意図されています。

その他の関連ページ

• Commercial Sales - Customer Success
• Territories

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