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

GitLab には、リセール、MSP、リファラルの商談を対象とした Partner Sourced Deal Registration（DR）プログラムがあります。GitLab に新規ビジネスをもたらしている商談については、パートナーが Partner Sourced DR を提出する必要があります。これは新規ロゴ、コタームでのアドオン／アップセル、または更新の一部としてのアドオン／アップセル商談に適用できます。なお、1 つの商談に対して承認できる Partner Sourced DR は 1 件のみです。これは、1 件のディールをソーシングできるパートナーは 1 社のみであるためです。パートナーは商談をソーシングしていない場合に Partner Sourced DR を提出するべきではなく、通常はこれらのディールに対して Co-Sell 割引を受けることになります。パートナープログラム割引に関する詳細は、GitLab の Internal Incentive Guide をご参照ください。

GitLab には Service Attach DR プログラムもあり、これは GitLab 製品の販売時にパートナーが自社のプロフェッショナルサービスを顧客環境に販売する商談に適用されます。

パートナー担当者がパートナーポータルアカウントを持っているもののログインできない場合、「Forgot Password」を選択してパスワードをリセットできます。パートナーポータルアカウントを持っていない場合は、「Request Portal Access」を選択してアカウントを作成できます。手順に従っても問題が解決しない場合は、パートナー担当者に [email protected] まで連絡するよう案内してください。

なお、ディール登録を提出するには、まず認定された GitLab パートナーであり、かつ DR を提出するためのアクセス権を付与されるために必要なトレーニングを完了している必要があります。

はい、期限切れの DR は、チャネルアカウントマネージャーが 30 日間延長できます。DR の延長を依頼するには、チャネルアカウントマネージャーに chatter してください。30 日を超える延長が必要な場合は、@Partner Operations に chatter し、登録の新しい有効期限を提示してください。

DR に割り当てられたチャネルアカウントマネージャー（CAM）が DR をレビューし、追加情報／背景の提供のためリセールパートナーに差し戻したことを意味します。リセールパートナーが CAM のフィードバックを確認して回答すると、CAM に通知が送られ、更新された DR をレビューしてアクションを取ります。

DR 情報は商談内の 2 箇所で確認できます:

• 商談の上部にある「Related list quick links」セクション内の「Registrations」セクション。このセクションには、承認済み、期限切れ、却下、保留中の Partner Sourced DR と Service Attach DR を含め、商談に紐づいたすべての DR が含まれています。

• 商談本体の「Partner Sourced Deal Registration」セクション。承認された Partner Sourced DR が表示されます。

商談の「Primary Quote Partner Details」セクションをご参照ください。プライマリ見積のパートナー情報が表示されます。

商談の SQS は、(i) 承認された Partner Sourced ディール登録がある場合、または Initial Source が Partner Qualified Lead の場合に「Partner Generated」になります。詳細については、パートナーオペレーションハンドブックをご参照ください。

パートナー割引、インセンティブ、リベートプログラム等に関する情報が掲載されている Internal Incentive Guide をご参照ください。

製品とサービスのパートナープログラム割引については、Internal Incentive Guide をご参照ください。

商談が新規ビジネスまたはアドオン／アップセルの場合:

• パートナーがソーシングした商談（更新商談の一部としてライセンスを追加する場合を含む）については、パートナーが Partner Sourced ディール登録（DR）を提出する必要があります。GitLab CAM と ASM が DR を承認した後、ディールの新規またはアドオン部分について DR パートナーに Partner Sourced 割引を提供できます。
• パートナーがソーシングしていない商談については、通常パートナーは Co-Sell 割引を受けることになります。

商談がフラットな更新の場合は、パートナーの既存契約権に関するルールについて、パートナーオペレーションハンドブックをご参照ください。

見積のパートナープログラム割引に関する情報は、Internal Incentive Guide をご参照ください。

GitLab のチャネルニュートラルな報酬ポリシーをご参照ください。ポリシーを確認した上で特定の商談についてご質問があれば、Sales Compensation チームまでお問い合わせください。

