Content last updated 2026-06-30

Ecosystem Operations

このページは Ecosystem Operations チームのページとして、標準的なチャンネルレポートのリンクとパートナー機会の管理の詳細を提供します。

Ecosystem Operations ページへようこそ

ビジョン

ワールドクラスのパートナービジネスを構築、運営し、それに助言すること。

ミッション

GitLab チーム、パートナー、顧客のニーズに耳を傾け、革新的で合理化されたプロセス、ツール、リソースで応えることで、GitLab と私たちのパートナーのためにスケーラブルで高収益なビジネスを運営します。

主要な信条

効率性と生産性: パートナーのシステム、プロセス、ワークフローを合理化し、取引のしやすさを改善するとともに、GitLab とパートナーの相互の収益性とポジティブな体験を推進します。

スケーラビリティ: 私たちの市場進出の方法の基盤となり、成長し進化するパートナービジネスを支えられるよう適応可能な、信頼性が高く効果的な運用プラクティスを構築、展開、管理します。

アドバイザリー: GitLab の社内チームとパートナーチームにとって信頼される専門家として、日々の運用サポートを提供し、私たちのパートナーモデルに関するベストプラクティスとビジネス上の意思決定を導きます。

お問い合わせ方法

お問い合わせには #global-ecosystem-programs-ops Slack チャンネルをご利用いただけます。Ecosystem Operations チームと Ecosystem Programs チームの双方がこの Slack チャンネルを監視しています。問題の報告、提案、変更リクエストがある場合は、運用に関する問題については Ecosystem Operations Issue Board、プログラムに関する問題については Channel Team’s Issue Board で Issue をオープンしてください。

Ecosystem Operations Issue ボード

Ecosystem Operations Issue Board では、各列がリクエストの種類（機能リクエスト、アライアンス、データとレポーティングなど）を表します。Ecosystem Operations ボードにリクエストを送信すると、チームが Issue を割り当て、対応するタグを追加します。Ecosystem Operations ボードでは、オープンな Issue のステータスを示すために、Issue に進捗タグも使用しています。各 Issue はメモと進捗タグで定期的に更新されるため、ステータスの確認のためにチームに連絡する前に確認してください。

Ecosystem Operations で Issue をオープンするには、New Issue を選択してください。

Issue テンプレート

Issue テンプレートの活用: クロスファンクショナルなチームからのリクエストを標準的な方法で受け付け、問題を診断するための適切な情報を提供できるよう ユーザーを案内 する取り組みの一環として、Ecosystem Operations チームは Issue テンプレートを作成しました。

始め方

1. 新しい Issue を作成する

新しい Issue を作成すると、「Choose a template」というオプションが表示されます。

2. テンプレートを選択する

テンプレートを選択すると、入力できる状態でテンプレートの内容が説明ボックスに反映されます。

カスタムのレポーティングリクエストには Ad hoc Reporting を選択します。
データの一括更新には Data Upload Request を選択します。
現在のシステムへの機能拡張をリクエストするには Feature Request を選択します。
合併・買収に関連するパートナーアカウントの変更、重複アカウントの統合やアカウント階層への移動、またはパートナーアカウント名の変更をリクエストする場合は、Partner M&A and Name Changes を選択します。
Ecosystem Operations が管理する特定の手順/プロセスやハンドブックの更新に関する編集やレビューをリクエストするには、特にページの MR を送信する前にさらなる議論が必要な場合に Procedures & HB Updates を選択します。
パートナーイベント、MOU、ファンデッドヘッド、SPIFF などに対する MDF 以外 の資金提供をリクエストするには Partner Funding Request を選択します。

3. 送信する前に

選択した Issue テンプレートを入力するためのプロンプトに従っていること、および Issue が 未割り当て であることを確認してください。私たちのチームがチームの余力に基づいて Issue を割り当てます。

Issue テンプレートの動画

外部パートナーのサポートとコミュニケーション

パートナー関連のリクエストに関するヘルプでパートナーやその他の外部ステークホルダーを含める場合は、[email protected] にメールしてください。Ecosystem Operations のチームメンバーが、すべてのタイムゾーンで一日を通してキューとメールの受信トレイを監視しています。

Salesforce で Ecosystem Operations に連絡する

2024 年 11 月 25 日をもって、chatter ハンドル @Partner Operations は廃止されました。Ecosystem Operations チームには、Salesforce で社内サポートをリクエストすることで連絡できます。新しいケースをオープンする前に、引き続き詳細な情報については各ハンドブックを参照してください。

Salesforce 内でアシスタンスのケースを作成できる項目の一般的なリストは以下のとおりです。

Deal Registration

一般的な質問
承認できない/エラーメッセージ
顧客アカウントの更新
Reg を Closed Opportunity にリンクする
リンクされた顧客アカウントの従業員数/セグメントの更新
30 日を超える延長リクエスト
Reg を別の Open Opportunity にリンクする

Partner Account

トレーニングと認定
パートナープログラムの管理
パートナーへの支払い
販売後のサポート
アカウントオーナーの更新
パートナーアカウントの統合、名称変更、買収

Opportunities

チャンネルパートナーの見積もりリクエスト
見積もりから注文へ/値引き
SQS/Opp 分割に関する質問
CPPO、MCPO、または DSOR
Reg を Closed Opportunity にリンクする

Labra Referral

一般的な質問

Slack でパートナーチームとコミュニケーションを取る

組織のさまざまなニーズに対応するため、複数の Slack チャンネルがあります。以下は、最も一般的なチャンネルのリストと、その用途、対象となるオーディエンス、投稿権限です。情報を投稿し質問を適切なチャンネルにしていることを確認するため、このリストを頻繁に参照してください。

Slack チャンネル	説明	トピック	オーディエンス	投稿権限
global-ecosystem-programs-ops	エコシステムプログラムと運用に関する質問やコメント	https://handbook.gitlab.com/handbook/resellers/ および https://handbook.gitlab.com/handbook/sales/field-operations/channel-operations/	全員	全員
global-ecosystem-sales	機会、パートナーとのつながり、フィールドエンゲージメント、その他のエコシステムセールスに関する質問やコメント		全員	全員
channels-emea	EMEA チャンネルチームとステークホルダーが協力するためのチャンネル		全員	全員
channels-amer	AMER チャンネルチームとステークホルダーが協力できるチャンネル		全員	全員
pub-sec-channels	Pubsec チャンネルチームとステークホルダーが協力するためのチャンネル		全員	全員
apac_partners	APAC チャンネルチームとステークホルダーが協力できるチャンネル		全員	全員
channel-services	チャンネルサービスプログラム、イネーブルメント、フィールドエンゲージメントに関する質問やコメント		全員	全員
#cloud-aws および #cloud-gcp	アライアンスチームと協力するためのチャンネル	https://handbook.gitlab.com/handbook/alliances/	全員	全員

標準的なチャンネルプラクティス

GitLab のチャンネルパートナープログラムに関する詳細情報は、Channel Partner Handbook を参照してください。パートナーは、GitLab の製品やサービスを取引するには、Authorized GitLab Partner であり かつセールス認定を 1 つ取得済みである 必要があります。認可を得るには、パートナーは締結済みの契約を持ち、GitLab Partner Program の要件を満たす必要があります。GitLab partner program team によりケースバイケースで特別に承認された場合を除き、良好な状態にある GitLab パートナーのみが GitLab の製品とサービスを販売できます。パートナーは認可を得るためにサインアップする必要があります。

エコシステムプログラム

GitLab のエコシステムプログラムは、Salesforce の Account と Opportunity のレベルにある Partner Engagement record を通じて追跡します。これにより、フィールドチームとパートナーは顧客ライフサイクル全体のパートナー主導のエンゲージメントを 1 か所で記録、追跡、測定でき、スプレッドシートを減らしてオフラインでの調整をなくせます。

新しいプログラムは、システム Issue を提出することで、毎回ゼロから再構築せずに同じインフラストラクチャへ追加できます。

CAPS：パートナーサービスを通じた顧客の活用促進

CAPS は、更新にリスクがある、または導入が進んでいないアカウントと認定サービスパートナーを結び付け、体系的なアセスメントによって導入を加速し、チャーンリスクを低減して、パートナー主導の Deal Registration パイプラインを創出します。

詳細：CAPS Program Guide

質問：#global-ecosystem-programs-ops

ポリシーとプロセス

すべての Partner Co-Sell 機会では、その取引を行うために Authorized GitLab Partner が必要です。Deal Registration は Partner Co-Sell 機会には適用されません。 Partner Sourced Deal Registration 機会でも取引を行うために Authorized GitLab Partner が必要であり、さらに GitLab Partner Portal で見つける/作成し、登録する必要があります（アライアンスと GSI を除く）。パートナープログラムの値引きやインセンティブの対象となるには、該当する GitLab Channel Manager が登録された機会を承認する必要があります。Partner Sourced Deal Registration 機会は、以下のいずれかです。

GitLab にとって完全に新規である
既存の GitLab 顧客に対するアップセル/アドオンである

承認された Partner Sourced Deal Registration により、機会で Sales Qualified Source = Partner Generated となります。

詳細情報: Deal Registration Program Overview。

パートナーアカウントレコードの Billing Account と Billing Account Contact

パートナーの請求レコードの作成

GitLab から直接購入する新しいパートナーをオンボーディングする際には、Billing Account と Billing Account Contact のレコードを作成する必要があります。新しいパートナーがクリックスルー契約に署名したか、顧客 MPA に同意した場合、Partner Manager は以下のアクションを取る必要があります。

パートナーの買掛金の連絡先情報を表すコンタクトレコードを、命名規則「[Partner Account Name] - Accounts Payable」でパートナーアカウント上に作成します。コンタクトレコードの住所がパートナーアカウントの住所と一致していることを確認します。
パートナーアカウントで @Billing Ops に Chatter して、新しい Billing Account をリクエストします。以下の情報を含めてください。
- Billing Account Company Name
- Billing Account Contact Name and Email
- 該当する場合は VAT #

ディストリビューション経由で取引するパートナーアカウントには、Billing Account または Billing Account Contact は必要ありません。

Billing Account に関する詳細情報は、Billing Operations Handbook Page を参照してください。

SFDC でパートナーの請求レコードを見つけて見積もりに使用する方法

パートナー見積もりの Invoice Owner と Invoice Owner Contact は、それぞれパートナーの Billing Account と Billing Account Contact のレコードを表します。