• リセラー - GitLab がリセラーに見積（つまり販売）し、リセラーがエンドカスタマーに見積を提示します。これは一般的に 1 ティア、またはリセラー直販ディールと呼ばれます。
• ディストリビューター - GitLab がディストリビューターに見積（つまり販売）し、ディストリビューターがリセラーに見積を提示し、リセラーがエンドカスタマーに見積を提示します。これは一般的に 2 ティアディストリビューションディールと呼ばれます。
• MSP - GitLab が MSP パートナーに見積を提示します。MSP パートナーは、エンドカスタマー（MSP エンドユーザー）が使用するライセンスを購入、所有、管理します。

ディストリビューションを活用する利点の詳細については、パートナーオペレーションハンドブックをご参照ください。

ディストリビューターの要件と地域・市場別のカバレッジの詳細については、パートナーオペレーションハンドブックをご参照ください。

パートナー見積プロセスの概要、およびステップバイステップの見積ガイド等の主要リソースへのリンクについては、パートナーオペレーションハンドブックをご参照ください。

見積は顧客ではなくパートナーに送信する必要があります。具体的には:

• リセラー直販の場合、リセラー担当者にのみ見積を送信してください（顧客を CC に入れないようにしてください）。
• ディストリビューション経由の場合、ディストリビューター担当者にのみ見積を送信してください（リセラーや顧客を CC に入れないようにしてください）。ディストリビューションの連絡先情報については、パートナーオペレーションハンドブックをご参照ください。

パートナーアカウントレコードに請求情報を追加または更新する方法の詳細については、パートナーオペレーションハンドブックをご参照ください。

パートナー見積上の Invoice Owner と Invoice Owner Contact は、それぞれパートナーの請求アカウントと請求アカウント担当者のレコードを表します。SFDC でこれらのレコードを見つけて見積に使用する方法の詳細については、パートナーオペレーションハンドブックをご参照ください。

未認定のリセラーに見積を提供することはできません。リセラーが GitLab 見積を受け取れるよう、パートナーとして登録するよう促してください。これが不可能な場合、商談オーナーおよび／またはチャネルアカウントマネージャー（CAM）は商談に法務ケースを作成し、パートナーが GitLab と取引するための一回限りの認可を依頼できます。リクエストがレビューされて承認された場合、Legal は商談オーナー、CAM、Sales Support と協力し、一回限りの認可を提供するために必要な手順を進めます。

パートナーアカウントが「Prospect」ステータスになっているのは、パートナーがまだ当社のパートナー契約に署名していない、または必須の販売トレーニングを完了していないためです。SFDC でパートナーアカウントを所有するチャネルアカウントマネージャーに連絡し、パートナーを認定するための作業を進めてもらうよう依頼してください。

見積作成時にレガシー／オフラインの承認を依頼するため、Cloud Licensing ガイドの手順に従ってください。

非標準の支払条件の適用に関する詳細は、Deal Desk ハンドブックと承認マトリクスをご参照ください。

見積をクローンする方法の詳細については、Deal Desk ハンドブックをご参照ください。

はい、見積を承認から取り下げるガイダンスについては、Deal Desk Handbookをご参照ください。

はい、2 ティアディールでは、当社の契約／サブスクリプションレコードはリセラーではなくディストリビューターと結ばれます。顧客、ディストリビューター、アカウントチームが 2 ティアディールのコタームアドオンでリセラーを変更する必要がある場合、GitLab は変更に対応できます。

はい、顧客がメールで正式に連絡し、更新で新しいリセラーと取引したいことを確認した場合、既存契約権の割引を移管できます。詳細については、パートナーオペレーションハンドブックをご参照ください。

はい、更新時に顧客の全体ライセンス数を正確にするためには、GitLab が更新見積を生成する前にアドオンライセンスを完全に処理する必要があります。詳細については、Deal Desk ハンドブックをご参照ください。

はい、更新処理中に顧客のアクセスが失われるのを防ぐため、内部サポートチケットを提出して一時的なライセンスを依頼できます。