ディストリビューター - GitLab セラーは、ディストリビューターの Billing Account と Billing Account Contact のレコードにここからアクセスできます。

注意 - ディストリビューションの情報が見積もりに使用されるため、ディストリビューション経由で取引するパートナーには請求レコードは必要ありません。

リセラーと MSP - GitLab と直接取引するパートナーの Billing Account と Billing Account Contact のレコードを SFDC で見つけるには、まずパートナーアカウントレコードに移動します。

Billing Account - パートナーアカウントレコードの上部にある関連リストクイックリンクセクションの「Billing Account」を参照します。
Billing Account Contact - パートナーの Billing Account を開き、Sold To Work Email（すなわち、買掛金のメールアドレス）を見つけます。このメールアドレスを SFDC で検索し、パートナーアカウントレコードの下にコンタクトレコードがすでに存在するかどうかを確認します。
- パートナーアカウント上にこのメールアドレスの既存のコンタクトレコードがある場合は、それを見積もりの Invoice Owner Contact として使用します。
- パートナーアカウント上にこのメールアドレスの既存のコンタクトレコードがない場合は、「[Partner Name] - Accounts Payable」というこのメールアドレスの新しいコンタクトレコードを作成し、見積もりの Invoice Owner Contact として使用できます。

パートナー取引の見積もり

パートナー見積もりの要件

取引がパートナー経由で行われる場合、GitLab の見積もりが必須です。少なくとも、ドラフト提案を作成してパートナーに提供する必要があり、パートナーはその発注書にオーダーフォーム番号を含める必要があります。SFDC にないパートナーへの見積もりの提供は、いかなる GEO や Sales Segment でも許可されていません。これには、製品や値引き後の価格の見積もり詳細をメールで提供することも含まれます。

パートナー見積もりの責任

Ecosystem Specialist は、APJ における Open および Select パートナー機会（AWS CPPO または GCP MCPO を含む）の見積もりに責任を負います。
フィールドセールスチームは、AMER、EMEA、PubSec の各地域、および直接取引（CPPO/MCPO 以外の AWS および GCP、または IBM OEM 取引）を含む、その他すべてのパートナー見積もりに責任を負います。
PO remittance と顧客とのコミュニケーション業務は、フィールドセールスチームが担います。

パートナー見積もりの概要とリソース

パートナー見積もりの作成は、直接顧客向けの見積もりを作成するプロセスと 非常に似ています。パートナー経由で見積もりを行う際の違いは わずかな細かい点のみ であり、それらは以下の Deal Desk ハンドブックのセクションに記載されています。

見積もりのウォークスルーについては、以下のパートナー取引固有のステップバイステップガイドを含め、Quote Studio Highspot page を参照してください。

SFDC でパートナーの請求レコードを作成または見つけ、それを見積もりに使用する方法のガイダンスについては、このハンドブックの partner billing information セクションを参照してください。

チャンネルパートナーの見積もりリクエスト

APJ における Open または Select パートナー向けのチャンネル見積もりをリクエストするには、以下の手順を実行します。

社内からのリクエスト

SFDC Opportunity から、Request Support → Ecosystem Ops → Quote Request をクリックします。
見積もりリクエストフォームに入力します。
Submit をクリックします。これは Ecosystem Specialist のケースキューにルーティングされます。見積もりまたはステータスの更新が 6 営業時間以内に提供されます。

パートナーからのリクエスト

partner portal にログインします。
Common Requests ページをクリックします。
見積もりリクエストフォームに入力します。
Submit をクリックします。これは Ecosystem Specialist のケースキューにルーティングされます。見積もりまたはステータスの更新が 6 営業時間以内に提供されます。

特定の見積もりリクエストの種類に関する Rules of Engagement の全文はこちらで確認できます。

ディストリビューション経由の取引

GitLab がディストリビューションを活用する理由

GitLab は、他の多くの一流ソフトウェア企業と同様に、グローバルな Authorized Distributor ネットワークを構築しています。ディストリビューターは、GitLab、私たちのパートナー、私たちの顧客に、いくつかの価値ある提供をもたらします。

以下を含む共同成長計画と実行により、市場リーチを加速する:
- GitLab パートナーを募集し、彼らの GitLab セールスおよびテクニカルトレーニングの修了を推進する
- 市場内での顧客の認知を生み出し、見込みのあるリードを引き継ぐ
GitLab のセールスキャパシティとカバレッジを補強する。ディストリビューターのセールスチームは:
- パートナーや GitLab セールスチームと協力し、コセリングを支援する
- 多くの場合、市場内におり、現地の言語を話す
GitLab セールスから取引の管理業務を引き受け、より価値の高い販売活動のための時間を解放する
- ディストリビューターの e-Marketplace により、GitLab チームによるタッチをゼロにして、顧客やパートナーが数分で配信される GitLab の注文を行える
- GitLab の Quote to Cash プロセスの専門家である単一の窓口を提供し、セールスサイクル全体を通して効率を推進する
- GitLab が大幅な人員追加なしに取引量の増加に対応できるよう、運用をスケールできるようにする（例: Deal Desk、Order Management、Billing）
クレジット管理
- GitLab のクレジット管理のコストとリスクを削減する
- パートナー/顧客が現地通貨で取引できる機能を含むさまざまなファイナンスオプションを提供し、彼らのリスクを軽減する
販売前後の両方で、GitLab のテクニカルサービス、トレーニングキャパシティ、カバレッジを拡張する

地域・市場別のディストリビューター要件とカバレッジ

コマーシャル市場向け:

アクティブな Authorized GitLab Distributor がある地域/国に所在する Open パートナーは、それらのディストリビューター経由で GitLab を購入する必要があります
Select パートナーは、GitLab と直接取引する（特定の地域を除く）か、その地域の authorized distributor 経由で取引するかを選択できます
北米では、パートナーは以下のいずれかのディストリビューターを通じて取引します:
- Climb Solutions: 米国（[email protected]）およびカナダ（[email protected]）
- Carahsoft Technology Corporation: [email protected]
EMEA では: パートナーは [email protected] 経由で Amazic と取引します
APAC（シンガポール、マレーシア、インドネシア、ベトナム、ニュージーランド/オーストラリア）では: パートナーは [email protected] 経由で Tech Data/TD Synnex と取引します
インドでは: パートナーは [email protected] 経由で Redington と取引することも選べます
日本では: パートナーは以下のいずれかと取引することを選べます:
- [email protected] 経由で Networld
- [email protected] 経由で SB C&S
タイでは: パートナーは [email protected] 経由で Get On Technology と取引することも選べます

GitLab セラーは、ディストリビューターの請求レコードへのリンクと、これらのレコードが見積もりプロセスでどのように使用されるかのガイダンスについて、このハンドブックの partner billing section を参照することもできます。

US PubSec 向け:

パートナーは [email protected] 経由で Carahsoft Technology Corporation と取引します

ディストリビューターの見積もりと注文に関する Rules of Engagement

ディストリビューターは、見積もりと注文のプロセスについて、GitLab セラーおよび/または Ecosystem Specialist と直接連携します。GitLab セラーは、見積もりと注文のプロセスを支援するために、partner quoting resources、distributor contact information、GitLab Sales FAQ - Selling with Partners を活用できます。

リセラーが上記のエイリアス経由でディストリビューターから直接見積もりをリクエストした場合、非 PubSec ディストリビューターは partner portal を通じて見積もりリクエストを送信するか、自分のアカウントエグゼクティブと連携できます。ディストリビューターは、自分のアカウントエグゼクティブが誰か不明な場合は [email protected] に連絡できます。Partner Support は、セールスがディストリビューターと機会に取り組めるよう、見積もりの作成・提供（該当する場合）を含めて、顧客アカウント/機会を所有する GitLab Sales Rep にリクエストを転送します。

GitLab Sales Rep がリセラーと直接連携しており、そのリセラーをディストリビューター経由で見積もる必要がある場合（例: 相手が Open パートナーである場合）、セールスは上記のこのセクションでリンクされたリソースを活用して見積もりを作成し、ディストリビューションに送信できます。

GitLab セラーが注意すべき重要な点:

two-tier ディストリビューション取引における私たちの価格設定は、GitLab とディストリビューターの間のみのものです。ディストリビューションの見積もりを送信したり、ディストリビューターの価格設定について議論したりする際に、リセラーや顧客を 決して 含めるべきではありません。
ディストリビューターは独自の価格表を持っており、価格が標準的なプログラム上の値引きである限り、公式の GitLab 見積もりを受け取ることなく、それをもとに新規ビジネスやその他の注文タイプを自己見積もり・注文できる態勢が整っています。特に複数入札のシナリオでは、PO を受け取るまで、その機会に入札しているパートナーを把握できない場合があります。

ディストリビューターの e-Marketplace

GitLab は、顧客が GitLab authorized reseller 経由で取引できるよう、ディストリビューターの e-Marketplace を有効化しています。e-Marketplace 機能を有効化する前に、パートナーには以下を含む特定の要件があります。

パートナーが良好な状態にある authorized GitLab Open または Select パートナーであること。
パートナーのテクニカルな専門知識および/またはサービス提供の概要を含む GitLab e-Marketplace ページ。
ドラフトページの GitLab によるレビューと、ディストリビューターに提供される GitLab の書面（メール）による承認。

GitLab は、問題が発生した場合、パートナーの e-Marketplace 提供を一時停止または無効化する権利を留保します。ディストリビューターの e-Marketplace の詳細については、パートナーは自社のディストリビューターに連絡するか、自社の GitLab Channel Manager に連絡してください。

パートナーセールス FAQ

パートナーと GitLab セラーは、GitLab のセールスプロセス全体を通してどのように互いに協力するかについて、頻繁に質問します。これらの FAQ と、パートナーと GitLab セラーの双方の視点からの回答を記載した以下のリソースを参照してください。

SFDC フィールドの定義

セクション I: Partner Sourced Deal Registration

DR - Partner: GitLab がその後システムで「承認」した Partner Sourced Deal Registration を「送信」したリセラーパートナー
DR - Partner Deal Type:
- MSP: パートナーが顧客の代わりにライセンスを購入し 所有する
- Resale: パートナーが実際に自社の書面で取引を行う
- Referral: パートナーがリード/機会を持ち込むが、GitLab と直接、または別のパートナーを通じて取引する
DR - Status: Partner Sourced Deal Registration が Pending、Approved、Denied のいずれであるかを示す
DR - Distributor: 該当する場合に、DR - Partner が購入する GitLab-authorized distributor

セクション II: Primary Quote Partner Data*

Resale Partner: 主見積もりのリセールパートナー。取引を行うパートナー
Distributor: 主見積もりに従って取引する GitLab-authorized distributor
Resale Partner Track: 値は Select、Open、または Technology となり、Resale Partner に基づいて決定される *承認時に主見積もりからスタンプされます。フィールドはロックされます。

セクション III: Partner Contribution Data

Referral: AWS/ACE のコセル登録レコードへのリンク
ESM/Cloud ESM Notes: ESM と Cloud ESM がパートナー機会のメモと次のステップをここに入力する
Alliance Partner Opp ID: ESM と Cloud ESM がクラウドパートナー（AWS または GCP）のコセル登録 ID をここに入力する
Platform Partner: GitLab がデプロイされる顧客のプラットフォーム
Hyperscaler Engaged: ESM と Cloud ESM が、初期段階のマーケットプレイス取引で関与するクラウドパートナー（AWS または GCP）を選択できる

Services Resale

パートナーは、GitLab Professional Services を再販することでプログラムの値引きを獲得できます

Incumbency Renewals

既存パートナーはプログラムの更新値引きの対象となります。直近の販売を取引したパートナーが既存パートナーと見なされます。
別のパートナーが既存パートナー値引きを獲得できるのは、顧客からの正式な書面によるコミュニケーションを通じてのみです。これは、顧客の権限を持つ代表者からのメールで提供できます。
パートナー値引きを獲得するには、パートナーはコンプライアンス要件を満たす必要があります（すなわち、良好なクレジット状態にある、顧客に関する四半期ごとの更新を提供済みである、更新の 30 日以内にレビューを行うなど）。
顧客がもはやそのパートナーと協力したくないと書面で文書化した場合を除き、GitLab Sales は更新について既存チャンネルパートナーと協力する必要があります。既存パートナーがいる場合、GitLab は直接の更新見積もりを提供できません。

Tender Offers（複数入札）

Tender offer とは、顧客がプロジェクトに対して複数の入札をリクエストするものです。
すべてのパートナーがセールスプロセスに関与し入札を作成することになるため、すべてのパートナーが Partner Co-Sell 値引きの対象となります。ただし、あるパートナーが顧客と早期に（テンダー前に）関わり、その取引をソースした場合、承認された Partner Sourced Deal Registration によりより高い値引きを受けられます。Partner Sourced 値引きを獲得するパートナーがその取引を受注できなかった場合、追加の紹介報酬は受け取りません。自社のサービスを提供するパートナーは、対象となる販売値引きに加えて、Service Attach インセンティブの対象となります。上記の例外は以下のとおりです:
- US PubSec ビジネス: tender offer に承認された Partner Sourced Deal Registration がある場合、入札する残りのパートナーは MSRP（List Price）を受け取ります。
- 更新: 既存リセラーは前年の値引きを受け取り、その他すべてのリセラーはフラットな更新に対して MSRP（List Price）を受け取ります。すべてのリセラーの更新アドオンは、Deal Registration ステータスに基づいてプログラムの値引きを受けられます。

Program Compliance

パートナーがプログラムの値引きに従って取引するには、GitLab Partner Agreement に同意する必要があります。
パートナー値引きを獲得するには、パートナーはプログラムに準拠している必要があります。
非契約パートナーは、地域のチャンネルディレクター、チャンネルプログラムディレクター、または VP of Channels の明示的な承認がある場合のみ、一回限りの取引を行えます。

認定されていないパートナー

認定パートナーとは、GitLab と取引する契約に署名したパートナーです。SFDC では「Partner Status」が「Authorized」と表示され、「Signed Contract Date」フィールドに日付があり、かつ「Click-Through Agreement」のボックスがチェックされているか、または手動の契約がアカウントレコードの Google docs もしくは Contract セクションに記載されています。
GitLab Channel Program の主要な目標は、私たちの認定パートナーの成功です。これは、可能な限り彼らと取引を行うべきであることを意味します。私たちは、地域、顧客セグメント、垂直市場にわたるカバレッジを提供するためにチャンネルを開発しています。しかし、顧客が、GitLab Partner Program に参加する意思のないパートナーによる取引を求める状況もあります。そのような状況においてのみ、私たちは認定されていないパートナーと取引すべきであり、それもプログラムチームの明示的な承認がある場合に限ります。
認定されていないパートナーは GitLab Partner Agreement に署名していません。
認定されていないパートナーが GitLab の製品やサービスを取引したい場合は、Partner Portal にアクセスしてサインアップしてもらってください。Agreement を承諾する権限を持つ人物が必要です。
認定されていないパートナーは、プログラムチームによってまれに、しかし明示的に承認が与えられる場合を除き、GitLab の製品および/またはサービスを取引できません。#partner-programs-ops Slack チャンネルに連絡してください。

パートナー契約に関する Legal リクエスト

パートナー契約への legal team の関与をリクエストするプロセスは、legal team のハンドブックページで確認できます。パートナー契約に署名してもらうプロセスは、その他の legal リクエストのプロセスとは異なることに注意してください。

パートナーのレポーティングとタギング

Partner Reporting and Tagging

定義

Deal Path: 取引がどのように行われるか。値は Partner、Direct、Web Direct となります。注: Partner には Referral 機会が含まれます
Partner Sourced Deal Reg: パートナーが Partner Portal 経由で自社がソースした機会の Registration を送信します。このマトリックスでは Deal Reg が承認されていることを前提とします。取引が Partner Sourced でない場合、Deal Reg は適用されません
DR - Deal Type: パートナーが送信した Partner Sourced Deal Registration の種類。オプションには Resale、Referral、MSP が含まれます。注: Partner Source Deal Registration がない場合、このフィールドは空白になります
Initial Source: 最初のリードソースに基づいて機会に反映される SFDC Lead の値。この値がどのように設定されるかは注文タイプによって異なります:
- 新規サブスクリプション: 機会を作成した元のコンタクトの Initial Source から反映されます。deal registration プロセスを通じて作成された新しいコンタクトは、Initial Source が Partner Qualified Lead になります。
- 更新: アカウントの最初の Closed-Won の New Business 機会の Initial Source から反映されます
Sales Qualified Sourced (SQS): SFDC で誰が機会をコンバート/作成するか。1 つの値のみとなります
Order Type: SFDC における顧客の注文区分。New First Order または Growth

ユースケース

	1	2	3	4
Deal Path	Partner	Partner	Partner	Partner
Partner Sourced Deal Reg	Yes	Yes	N/A	N/A
DR - Deal Type	Resale	Referral	N/A	N/A
Initial Source	PQL	PQL	PQL	Non PQL
SQS (Sourced)	Partner Generated	Partner Generated	Partner Generated	AE/SDR Generated
Order Type	New FO or Growth	New FO or Growth	New FO or Growth	New FO or Growth

番号 1 と 2
- 2 つの可能なパス:
  - パートナーが Partner Sourced Deal Reg を送信し、システムに機会が存在しない。Initial source は PQL となり、SQS はデフォルトで Partner Generated になる
  - 有効な Partner Sourced Deal Reg が送信され承認される前に、AE または SDR が機会を作成する。Deal Registration がリンクされ承認されると、機会の SQS は自動的に Partner Generated に更新される
- 番号 1 は機会をソースしたパートナー経由で取引され、番号 2 は顧客と直接取引されたソース済みの紹介である
- これは New と Growth の両方の注文に適用される
番号 3
- システムに機会がなく、パートナーが Partner Sourced Deal Reg を送信しなかった取引について、パートナーが注文を送信する
番号 4
- 取引はパートナー経由で行われるが、GitLab の AE または SDR のいずれかによってソースされた

デフォルトのロジック

Partner Sourced Deal Reg = True で機会が存在しない場合、Initial Source = PQL かつ SQS = Partner Generated となります
Partner Sourced Deal Reg が機会にリンクされ承認された場合、SQS = Partner Generated となります
Initial Source = PQL の場合、SQS = Partner Generated となります
更新機会の場合、Initial Source はリンクされたソース機会からではなく、アカウントの最も古い Closed-Won の New Business 機会から継承されます。

注: 更新機会の場合、Initial Source はソース機会からコピーされません。アカウントの最も古い Closed-Won の New Business 機会を参照します。したがって、アカウントの最も古い Closed-Won の New Business 機会のソースが PQL であった場合、ソース機会が Initial Source = AE Generated を示していても、更新は Initial Source = PQL を示すことがあります。

チャンネル向けの SFDC Opportunity Source フィールドの値

Initial Source - Partner Qualified Lead (PQL): パートナーが自らソースしたか、GitLab がそのリードを提供して取り組んでもらったかにかかわらず、パートナーがそのリードを作成および/または見込み確認した。
Sales Qualified Source: - Partner Generated:
- パートナーがリード/PQL を見込みのある機会にコンバートしたか、事前にシステムにリードがない状態で全く新しい機会を作成した。Initial Source = PQL の場合、SQS はデフォルトで Partner になる
- パートナーが Partner Sourced Deal Reg を送信し、これが (i) 新しい機会を作成するか、(ii) 既存の機会に紐づけられて GitLab により承認される

パートナー機会の管理

Partner Co-Sell (Resale) | Partner Sourced Deal Registration: Resale | MSP | Referral

GitLab と取引するには、パートナーは GitLab により認可されており、かつ少なくとも 1 つのセールストレーニングを修了済みである必要があります。

Partner Co-Sell

すべてのチャンネル取引は、承認された Partner Sourced Deal Registration があるか、または機会の Sales Qualified Source = Partner Generated である場合を除き、Partner Co-Sell 機会と見なされます。これらの機会はパートナー単独でソースされたものではありませんが、販売プロセスにおける GitLab とパートナーの関係を際立たせるものです。Partner Co-Sell 取引では、パートナーが deal registration を送信する必要はなく、GitLab Partner Program で特定される標準的な Partner Co-Sell 値引きに従って処理されるべきです。

US Public Sector Preferred Partner Co-Sell リクエストプロセス

Partner Sourced Deal Registration プロセスは、コマーシャルと US Pubsec ビジネスで同じです。以下の手順は、US Public Sector CoSell 機会にのみ適用されます。