パートナー商談の計上要件については、Sales Order Processing ハンドブックをご参照ください。

既存の見積の有効期限を延長するガイダンスについては、Deal Desk ハンドブックをご参照ください。

四半期末計上に関する Sales Order Processing ハンドブックのガイドラインをご参照ください。

ECCN については、Trade Compliance ハンドブックに記載されています。

請求書は商談クローズの 24〜48 時間後に送付されます。

プライマリ見積の Invoice Owner Contact が GitLab 請求書を受領し、Invoice Owner の Sold To Work Email が POD（つまり、フルフィルメントからの顧客プロビジョニングメールのコピー）を受領します。なお、これら 2 つの担当者は見積上で揃っている必要があります。Invoice Owner Contact（つまり、請求アカウント担当者）は Invoice Owner（つまり、請求アカウント）から作成され、その詳細と一致している必要があるためです。パートナー請求レコードとパートナーディールの見積への適用方法の詳細については、パートナーオペレーションハンドブックをご参照ください。

注意: 2 ティアディールでは、ディストリビューターが GitLab から請求を受けるため、ディストリビューターが POD を受け取ります。リセラーがディストリビューション経由で購入した場合は、POD を取得するためにリセラーをディストリビューターにつないでください。

これは GitLab 営業担当者またはパートナーのいずれかが実行できます:

• GitLab 営業担当者は、内部サポートチケットを提出し、サポートチームに同じエンドユーザー担当者への購入確認メール送信を依頼できます。
• GitLab 請求書を受領したパートナー（つまり、2 ティアディールの場合はディストリビューター、1 ティアディールの場合はリセラー）は、GitLab 請求書を添付してサポートチケットを提出し、同じエンドユーザー担当者への購入確認メールの再送を依頼できます。

GitLab 請求書を受領したパートナー（つまり、2 ティアディールの場合はディストリビューター、1 ティアディールの場合はリセラー）が、GitLab 請求書を添付してサポートチケットを提出し、新しいエンドユーザー担当者への購入確認メールの送信を依頼する必要があります。

重要: GitLab 営業担当者は、パートナーや顧客に代わって販売後のエンドユーザー担当者を変更することはできません。エンドユーザー担当者の変更依頼は、(i) 上述のとおり GitLab の請求書を受領したパートナー、または (ii) 最終的な見積に Sold To Contact として記載されている顧客担当者（つまり、ライセンスを受け取った人物）が提出する必要があります。

クローズドウォンの商談に対してオフラインまたはレガシーライセンスキーを提供するため、SFDC chatter を介して VP に承認を依頼してください。VP の承認が得られた場合、内部サポートチケットを提出し、顧客への更新ライセンスの発行を依頼してください。

顧客は、当初の注文と同じ調達経路で Compute Minutes を追加する必要があります（つまり、パートナー経由で当初のサブスクリプションを購入した場合、追加分も同じパートナー経由で購入する必要があります）。次の手順を実行してください:

1. 調達プロセスを開始します。チャネルディールの場合、GitLab Sales がパートナーに追加 Compute Minutes の見積を提供します。AWS／GCP ディールの場合、GitLab Sales が追加 Compute Minutes のプライベートオファーを顧客に対して生成します。
2. GitLab Sales は内部サポートチケットを提出し、GitLab の調達サイクルが完了するまで顧客がオンラインに復帰できるよう、サポートチームに顧客のインスタンスへの分の追加を依頼します。内部サポートチケットを提出するには、Other> Other License & Renewals Related Issue request type を使用し、迅速なレビューと承認を促すために可能な限り多くの情報をリクエストに記載してください（例: 顧客はロックアウトされており、パートナー経由で購入しているため当社の調達サイクルを待つ必要がある、オンライン復帰のため追加の分数が必要）。

重要: サポートチームは Compute Minutes を追跡したり削除したりしないため、GitLab Sales は販売処理を待つ間に必要な期間をカバーする控えめな分数を依頼すべきです。