各 public sector パートナーには、SAE、ISR、または Channel Manager のいずれかから Google フォームへのリンクが提供されます。パートナーが Preferred Partner Co-Sell 値引きを受けるには、このフォームに入力する必要があります。
パートナーが機会を認識したら、Google フォームに入力する必要があります。これにより、すべての関連データが Google sheet にタイムスタンプ付きで記録されます。
Google フォームへの入力の一部として、パートナーはこれについて議論した SAE の名前とメールを入力する必要があります。そのメールアドレスがフォームに入力されフォームが送信されると、その SAE は Pubsec Co-Sell 機会の通知を受け取ります。
その後、SAE は Handbook のガイドラインに基づいて送信を承認または却下します。
- preferred partner の送信を受け入れるビジネス上の理由を Google フォームに記載する必要があります。
- SAE の承認または却下は、Google sheet にタイムスタンプ付きで記録されます。
パートナーが承認され選択されると、18 桁の機会 ID が彼らと共有されます。
以前に承認されたパートナーが現在は除外される場合、その SAE は「Removed」オプションを選択し、パートナーのメールアドレスを入力して彼らに通知できます。

すべての送信は監査目的で記録・追跡されます。選択された preferred partner は、Partner Co-Sell 値引きの見積もり上の Resale Partner と一致する必要があります。

同じ機会の見積もりを受け取る他のパートナーには、MSRP が提供されます。

GitLab チームメンバー向けのさらなるイネーブルメントが利用可能です。詳細は #partner-programs-ops Slack チャンネルに連絡してください。

US Public Sector Co-Sell パートナー送信を承認するためのガイドライン

以下は、承認された US Public Sector パートナーが GitLab がソースした機会で優遇価格を受けるための明示的なガイドラインです。

パートナーの要件:

承認された US Public Sector パートナーであり、GitLab と取引する認可を受けていること
パートナーは、その機会について SAE と 1 回のミーティングを完了している必要がある -このミーティングには、ビジョンを持って導入を実現し、目的を持って取引を拡大するために私たちがどのように協力できるかという足並みの統一についての会話が含まれていなければならない
パートナーは、Public Sector Co-Sell フォームに入力し、SAE が提供した 18 桁の機会 ID を含めている必要がある

Partner Sourced Deal Registration

Partner Sourced Deal Registration プログラムは、GitLab に完全に新規のビジネスをもたらしたパートナーに報いるものです。GitLab Partner Program には、3 種類の Partner Sourced Deal Registration があります。

パートナーがソースした Resale 機会の登録
パートナーがソースした MSP 機会の登録（パートナーがライセンスを購入し所有して、エンドカスタマーにマネージドサービスを提供する）
パートナーがソースした Referral 機会の登録（パートナーは GitLab に持ち込んだビジネスを取引しない）

各登録タイプの処理方法に関するステップバイステップの手順については、以下のセクションを参照してください: Resale、MSP、Referral。

GitLab の Ecosystem Sales Manager、Sales Rep、Regional Director が協力して、Partner Sourced Deal Registration の送信をレビューし対応します。レビューと承認のプロセスの詳細については、Partner Sourced Deal Registration: How it Works セクションを参照してください。

GitLab が Partner Sourced Deal Registration についてパートナーとコミュニケーションを取る SLA は 2 営業日です。登録について議論するための最初のアウトリーチ、追加情報のリクエスト、承認、却下のいずれであっても、2 営業日以内に登録するパートナーとの接触がなければなりません。

1 つのパートナーのみが取引をソースできるため、1 つの機会に承認される Partner Sourced Deal Registration は 1 つだけです。念のため、Partner Sourced Deal Registration は機会ベースであり、パートナーはアカウントを登録できません。

Partner Sourced Deal Registration: How it Works

パートナーは、Impartner がホストする Partner Portal で deal registration を送信できます。

Partner

パートナーが Partner Sourced Deal Registration を送信すると、以下が発生します。

deal registration が正常に作成され送信されたことを確認するメッセージが表示されます。登録はパートナーのポータルアカウントの deal registration ダッシュボードでも閲覧できます。
システムが SFDC の registration オブジェクトに、登録のすべての詳細を含む registration レコードを作成します。
システムが Ecosystem Operations チームに登録のレビューを通知します。

Ecosystem Operations

Ecosystem Operations チームは、パートナーが送信した後（Status = “New”）に登録をレビューします。以下の場合があります:

SFDC に既存の顧客アカウントがある 場合、アカウントとコンタクトを登録にリンクし、登録を ESM にルーティングします。
SFDC に既存の顧客アカウントがない 場合、アカウントを作成し、アカウントとコンタクトを登録にリンクし、夜間更新で SFDC がアカウントのテリトリーとオーナーを割り当てるまで保留します。セールスチームが割り当てられたら、アカウントとコンタクトを登録にリンクし、登録を ESM にルーティングします。

Ecosystem Operations チームには、勤務時間内（月曜から金曜）に、既存顧客の登録に対応する 2 時間の SLA と、新規顧客の登録に対応する 24 時間の SLA があります。

GitLab Ecosystem Sales Manager

リンクされた顧客アカウントの Ecosystem Sales Manager は、登録を受け取ったことを知らせるメール通知を受け取ります。登録の Status = “Pending Approval” になると、レビューと承認の準備が整います。Ecosystem Sales Manager は、SFDC の Deal Registrations タブ内の Deal Registration View/Deal Registration Approval View で登録を閲覧することもできます。Ecosystem Sales Manager は、登録をレビューし、このプロセス中に該当する GitLab Sales Rep と Regional Director とコミュニケーションを取る責任があります。Ecosystem Sales Manager は、機会を添付するか新しい機会を作成し、レビューの完了後に登録を承認、却下、または追加情報のために返却する必要があります。承認すると、最終レビューのために適切な Regional Director に自動的に送信されます。

GitLab Regional Director (RD)

機会の GitLab Regional Director は、Ecosystem Sales Manager が承認した Partner Sourced Deal Registration の最終レビューを行う責任があり、登録を承認、却下、または追加情報のために返却する必要があります。RD は、Ecosystem Sales Manager が承認した場合（Status = “Pending Approval”）にのみ、登録をレビューするメール通知を受け取ります。RD は、SFDC の Registration タブ内の Deal Registration View/Deal Registration Approval View で登録を閲覧することもできます。

Cloud、OEM、GSI パートナー

クラウドマーケットプレイス、OEM パートナー、GSI パートナーは GitLab のために機会をソースしますが、これらの機会について自分自身の Partner Sourced Deal Registration を送信することはありません。これらのパートナーの Registration プロセスは、代わりにパートナーに代わって GitLab Ecosystem Sales Manager によって開始されます。

以下の手順は、Deal Registration プロセスを開始してソースした取引を Partner Generated として認定するために、Cloud、OEM、または GSI パートナーに代わって Partner Sourced Deal Registration がどのように送信されるかを説明しています。

Ecosystem Sales Manager は、完全なステップバイステップの手順について GSI, Hyperscaler, & OEM Deal Registration Process Guide に従うことができます。

Partner Sourced Deal Registration: Rules of Engagement

Partner Sourced 値引き
- Partner Sourced 値引き付きの見積もりを受けるには、パートナーはその機会について Partner Sourced Deal Registration を送信し、GitLab がそれを承認する必要があります。
- 1 つの機会につき 1 つのパートナーのみが Partner Sourced 値引きを獲得できます。承認された Partner Sourced Deal Registration がない場合、パートナーは一般に Co-Sell 値引き率を受け取ります。
承認プロセス: deal registration の承認は、(i) 受領順、(ii) 機会の見込み確認、(iii) パートナーの国内/地域内サポートの提供能力、(iv) パートナーと顧客の関係の組み合わせに基づきます
排他性: 1 つの機会につき 1 つのパートナーのみが deal registration マージンを獲得できます
資格: 新規または既存の顧客機会、既存顧客との新規機会、成長を伴う更新へのアドオン販売が対象となります。フラットな更新は対象外です。
要件: 署名済みの GitLab Partner Program Agreement を持つ認定パートナーのみが取引を登録できます。少なくとも 1 名のパートナー従業員が GitLab Foundations for Partners トレーニングを修了する必要があります
GitLab の SLA
- GitLab が Partner Sourced Deal Registration についてパートナーとコミュニケーションを取る SLA は 2 営業日です。登録について議論するための最初のアウトリーチ、追加情報のリクエスト、承認、却下のいずれであっても、2 営業日以内に登録するパートナーとの接触がなければなりません。
- GitLab RD には、登録を承認または却下する 1 営業日があり、これは登録が承認のために彼らのキューに入ったときに開始されます。RD は、承認が 1 営業日の SLA を超えると予想される場合、GitLab Ecosystem Sales Manager と必ずコミュニケーションを取らなければなりません。
バックアップ承認者の特定と通知
- GitLab Ecosystem Sales Manager と RD は、不在になる前に、SFDC の delegate approval process を使用して自分に代わって登録を承認するバックアップ承認者を必ず特定し通知すべきです。これにより、不在時にも承認リクエストに対応できるようになり、私たちの SLA を満たすために極めて重要です（上記の GitLab の SLA を参照）。
標準期間と延長
- 承認された deal registration には、元の承認日から標準 90 日間の有効期限があります。
- 最初の 90 日間の承認を超える Deal Registration の延長は、GitLab の独自の裁量によります。標準の 30 日間の延長を許可するには、GitLab パートナーが Partner Portal の Deal Registration フォームで延長をリクエストする必要があります。Ecosystem Sales Manager は、登録の Extension Approval Status フィールドをクリックし、Approved、Denied、または Pending を選択できます。30 日を超える非標準の延長については、登録レコードの Request Support ボタンを使用して Ecosystem Ops にケースをオープンし、登録が失効すべき新しい日付を提供してください。
セールスプロセスにおける GitLab とパートナーの協力
- Resale および MSP 機会 - GitLab は、承認された Partner Sourced Deal Registration を持つパートナーと協力し、セールスプロセス全体を通してパートナーをサポートできる態勢にあります。
- Referral 機会 - パートナーは GitLab を適切な顧客コンタクトに紹介し、その結果として GitLab に見込みのある機会が生まれます。その後、GitLab は一般にセールスプロセスを完了まで主導します。
Closed Lost に登録された機会
- GitLab Sales Rep は一般に、機会が進まないことを電話またはメールでパートナーに通知し、その後 SFDC の機会を Closed Lost に更新します。
- Deal Registration はシステムで Closed Lost に更新され、パートナーは通知を受け取ります。

Partner Sourced Deal Registration: システムステータスと情報

Deal Registration の詳細が、セールスチームが機会で予測する情報を上書きすることは決してありません。
Deal Registration ID（DR - Deal ID）を使用して、システム内のすべての Deal Registration を追跡できます。
Deal Registration は、SFDC の Deal Registration オブジェクト配下の個別の Deal Registration レコードです。Deal Registration は Lead オブジェクト上の Lead レコードではありません。

Partner Sourced Deal Registration: レポート & ツール

Partner Sourced Deal Registration: Resale オポチュニティ

resale 機会の Partner Sourced Deal Registration は、GitLab に完全に新規のビジネスをもたらしたパートナーに報いるものです。承認された Partner Sourced Deal Registration は、GitLab Partner Program で説明されているとおり、一般に Co-Sell 率よりも深い値引きをパートナーに提供します。

resale 機会の Partner Sourced Deal Registration を処理するには、以下の手順に従います。

最初のレビューと対応を行う Ecosystem Operations

Ecosystem Operations チームは、Status = New のときに登録をレビューおよび更新する最初のアクションを担います。重要な注意点として、Status = New の間、登録は Ecosystem Sales Manager または Regional Director のレビューの 準備ができていません。

既存の顧客アカウントをリンクするか、新しい顧客アカウントを作成します。
既存の顧客コンタクトをリンクするか、Initial Source を Partner Qualified Lead として新しい顧客コンタクトを作成します。
承認フローを通じて登録を送信します。登録は ESM と RD の承認にルーティングされます。

ESM と RD の承認にルーティングされる登録は、以下の手順に示すように、レビューと決定をリクエストするメールを承認者に送信します。

レビューと対応を行う Ecosystem Sales Manager

メールまたは Deal Registration View/Deal Registration Approval View の登録リンクをクリックして、Salesforce で登録レコードを開きます。
Type が「Resale」であること、およびパートナーが登録を進めるのに十分な詳細を提供したことを確認します。登録の詳細が:
- 正確かつ完全 な場合、次のステップに進みます。
- 不正確および/または不完全 な場合、登録を返却してパートナーに追加情報をリクエストします。DR Approval セクションで「Return」を選択し、パートナーに送信するコメントを追加します。
GitLab Sales Rep と RD と機会について議論し、登録を承認するか却下するかを決定します。
登録レコードの Ecosystem Sales Manager DR Approval セクションに移動します。次のいずれかを行う場合:
- 承認する場合、DR Approval セクションで「Approve」を選択し、Next をクリックして機会をリンクし、最後にもう一度 Next をクリックしてコメントを追加し承認を完了します。
- 返却する場合、DR Approval セクションで「Return」を選択し、General Information セクションの Linked Opportunity フィールドをクリックして機会をリンクし、最後に Next をクリックしてコメントを追加し承認を完了します。
- 却下する場合、DR Approval セクションで「Deny」を選択し、General Information セクションの Linked Opportunity フィールドをクリックして機会をリンクし、最後に Next をクリックしてコメントを追加し承認を完了します。
DR Approval セクションで機会をリンクするか、Linked Opportunity フィールドをクリックします:
- 機会がすでに存在する場合、機会名をクリックします。
  - 登録を承認する予定の場合、承認フローまたは General Information セクションの Primary チェックボックスをクリックします。
  - 登録を却下する予定の場合、Primary チェックボックスをクリックしません。
- 一致する機会がない場合、DR Approval セクションの Create a new Opportunity instead? トグルをクリックするか、Linked Opportunity フィールドの + New Opportunity オプションをクリックし、Opportunity Record Type として「Standard」を選択します。必要な機会の情報を入力し、「Save」をクリックします。その後、承認フローまたは General Information セクションの Primary チェックボックスをクリックします。
このプロセス中に新しい機会を作成した場合（上記のステップ 5 を参照）、Change Owner ドロップダウンオプションを使用して、新しい機会の Opportunity Owner を顧客アカウントを所有する Sales Rep に更新します。

最終レビューと対応を行う Regional Director (RD)（Ecosystem Sales Manager によって承認された場合）

登録がレビューと承認のためにあなたのキューに入ると、承認リクエストのメールを受け取ります。メールまたは Deal Registration View/Deal Registration Approval View のリンクをクリックして、SFDC で登録レコードを開きます。
登録の最終的な承認または却下を行う前に、Ecosystem Sales Manager と GitLab Sales Rep との足並みの統一を確認します。
登録の上部にある DR Approval セクションに移動します。
Approve、Deny、または Return オプションを選択します。該当する場合は、Comments フィールドにパートナー向けのメッセージを追加します。Next を選択してプロセスを完了します。 deal registration フォームは見積もりツールではなく、見積もりの作成に必要なすべての情報を含んでいるわけではありません。GitLab Sales Rep は、見積もりを作成する前に、必要な情報をリクエストするためにパートナーと連絡を取る必要があります。

Partner Sourced Deal Registration: MSP オポチュニティ

MSP 機会の Partner Sourced Deal Registration は、エンドカスタマーのために製品とサービスを管理するパートナーに報いるものです。承認された Partner Sourced Deal Registration は、GitLab Partner Program で説明されているとおり、一般に Co-Sell 率よりも深い値引きをパートナーに提供します。

Managed Service Provider（MSP）は、エンドユーザーの代わりにライセンスを購入します。MSP がライセンスの所有者かつ管理者となりますが、その顧客であるエンドユーザーがライセンスを使用する者です。これにより、適切なレポーティングと報酬を確保するために、GitLab Salesforce の機会に特有のニーズが生じます。MSP 機会の手順は resale 機会の手順とは異なることに注意してください。

MSP 機会の Partner Sourced Deal Registration を処理するには、以下の手順に従います。

最初のレビューと対応を行う Ecosystem Operations

既存の顧客アカウントをリンクするか、新しい顧客アカウントを作成します。
既存の顧客コンタクトをリンクするか、Initial Source を Partner Qualified Lead として新しい顧客コンタクトを作成します。
承認フローを通じて登録を送信します。登録は ESM と RD の承認にルーティングされます。

ESM と RD の承認にルーティングされる登録は、以下の手順に示すように、レビューと決定をリクエストするメールを承認者に送信します。

レビューと対応を行う Ecosystem Sales Manager

メールまたは Deal Registration View/Deal Registration Approval View の登録リンクをクリックして、Salesforce で登録レコードを開きます。
Type が「MSP」であること、およびパートナーが登録を進めるのに十分な詳細を提供したことを確認します。登録の詳細が:
- 正確かつ完全 な場合、次のステップに進みます。
- 不正確および/または不完全 な場合、登録を返却してパートナーに追加情報をリクエストします。DR Approval セクションで「Return」を選択し、パートナーに送信するコメントを追加します。
GitLab Sales Rep と RD と機会について議論し、登録を承認するか却下するかを決定します。
登録レコードの Ecosystem Sales Manager DR Approval セクションに移動します。次のいずれかを行う場合:
- 承認する場合、DR Approval セクションで「Approve」を選択し、Next をクリックして機会をリンクし、最後にもう一度 Next をクリックしてコメントを追加し承認を完了します。
- 返却する場合、DR Approval セクションで「Return」を選択し、General Information セクションの Linked Opportunity フィールドをクリックして機会をリンクし、最後に Next をクリックしてコメントを追加し承認を完了します。
- 却下する場合、DR Approval セクションで「Deny」を選択し、General Information セクションの Linked Opportunity フィールドをクリックして機会をリンクし、最後に Next をクリックしてコメントを追加し承認を完了します。
DR Approval セクションで機会をリンクするか、Linked Opportunity フィールドをクリックします:
- 機会がすでに存在する場合、機会名をクリックします。
  - 登録を承認する予定の場合、承認フローまたは General Information セクションの Primary チェックボックスをクリックします。
  - 登録を却下する予定の場合、Primary チェックボックスをクリックしません。
- 一致する機会がない場合、DR Approval セクションの Create a new Opportunity instead? トグルをクリックするか、Linked Opportunity フィールドの + New Opportunity オプションをクリックし、Opportunity Record Type として「Standard」を選択します。必要な機会の情報を入力し、「Save」をクリックします。その後、承認フローまたは General Information セクションの Primary チェックボックスをクリックします。
機会の Account Name フィールドをパートナーアカウントに変更します。これは MSP End User（すなわち、顧客）アカウントであってはなりません。
MSP End User フィールドに顧客アカウントを追加します。
このプロセス中に新しい機会を作成した場合（上記のステップ 5 を参照）、Change Owner ドロップダウンオプションを使用して、新しい機会の Opportunity Owner を顧客アカウントを所有する Sales Rep に更新します。
機会と見積もりの詳細について議論し足並みを揃えられるよう、GitLab Sales Rep を MSP Partner Rep につなぎます。
機会の管理と見積もりの作成に必要なプロセスの詳細を持てるよう、GitLab Sales Rep に Deal Desk MSP quoting と Internal Partner Program discounting のリンクを提供します。

最終レビューと対応を行う Regional Director (RD)（Ecosystem Sales Manager によって承認された場合）

登録がレビューと承認のためにあなたのキューに入ると、承認リクエストのメールを受け取ります。メールまたは Deal Registration View/Deal Registration Approval View のリンクをクリックして、SFDC で登録レコードを開きます。
登録の最終的な承認または却下を行う前に、Ecosystem Sales Manager と GitLab Sales Rep との足並みの統一を確認します。
登録の上部にある DR Approval セクションに移動します。
Approve、Deny、または Return オプションを選択します。該当する場合は、Comments フィールドにパートナー向けのメッセージを追加します。Next を選択してプロセスを完了します。 deal registration フォームは見積もりツールではなく、見積もりの作成に必要なすべての情報を含んでいるわけではありません。GitLab Sales Rep は、見積もりを作成する前に、必要な情報をリクエストするためにパートナーと連絡を取る必要があります。

Partner Sourced Deal Registration: Referral オポチュニティ

referral 機会の Partner Sourced Deal Registration は、そのパートナーが取引を行わない場合でも、GitLab に完全に新規のビジネスをもたらしたパートナーに報いるものです。referral 機会の承認された Partner Sourced Deal Registration は、GitLab Partner Program で説明されているとおり、GitLab が取引を受注として正常にクローズした際に、パートナーに バックエンドリベート を提供します（四半期ごとに処理されます）。

Referral 機会の Partner Sourced Deal Registration を処理するには、以下の手順に従います。

最初のレビューと対応を行う Ecosystem Operations

既存の顧客アカウントをリンクするか、新しい顧客アカウントを作成します。
既存の機会をリンクするか、新しい機会を作成するか、Ecosystem Sales Manager がリンクするために機会フィールドを空白のままにします。
承認フローを通じて登録を送信します。Rules of Engagement に詳述されているとおり、登録は承認、却下、追加情報のために返却、または ESM と RD の承認にルーティングされます。

ESM と RD の承認にルーティングされる登録は、以下の手順に示すように、レビューと決定をリクエストするメールを承認者に送信します。

レビューと対応を行う Ecosystem Sales Manager

メールまたは Deal Registration View/Deal Registration Approval View の登録リンクをクリックして、Salesforce で登録レコードを開きます。
Type が「Referral」であること、およびパートナーが登録を進めるのに十分な詳細を提供したことを確認します。登録の詳細が:
- 正確かつ完全 な場合、次のステップに進みます。
- 不正確および/または不完全 な場合、登録を返却してパートナーに追加情報をリクエストします。DR Approval セクションで「Return」を選択し、パートナーに送信するコメントを追加します。
GitLab Sales Rep と RD と機会について議論し、登録を承認するか却下するかを決定します。
登録レコードの Ecosystem Sales Manager DR Approval セクションに移動します。次のいずれかを行う場合:
- 承認する場合、DR Approval セクションで「Approve」を選択し、Next をクリックして機会をリンクし、最後にもう一度 Next をクリックしてコメントを追加し承認を完了します。
- 返却する場合、DR Approval セクションで「Return」を選択し、General Information セクションの Linked Opportunity フィールドをクリックして機会をリンクし、最後に Next をクリックしてコメントを追加し承認を完了します。
- 却下する場合、DR Approval セクションで「Deny」を選択し、General Information セクションの Linked Opportunity フィールドをクリックして機会をリンクし、最後に Next をクリックしてコメントを追加し承認を完了します。
DR Approval セクションで機会をリンクするか、Linked Opportunity フィールドをクリックします:
- 機会がすでに存在する場合、機会名をクリックします。
  - 登録を承認する予定の場合、承認フローまたは General Information セクションの Primary チェックボックスをクリックします。
  - 登録を却下する予定の場合、Primary チェックボックスをクリックしません。
- 一致する機会がない場合、DR Approval セクションの Create a new Opportunity instead? トグルをクリックするか、Linked Opportunity フィールドの + New Opportunity オプションをクリックし、Opportunity Record Type として「Standard」を選択します。必要な機会の情報を入力し、「Save」をクリックします。その後、承認フローまたは General Information セクションの Primary チェックボックスをクリックします。
このプロセス中に新しい機会を作成した場合（上記のステップ 5 を参照）、Change Owner ドロップダウンオプションを使用して、新しい機会の Opportunity Owner を顧客アカウントを所有する Sales Rep に更新します。

最終レビューと対応を行う Regional Director (RD)（Ecosystem Sales Manager によって承認された場合）

登録がレビューと承認のためにあなたのキューに入ると、承認リクエストのメールを受け取ります。メールまたは Deal Registration View/Deal Registration Approval View のリンクをクリックします。
登録の最終的な承認または却下を行う前に、Ecosystem Sales Manager と GitLab Sales Rep との足並みの統一を確認します。
登録の上部にある DR Approval セクションに移動します。
Approve、Deny、または Return オプションを選択します。該当する場合は、Comments フィールドにパートナー向けのメッセージを追加します。Next を選択してプロセスを完了します。 deal registration フォームは見積もりツールではなく、見積もりの作成に必要なすべての情報を含んでいるわけではありません。GitLab Sales Rep は、見積もりを作成する前に、必要な情報をリクエストするためにパートナーと連絡を取る必要があります。

Service Attached Registration

GitLab は、自社のプロフェッショナルサービスを顧客環境に販売する Select パートナーおよび Designated Professional Services Partner（PSP）にインセンティブを提供します。パートナーは、Partner Portal で Service Attached Registration を通じてサービス機会を送信する必要があります。Service Attached の資格は、サービスパートナーを通じたライセンス購入を必要としません。顧客は、GitLab から直接、サービスパートナーを通じて、または他のパートナーからライセンスを取得できます。

Service Attached Registration の承認要件については、プログラムガイドラインを参照してください。承認された Service Attached Registration を持つ Select パートナーと PSP は、四半期ごとのバックエンドリベートの対象となります。GitLab セラーは、Designated Professional Services Partner（PSP）からの Service Attached Registration の承認時に、パートナーサービス報酬の対象となります。詳細は GitLab Sales Commissions Internal Handbook を参照してください。

該当する GitLab ソフトウェア機会の Service Attached Registration がどのように処理されるかを理解するには、以下の手順を確認してください。

最初のレビューと対応を行う Ecosystem Operations

Ecosystem Operations は、Status = New のときに登録をレビューおよび更新する最初のアクションを担います:

Customer Account をリンクする
関連するソフトウェア機会をリンクする
リンクされた機会に 承認された Service Attached Registration がないことを確認する。追加の登録は却下されます
Status を Pending Approval に設定する
リンクされた機会の Service Attach Registration に Registration Name を追加する
リンクされた機会に Service Attach Partner を追加する

パートナーが締結済みの Statement of Work を送信する

パートナーは、締結済みの Statement of Work と Deal ID を [email protected] にメールします。Statement of Work（SOW）は GitLab Partner Program の要件を満たす必要があります。

2 回目のレビューと最終対応を行う Ecosystem Operations

Ecosystem Operations はパートナーの SOW をレビューし、登録を以下のいずれかのステータスに移行します:
- Pending Approval: 追加の情報または文書が必要です。Ecosystem Operations は登録を Pending Approval ステータスのままにし、必要な文書を取得するためにパートナーと協力します。
- Approved - Open: パートナーの SOW が (i) 送信され、かつ (ii) プログラム要件を満たしているが、関連するソフトウェア機会がまだ closed-won になっていない
- Approved - Closed-Won: (i) SOW が送信され承認され、(ii) 機会が closed-won になり、(iii) その他すべてのプログラム要件が満たされている
- Accepted: PSP の対象となるが、リベートの対象とはならない。登録送信から 12 ヶ月以内に SOW が署名・送信された有償のサービスエンゲージメントと、closed-won の Net ARR 機会。
- Unqualified: GitLab Partner Program で定義された Service Attached プログラムの対象とならない登録および/または SOW
- Approved - Closed Lost: 機会が Closed-Lost に移行した場合、またはパートナーや ESM がパートナーがサービスビジネスを受注しなかったと伝えた場合
Ecosystem Operations は、登録がいずれかの Approved ステータスに移行したときに Service Attach Approval Date を追加します。Service Reg Approval Date は、以下の両方の要件が満たされたときに設定されます:
- 有効な締結済み SOW の受領
- 機会が Closed Won ステータス
- その他すべてのプログラム要件が満たされている

Closed Won

Service Attached Registration は、以下のすべての基準が満たされたときに Closed Won に分類され、Clari の予測に組み込まれます:

Service Attach Approval Date > 0
Service Attach Registration Status = Approved
Opportunity Stage = Closed Won
PSP Engaged = True

Most Likely

Most Likely カテゴリーは、Ecosystem Director が予測エントリーを完了した機会を捉えます。このロールアップには、Closed Won 機会と、以下の要件を満たすアクティブな取引の両方が含まれます:

Close Date が選択した四半期内にある
Partner Services Amount > $0
PSP Engaged = True

Open Pipeline

Open Pipeline は、Closed Won 機会を除外して、Most Likely と同じ基準に従います。機会は、これらの条件を満たすときにこのカテゴリーに表示されます:

Close Date が選択した四半期内にある
Partner Services Amount > $0
PSP Engaged = True
Opportunity Stage ≠ Closed Won

Clari の活用方法と Service Attached Registration に関する Salesforce レポーティングのレビュー方法のデモについては、以下の Additional Resources のリンクを確認してください。

追加リソース

Partner Rebate Exception Review プロセス

リベートは一般に Partner Sourced ビジネスのみを対象としていますが、GitLab が、異なる結果につながった Sourced のような活動に対してパートナーにリベートを提供したいコーナーケースがある場合があります。リベートの例外をリクエストするには、以下の Partner Rebate Exception Review Process を使用できます。

Ecosystem Programs チームと GTM FP&A は、四半期の最終月の 15 日まで Partner のリベート例外リクエストを収集します
四半期の最終月の 15 日頃に、GTM FP&A、Ecosystem Programs、Ecosystem Operations、Ecosystem Strategy、Ecosystem Sales Leadership が各ケースをレビューするために集まります。考えられる結果には以下が含まれます:
- リベートリクエストの却下
- Global Ecosystem 予算で資金提供されるリクエストの承認
- 関与するアカウントチームの予算で資金提供されるリクエストの承認
結果はレビュー後にあなたとあなたのリーダーに共有され、Chatter を通じて文書化されます。リクエストが承認された場合、リベートは新しい四半期の開始から 45 日以内に支払われます。

Partner Influence

パートナーは、取引を行わずに GitLab の機会に影響を与えることができます。Partner Team（ESM、Cloud ESM、または SA）は、パートナーの影響活動を追跡するために、社内の Partner Influence レコードを送信できます。

パートナーの影響活動には、以下の方法での顧客エグゼクティブのエンゲージメントとアドボカシー、および/または顧客の追求における GitLab との協働が含まれます。

顧客の意思決定者/C-Suite への紹介
GitLab を擁護するエグゼクティブブリーフィングのホスト/参加
GitLab を積極的に擁護する信頼されるエグゼクティブまたはテクニカルアドバイザー
better together（より良い相乗効果）のソフトウェア販売の一環として GitLab を紹介および/またはポジショニングする
プレゼンテーション、デモ、POC、または RFP への回答を提供する
GitLab を推奨する顧客戦略を提供する
顧客戦略/ユースケース/ペインポイントについて GitLab のアカウントチームに助言する

機会に対するパートナーの影響を追跡するには、以下の手順に従います。

機会ページの上部にある Related List Quick Links から、Influence Partners にカーソルを合わせ、New Influence Partner を選択します
ルックアップボタンを使用して Influence Partner フィールドにパートナーを追加します
該当する Influence Type を選択します:
- 顧客エグゼクティブのエンゲージメントとアドボカシー
- 顧客の追求における GitLab との協働。
Influence Details を使用して、該当する 1 つ以上のパートナーの影響活動を選択します:
- 顧客の意思決定者または C-Suite への紹介
- GitLab を擁護するエグゼクティブブリーフィングのホストまたは参加
- GitLab を積極的に擁護する信頼されるエグゼクティブまたはテクニカルアドバイザー
- better together（より良い相乗効果）のソフトウェア販売の一環として GitLab を紹介および/またはポジショニングする
- プレゼンテーション、デモ、POC、または RFP への回答を提供する
- GitLab を推奨する顧客戦略を策定する
- 顧客戦略/ユースケース/ペインポイントについて GitLab のアカウントチームに助言する
Description of Partner Influence を使用して、パートナーの影響活動の詳細な説明を提供します
Opportunity Owner、ASM、Ecosystem Sales Manager、Customer Account を編集しないでください。これらは保存時に自動入力されます
Influence Partner レコードを Save します
Google Docs, Notes, & Attachments セクションを通じて、機会に対するパートナーの影響を際立たせるサポート文書を添付します。

Channel 承認

機会の Channel Approver は、Opportunity Owner の User Region に基づきます。承認者が変わるたびに、古い承認者を新しい承認者に置き換えるため、Sales Systems で Issue をオープンする必要があります。現在の channel approver は、私たちの channel approver matrix で確認できます。

承認者が PTO やその他の理由で機会を承認できない場合、自分に代わって機会を承認する delegate を割り当てる必要があります（SFDC 内で）。

Letters of Authorization

パートナーが Letter of Authorization（「LOA」）を必要とする場合、partner portal にログインし、「Common Requests」ページの「Request a Letter of Authorization」ボタンからリクエストする必要があります。パートナーがポータルにログインしない場合、このリクエストにアクセスできません。これにより、認定パートナーのみがリンクにアクセスし LOA をリクエストできるようになります。

パートナーは、LOA を自動入力する基本的な会社情報の入力を求められます。送信すると、LOA は、LOA をリクエストしているエンティティが有効かつ authorized なパートナーであることをレビュー・確認するために、自動的に Ecosystem Operations チームに送信されます。Ecosystem Operations によって承認されると、LOA は自動的に legal team に送信され、legal team が LOA を承認しイニシャルを記入した後、GitLab の PAO に署名のために送信します。署名されると、LOA はメールで直接パートナーに送信されます。レターは、レターに記載された日付から 1 暦年間有効です。

プログラムとインセンティブの定義

GitLab Ecosystem Program は、パートナーのプログラムステータスと、アクティブな deal registration があるかどうかに基づいて、パートナーに設定された値引きを提供します。
パートナーが deal registration とプログラムの値引きの対象となるには、少なくとも 1 名のパートナー従業員が GitLab Foundations for Partners トレーニングを修了する必要があります。
GitLab 従業員は、パートナー値引きのガイダンスにここからアクセスできます
パートナーは、GitLab Partner Portal の Asset Library で値引き表を見つけることができます。

チャンネルパートナー価格ファイル

以下の価格ファイルは、Partner Ops が Google Sheet、Excel、PDF 形式で提供します。

Resale 機会向けの Distribution Price Files。メインプログラムのリセラーおよびディストリビューターの値引きを含みます。
Resale 機会向けの Public Sector Price Files。メインプログラムのリセラーおよびディストリビューターの値引きを含みます。
Resale 機会向けの Partner (Direct Reseller) Price Files。メインプログラムのリセラーの値引きを含みます。
値引きのない List Price File。

価格ファイルへのアクセス方法（パートナー）

ディストリビューターとリセラーのパートナーは、現在の GitLab 価格ファイルについて Partner Portal にアクセスできます。Partner Portal へのアクセスに問題がある場合は、[email protected] で Ecosystem Operations チームに連絡してください。

価格ファイルへのアクセスと共有の方法（GitLab チームメンバー、社内利用のみ）

Channel 価格ファイルをパートナー（ディストリビューターまたはリセラー）と共有する際は、Channel 価格ファイルのフォルダーまたはファイルの場所を共有しないでください。価格ファイルを共有するには、ディストリビューターまたはパートナーに Partner Portal にログインし、メニューで Asset Library を選択して「Price File」を検索するよう案内してください。パートナーは、この経路で最新の Channel 価格ファイルにアクセスしダウンロードできます。

社内利用向けの価格ファイルと Ecosystem Discount Calculator は、このフォルダーで見つけることができます。

価格ファイル更新プロセス

各四半期の 2 ヶ月目の初めに、Ecosystem Operations は Issue を作成し、製品およびプロフェッショナルサービス（PS）の部門にタグを付けて、部品番号の新しい変更、追加、廃止に関する情報を収集します。次の四半期の初日にアクティブになる SKU に関するありとあらゆる情報を提供することは、製品/PS 部門の責任 です。

この情報を収集するために、以下の部門/人物にタグが付けられます。

Professional/ Education Services - Brian Will, Sean Sandoval
Channel Services - Boughty Canton
Product/Finance - Brian Wong, Justin Farris
Fulfillment - Courtney Meddaugh
Partner Programs & Enablement - Ed Cepulis（既存/新規のチャンネル/ディストリビューターの値引きへの変更）
Customer Success Management - Sherrod Patching

FYI/追加のインプットのために、以下の部門/人物にタグが付けられます。

Ecosystem Operations: Marcella Summers
Partner Programs: Ed Cepulis
Deal Desk: Jesse Rabbits
PubSec Channel: Pilar Meija
Business Technology: Caroline Swanson

次の四半期向けに価格ファイルが更新されると、Partner Support はファイルを Partner Portal にアップロードし、新しい四半期の 30 日前に以下のディストリビューターにメールで共有します。

Carahsoft
Amazic
Tech Data (APAC)
Redington
Get On Technology
Climb Solutions
Networld

ファイルに更新がない場合は、バージョン変更タブに文書化されます。

アシスタンスについては #partner-programs-ops Slack チャンネルに連絡してください。

*コア GitLab 製品（Ultimate と Premium）の更新については例外が認められる場合があります。

価格ファイルの社内コミュニケーション

Partner Support は、Slack チャンネル #partner-fyi にメッセージを投稿して、更新された価格ファイルを共有し、主要な変更を強調します。

SFDC Channel Manager アクティビティトラッカー

Channel Manager は、Salesforce の追跡システムを使用して、自分のセールスおよびマーケティング活動を記録します。このトラッカーにより、セールス分析と目標設定（QBR、OKR、Business Plans、1:1）のためのデータを抽出できます。さらに、エンゲージメントの基準を設定し、GitLab のパートナーとの関係をさらに発展させるためのアクティビティフレームワークを作成できます。このアクティビティトラッカーは、すべての Channel Manager が利用できます。

GitLab Ecosystem Certification Dashboard

GitLab Ecosystem Certification Dashboard は、パートナーと地域別の認定と認証のジャーニーの包括的な概要を提供するインタラクティブなスコアカードです。

ダッシュボードの機能:

Partner Scorecard は、GitLab パートナーの認定合計の全体的なビューを提供します。四半期とバッジで掘り下げることができます。
Regional Scorecard は、バッジ別、およびパートナーとユーザー別の認定数を提供します。国、四半期、バッジで掘り下げることができます。
PSE Vouchers Used タブには、パートナーの PSE バウチャーコードと有効期限が一覧表示されます
PSP Eligibility タブは、各パートナーの PSP とコンプライアンスのステータスへの可視性を提供します

Partner Account Mapping

私たちの Cloud および Resale パートナーの担当者は、自分のテリトリーで共有されているアカウントを特定するために、自分の ESM との共同アカウントマッピングをしばしばリクエストします。アカウントマッピングのデータ抽出をリクエストするには、以下の手順を使用できます。

ESM またはパートナーが Account Mapping Template に入力し、GitLab ESM に送信します。アカウントマッピングツールが結果をレンダリングするには、Account Name と Domain（A 〜 B 列）が必須です。
ESM は、パートナーマッピングのデータ実行をリクエストするために、アカウントマッピングテンプレートを #global-ecosystem-programs-ops に送信します。
Ecosystem Specialist は、[Confidential] [Internal DI Only] Account Mapping 2026 シートを通じてアカウントマッピングテンプレートを実行します。このドキュメントは SAFE 要件のため、ecosystem specialist チームにのみ表示されます。
Ecosystem Specialist は、結果を 2 つのドキュメントにコピーします:
- hyperscaler のアカウント担当者と共有できるスタンドアロンの g-sheet ドキュメント。
- マスターの [INTERNAL ONLY] Account Mapping Results シート。これはすべてのアカウントマッピングリクエストの社内専用ビューです。各リクエストに対して、命名規則 MM/DD/YY - [Requestor] で新しいタブが作成されます。
Ecosystem Specialist は、次のユーザーのために準備できるよう、Account Mapping Template と Account Mapping シートをクリアします。
ESM は、結果を自分のアカウント担当者と共有します。

Partner Insights

Ecosystem Operations チームは、パートナーの Business Plan の作成や QBR・パートナーミーティングの準備を支援するため、Partner Insights データを Ecosystem Sales Manager に提供します。これらのインサイトは、Ecosystem Sales Manager がパートナーと生産的な会話を行い、うまくいっていることを特定して再現できるようにするとともに、より強力で価値あるパートナーシップを発展させるための改善の機会に対処できるようにすることを目的としています。

Ecosystem Sales Manager は以下のことができます:

このセルフサービスのスプレッドシートにアクセスして、自分の Partner Insights データを生成する。選択したパートナーのチャートとメトリクスを含む PDF を生成するには、スプレッドシートの最初のタブの手順に従ってください。
このステップバイステップガイドにアクセスして、Partner Insights PowerPoint を作成する。
チャットで /Partner QBR と入力して、データが入力済みの QBR テンプレートを生成する。Claude が利用可能なデータを使って事前入力します（慎重にレビューしてください）。AI 生成コンテンツには誤りが含まれる可能性があります。

セットアップ（初回のみ）： このスキルをダウンロードし、Claude → Customize から Skills フォルダに追加します。

スプレッドシートまたは PowerPoint のステップバイステップガイドへのアクセスについてアシスタンスが必要な場合は、Slack の #partner-program-ops で連絡してください。セルフサービスのスプレッドシートにないカスタマイズされたレポーティングリクエストがある場合は、Ecosystem Operations ボードで Issue をオープンしてください。

Partner Award プログラム

GitLab Partner Awards は、毎年授与されます。提出物や応募は募集されません。パートナーは、以下に概説する公表された授賞基準に基づいて評価されます。

結果は、2 月から 1 月まで実施される直前の GitLab の会計年度に基づいて評価されます。すなわち、FY25 Awards は FY24 のデータに基づいて評価されます。すべての賞は、発表前に地域の Channel ディレクターと VP of Global Channels and Alliances によって承認される必要があります。

受賞者は、物理的な賞、パートナーのウェブサイトやソーシャルメディアで使用するバーチャルバッジ、および GitLab によるオンラインプロモーション（ブログ投稿やソーシャルメディアでの発表を含む場合があります）を受け取ります。

アワードプログラム DRI:

Channel Program DRI
- Channel Program Director が受賞者を決定するために分析する SSOT からデータを募ります
Channel Sales DRI
- Director と VP of Global Channels and Alliances が受賞者を推薦・承認します
- Director が、PR 活動やプレゼンテーションに含めるための受賞者に関する短い記事を提供します
Channel Marketing DRI
- 賞の発注と発送を管理します
- PR アシスタンスのための Issue を作成します
Corporate Communications DRI
- 受賞者を発表するプレスリリースまたはブログ投稿を作成します

アワードカテゴリ - FY25 向けに提案:

Americas と Public Sector カテゴリー
- AMER Partner of the Year
- AMER Emerging Partner of the Year（任意）
- AMER Services Partner of the Year
- Public Sector Partner of the Year
- Public Sector Services Partner of the Year
- AMER / Public Sector Distributor of the Year
Asia-Pacific カテゴリー
- APAC Partner of the Year
- APAC Emerging Partner of the Year（任意）
- APAC Distributor of the Year
- APAC Services Partner of the Year
Europe-Middle East-Africa カテゴリー
- EMEA Partner of the Year
- EMEA Emerging Partner of the Year（任意）
- EMEA Distributor of the Year
- EMEA Services Partner of the Year

アワード検討タイミング: GitLab は、Q1 の期間内にグローバルレベルのイベントで Partner Award の受賞者を発表します。賞は、発表後 4 〜 6 週間で受賞者に発送されます。授賞の祝賀は、Partner Leadership Summit またはその他の類似のイベントで開催されます。

アワード基準（直前の FY から取得）: GitLab Ecosystem Operations チームは、SFDC の SSOT データから、以下の基準に概説されたレポートを編集する責任を負います。Channel Sales Director と VP of Global Channel and Alliances が、以下に概説された基準に基づいてこれらのレポートをレビュー、評価、査定します。

[地域別] Partner of the Year
- 総収益
- Partner Sourced - 承認された deal reg
- 新規ロゴ
- 優れた取引、サービス提供、キャンペーン、フィールドでの協働の例
[地域別] Emerging Partner of the Year（任意の賞）
- 急速な収益とパイプラインの成長
- 急速なサービスエンゲージメント
- 優れた取引、サービス提供、キャンペーン、フィールドでの協働の例
- 新規パートナー、または前年に急速に立ち上がった既存パートナーである場合があります
[地域別] Services Partner of the Year
- Professional Services の下請けデリバリー - GitLab Services の収益への影響
- service attach deal registrations
- GitLab サービスオファー - オファーの数、オファーの品質、オファーに対する GitLab セールスのエンゲージメントのレベル
[地域別] Distributor of the Year
- 総収益
- Open パートナーのコンプライアンス改善
- 準拠しているパートナーの数
- 認証の数
- 生成されたパイプライン

Partner SWAG リクエスト

パートナー向けに MDF 以外の SWAG をリクエストするには、以下のガイドを参照してください。

Ecosystem Operating Dashboard

以下の Ecosystem ダッシュボードが FY27 向けに公開されました。Salesforce の権限に基づいて、自分の地域のデータのみを閲覧できます。

FY27 QTD Ecosystem Metrics Dashboard

Alliances と OEM

GitLab Alliance Team の概要については、Alliances Handbook をご覧ください。GitLab 従業員であれば、Private Alliance Handbook も利用可能なリソースです。Alliances Salesforce Dashboard も利用できます。 Alliance パートナーに関する質問については、#cloud-aws または #cloud-gcp Slack チャンネルに連絡してください。お問い合わせが取引固有のものである場合は、以下のいずれかの Slack チャンネルを使用してください: #a_gcp_deal_registration, #a_aws_deal_registration, #a_ibm_deal_registration。

マーケットプレイス取引の Opportunity タギング

ユースケース 1: Partner Co-Sell（ソースクレジットのないマーケットプレイス取引）

取引が GCP Marketplace または AWS Marketplace を通じて行われる場合、機会で以下のフィールドを入力する必要があります。

Resale Partner = GCPまたは AWS *正しい SFDC アカウントを必ず使用してください。リンクをクリックして GCP および/または AWS アカウントを確認してください。)

ユースケース 2: Partner Sourced Deal Registration（マーケットプレイス取引なし）

GCP または AWS が私たちにリードを持ち込んだ/GitLab に取引を紹介したが、Marketplace で取引しない場合、機会で以下のフィールドを入力する必要があります。

DR - Partner は GCP または AWS アカウントを使用して入力する必要があります
DR - Partner Deal Type = Referral

ユースケース 3: Partner Sourced Deal Registration（マーケットプレイス取引） GCP または AWS が私たちにリードを持ち込んだ/GitLab に取引を紹介し、Marketplace で取引する場合、機会で以下のフィールドを入力する必要があります。

DR - Partner は GCP または AWS アカウントを使用して入力する必要があります
DR - Partner Deal Type = Resale

ユースケース 4: Partner Influence（マーケットプレイス取引なし、ソースクレジットなし）

GCP または AWS が取引をサポートし、顧客が GitLab を購入するよう後押しするが、機会の元のソースでもなく、取引も行わない場合、機会で以下のフィールドを入力する必要があります。

Influence Partner は GCP または AWS アカウントを使用して入力する必要があります

マーケットプレイス取引の Quote タギング

取引が Google Cloud Marketplace を通じて行われる場合、見積もりで以下の値を使用します:
- Invoice Owner = Google Cloud Marketplace
- Invoice Owner Contact = Cloud Marketplace Payments 注: このフィールドに入力する正しいコンタクトを見つけるには「Payments」（引用符付き）を検索してください)
- Resale Partner = Google Cloud (Partner)
取引が Amazon Web Services Marketplace を通じて行われる場合、見積もりで以下の値を使用します:
- Invoice Owner = Amazon Web Services, Inc.
- Invoice Owner Contact = Accounts Payable (AWS)
- Resale Partner = Amazon Web Services

Distributor Seller of Record (DSOR) の AWS Marketplace 取引の Opportunity タギング

AWS の Distributor DSOR（Distributor Seller of Record）Program は、ISV クライアントに 3-Tier のチャンネルイネーブルメントを提供し、AWS Marketplace を通じてビジネス成長を拡大するために設計されたパートナープログラムです。このプログラムの下では、GitLab Distributor が AWS Marketplace に GitLab の製品を掲載し、プライベートオファーの販売モーションを推進します。ディストリビューションパートナーが販売機会を発展させ、AWS Marketplace 内の Consulting Partner に顧客へのプライベートオファーのリリースを承認します。

GitLab DSOR プログラムを通じて取引する取引については、見積もりを以下のように設定する必要があります。

Distributor = 機会に取り組むディストリビューター
Resale Partner = 機会に取り組むリセラー
CPPO, MCPO, or DSOR Partner フィールド = Amazon Web Services

ディストリビューション取引の見積もりに関する詳細情報/手順については、この Deal Desk ハンドブックのセクションまたはこの社内のディストリビューターオンボーディングと請求プロセスのガイドを参照してください。

IBM (OEM) パートナーリクエストと QTC プロセス

IBM (OEM) Quote to Cash プロセスのステップバイステップガイドについては、IBM (OEM) Partner Requests & QTC Process を参照してください。

Channel Partner Private Offers（CPPO と MCPO）

AWS CPPO プログラムとプロセスの詳細情報については、以下のプログラムガイドとプロセスガイドを参照してください。
GCP MCPO プログラムとプロセスの詳細情報については、以下のプログラムとプロセスのガイド。を参照してください

マーケットプレイスプロバイダーへの Opportunity の登録

パートナーが GitLab に機会を登録するのと同様に、Ecosystem Sales Manager は、自分のマーケットプレイス機会を見込みのあるクラウドプロバイダーに登録すべきです。AWS と GCP に登録を送信する手順を以下に示します。

Amazon Web Services

AWS の登録は、Tackle Cosell インテグレーションを使用して、SFDC の機会を通じて直接受領、送信、管理できます。手順は Tackle Co-Sell | How To Guide で確認できます。

Google Cloud

GCP の登録は、GCP チームによって GitLab に代わって送信されます。GCP に新しい機会を登録するには、以下のリンクをクリックしてフォームに入力してください。

New GitLab Opportunity Registration for GCP

Ecosystem 機会の報酬

締結済みの報酬レターが、報酬に関する承認済みかつ正式な信頼できる唯一の情報源であるべきです。ただし、明確化や例外については以下のリソースを使用してください。

Sales Commissions Internal Handbook

FY25 Partner Comp Exception Process

パートナー FAQ - GitLab との販売

このページでは、販売プロセス全体を通じて GitLab と協業する方法について、パートナーコミュニティからよく寄せられる質問をまとめています。ご質問や、このページに別の Q&A の掲載を希望 …

GitLab セールス FAQ - パートナーとの販売

このページでは、販売プロセス全体を通じてパートナーと協業する方法について、GitLab セラーからよく寄せられる質問をまとめています。ご質問や、このページに別の Q&A の掲載を希望される場 …

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)

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