Ecosystem Operations

Welcome to the Ecosystem Operations Page

Vision

To build, operate, and advise a world-class partner business.

Mission

Listen to the needs of GitLab teams, partners, and customers, and respond with innovative and streamlined processes, tools, and resources to operate a scalable and highly profitable business for GitLab and our partners.

Key Tenets

Efficiency and Productivity: Streamline partner systems, processes, and workflows to improve ease of doing business and drive mutual profitability and positive experience for GitLab and our Partners.

Scalability: Build, deploy, and manage reliable and effective operational practices that are foundational to how we go to market and adaptable to support our growing and evolving partner business.

Advisory: Trusted subject matter experts for GitLab’s internal and partner teams, providing daily operational support and guiding best practices and business decisions regarding our partner models.

How to Contact Us

The #global-ecosystem-programs-ops Slack channel can be leveraged for inquiries. Both the Ecosystem Operations Team and the Ecosystem Programs Team monitor this slack channel. If you are reporting a problem, have suggestions, or changes requests, please open an issue on the Ecosystem Operations Issue Board for operational issues, or the Channel Team’s Issue Board for program issues.

The Ecosystem Operations Issue Board

On the Ecosystem Operations Issue Board, each column represents a type of request (feature request, alliances, data & reporting, etc.). When you submit a request to the Ecosystem Operations board, the team will assign the issue and add the corresponding tags. The Ecosystem Operations Board also uses progress tags on issues to show the status of open issues. Each issue is updated regularly with notes and progress tags and should be checked before reaching out to the team for status updates.

To open an issue with Ecosystem Operations and select New Issue.

Issue Templates

Utilizing Issue Templates: In an effort to have a standard way of taking in requests from the cross-functional teams and help guide users through providing the right information to diagnose issues, the Ecosystem Operations team has created issue templates.

How to get started

1. Create New Issue

When you create a new issue, you get the option to “Choose a template”

2. Choose a template

Once a template has been selected, the description box will be populated with the content of the template ready for completion.

• Select Ad hoc Reporting for custom reporting requests.
• Select Data Upload Request for bulk updates to data.
• Select Feature Request for requesting enhancements to current systems.
• Select Partner M&A and Name Changes when requesting a partner account change related to mergers and acquisitions, merging duplicate accounts or moving them into an account hierarchy, or to change a partner account name.
• Select Procedures & HB Updates to request edits or reviews for certain procedures/processes or handbook updates managed by Ecosystem Operations, especially if more discussion is needed prior to submitting a MR for a page.
• Select Partner Funding Request to request non-MDF funding for partner events, MOUs, funded heads, SPIFFS, etc.

3. Before you submit

Please ensure you have followed the prompts to fill in the selected issue template and that your issue is unassigned. Our team will be assigning issues based on team bandwidth.

Issue Templates Video

External Partner Support and Communication

Email partnersupport@gitlab.com to include a partner or other external stakeholder for help with partner-related requests. Ecosystem Operations team members monitor the queue and email inbox throughout the day in all time zones.

Reaching Out to Ecosystem Operations in Salesforce

As of November 25, 2024 the chatter handle @Partner Operations has been deprecated. You can reach out to the Ecosystem Operations team by Requesting Internal Support in Salesforce. Please continue to refer to our respective handbooks for in-depth information before opening a new case.

Here is a general list of items you can create a case for assistance within Salesforce:

Deal Registration

• General Questions
• Unable to Approve/Error Message
• Update Customer Account
• Link Reg to a Closed Opportunity
• Linked Customer Account Employee Count/Segment Update
• Extension Requestion > 30 Days
• Link Reg to a Different Open Opportunity

Partner Account

• Training and Certification
• Partner Program Administration
• Partner Payments
• Post-Sale Support
• Update Account Owner
• Partner Account Merges, Name Changes, and Acquisitions

Opportunities

• Quote to Order/Discounts
• SQS/Opp Splits Questions
• CPPO
• Link Reg to a Closed Opportunity

Labra Referral

• General Questions

Communicating with the Partner Teams via Slack

There are a number of different slack channels to serve the different needs of the organization. Below is a list of the most common channels, as well as their uses, intended audience, and posting permissions. Please refer to this list often to ensure you’re posting information and asking questions to the appropriate channel.

Slack Channel	Description	Topic	Audience	Posting Permissions
global-ecosystem-programs-ops	Questions and comments about ecosystem programs and operations	https://handbook.gitlab.com/handbook/resellers/ and https://handbook.gitlab.com/handbook/sales/field-operations/channel-operations/	any	any
global-ecosystem-sales	Questions and comments about opportunities, partner connections, field engagement, and other ecosystem sales questions		any	any
channels-emea	A channel for the EMEA channels team and stakeholders to collaborate		any	any
channels-amer	A channel for the AMER channels team and stakeholders can collaborate		any	any
pub-sec-channels	A channel for the Pubsec channels team and stakeholders to collaborate		any	any
apac_partners	A channel for the APAC channels team and stakeholders can collaborate		any	any
channel-services	Questions and comments about channel services program, enablement and field engagement		any	any
#cloud-aws and #cloud-gcp	A channel for collaboration with the alliances Team	https://handbook.gitlab.com/handbook/alliances/	any	any

Standard Channel Practices

For detailed information on GitLab’s Channel Partner Program, visit the Channel Partner Handbook. Partners must be an Authorized GitLab Partner and have completed one sales certification to transact any GitLab products or services. To achieve authorization, partners must have an executed agreement and meet the requirements of the GitLab Partner Program. Only GitLab partners in good standing may sell GitLab products and services unless specifically approved on a case-by-case basis by the GitLab partner program team. Partners must sign up to be authorized.

Policy and Process

All Partner Co-Sell opportunities require an authorized GitLab Partner(s) to transact the deal. Deal Registration is not applicable for Partner Co-Sell opportunities. Partner Sourced Deal Registration opportunities also require an authorized GitLab Partner to transact, and must also be found/created and registered in the GitLab Partner Portal (excludes Alliances and GSIs). The applicable GitLab Channel Managers must approve the registered opportunity to qualify for partner program discounts and incentives. Partner Sourced Deal Registration opportunities are either:

1. Net-new to GitLab
2. An upsell/add-on for an existing GitLab customer

An approved Partner Sourced Deal Registration results in Sales Qualified Source = Partner Generated on the opportunity.

For more information: Deal Registration Program Overview.

Billing Account and Billing Account Contact on Partner Account Record

Partner Billing Record Creation

Billing Account and billing account Contact records must be created when onboarding a new partner that will be purchasing directly from GitLab. The Partner Manager should take the following action when a new partner has signed the click-through agreement or agreed to a customer MPA:

1. Create a contact record on the partner account that represents the partners accounts payable contact information with naming convention “[Partner Account Name] - Accounts Payable”. Ensure the address on the contact record matches the address on the partner account.
2. Chatter @Billing Ops on the Partner Account to request a new billing account. Include the following information:
   • Billing Account Company Name
   • Billing Account Contact Name and Email
   • VAT # if applicable

Partner accounts that will transact via distribution do not need a Billing Account or billing account Contact.

More information on billing accounts can be found on the Billing Operations Handbook Page.

How to Find Partner Billing Records in SFDC and Use for Quoting

The Invoice Owner and Invoice Owner Contact on a partner quote represent the partner’s Billing Account and billing account Contact records, respectively.

Distributors - GitLab sellers can access the Billing Account and billing account Contact records for our distributors here.

Note, partners that transact via distribution do not need billing records, as the distributor information will be used on the quote.

Resellers and MSPs - To find Billing Account and billing account Contact records in SFDC for partners that transact directly with GitLab, first navigate to the Partner Account record.

1. Billing Account - Refer to “Billing Account” in the related list quick links section at the top of the Partner Account record
2. Billing Account Contact - Open the partner’s Billing Account and locate the Sold To Work Email (i.e., their Accounts Payable email address). Search for this email in SFDC to determine if a contact record already exists under the Partner Account record
   • If there is an existing contact record for this email on the partner account, use it as the Invoice Owner Contact for your quote
   • If there is not an existing contact record for this email on the partner account, create a new contact record for this email address called “[Partner Name] - Accounts Payable” which you can then use as Invoice Owner Contact on the quote

Quoting Partner Deals

Partner Quoting Requirements

When a deal is being transacted via a Partner, and a discount other than the defined Program discount is being offered, a GitLab quote is required. At a minimum, a Draft Proposal needs to be created and provided to the Partner. Discounted quotes not in SFDC and sent to a Partner are not permitted within any GEO or Sales Segment. This includes providing product and discounted pricing quote details in an email.

Partner Quoting Responsibilities

Sales Reps and/or Renewal Managers are responsible for quoting and PO remittance on all standard GitLab direct and partner opportunities.

Partner Quoting Overview and Resources

Creating a partner quote is very similar to the process of creating a direct customer quote. There are only a few minor differences when quoting via partners, which are documented in the following Deal Desk handbook sections:

• One-Tier Reseller Direct quotes
• Two-Tier Distributor quotes
• MSP quotes

Refer to the Quote Studio Highspot page for quoting walkthroughs, including the following step-by-step guides specific to partner deals:

• Quoting Reseller and Distributor Deals
• Quoting MSP Deals

Refer to the partner billing information section of this handbook for guidance on how to create or find partner billing records in SFDC and then use them for quoting.

Transacting Through Distribution

Why Does GitLab Leverage Distribution?

GitLab is building out a global Authorized Distributor network similar to many other tier-one software companies. Distributors bring GitLab, our partners, and our customers several valuable offerings:

• Accelerate market reach with joint growth plans and execution including:
  • recruiting GitLab partners and driving completion of their GitLab sales and technical training
  • generating in-market customer awareness and passing qualified leads
• Augment GitLab sales capacity and coverage. Distributor sales teams:
  • work with partners and GitLab sales teams to aid in co-selling
  • are often in-market and speak local languages
• Offload transaction administration from GitLab sales, freeing time for more valuable selling activities
  • Distributor e-Marketplaces allow GitLab orders to be placed by customers and partners that are delivered in minutes, with zero touch by GitLab teams
  • Provide a single point of contact that is an expert in the GitLab Quote to Cash process, driving efficiencies throughout the sales cycle
  • Enable GitLab to scale our operations to allow for increased transaction volume without significant headcount additions (e.g., Deal Desk, Order Management, Billing)
• Credit management
  • Reduce credit management cost and risk for GitLab
  • Offer an array of financing options including the ability for our partners/customers to transact in local currency, which reduces their risk
• Extend GitLab technical services, training capacity, and coverage, both pre and post-sale

Distributor Requirements and Coverage by Geo and Market

For Commercial Markets:

• Open Partners located in regions/countries with active Authorized GitLab Distributors must purchase GitLab via those distributors

• Select Partners may choose to transact directly with GitLab (excluding certain regions) or via the region’s authorized distributor(s)

• In NORTH AMERICA, Partners transact with Climb Solutions via sales@climbcs.com and sales@climbcs.ca in the US and Canada, respectively

• In EMEA: Partners transact with Amazic via gitlab@amazic.com

• In APAC (several countries): Partners transact with Tech Data/TD Synnex via GitLab.APJ@techdata.com

  • In India: Partners may also choose to transact with Redington via gitlab@redington.co.in
  • In Japan: Partners may choose to transact with either Networld via gitlab-info@networld.co.jp or SB C&S via SBCASGRP-DevOps+gitlabdisti@g.softbank.co.jp
  • In Thailand: Partners may also choose to transact with Get On Technology via gitlab@got.co.th

GitLab sellers can also refer to the partner billing section of this handbook for a link to our distributor billing records and guidance on how these records are used in the quoting process.

For US PubSec:

• Partners transact with Carahsoft via gitlab@carahsoft.com

Rules of Engagement for Distributor Quotes and Orders

Distributors work directly with GitLab Sellers on the quoting and ordering process. GitLab Sellers can leverage the partner quoting resources, distributor contact information, and GitLab Sales FAQ - Selling with Partners to aid in the quote and order process.

If a reseller requests a quote directly from a distributor via the aliases above, any non-PubSec distributors may contact partnersupport@gitlab.com to request an official quote. Partner Support will forward the request to the GitLab Sales Rep that owns the customer account/opportunity for Sales to work the opportunity with the distributor, including creating and providing the quote.

If a GitLab Sales Rep is working directly with a reseller and needs to quote that reseller via a distributor (e.g., they are an Open partner), Sales can leverage the resources linked in this section above to create the quote and send to distribution.

Important to note for GitLab Sellers:

• Our pricing on a two-tier distribution deal is between GitLab and Distributor only. We should never include the reseller or customer when sending a distribution quote or discussing distributor pricing.
• Distributors have their own pricelist and are equipped to self-quote and order new business or other order types from it without receiving an official GitLab quote, as long as pricing is at standard programmatic discounts. There may be times, especially in multiple bid scenarios, where you may not be aware of the partner(s) bidding on an opportunity until we receive a PO.

Distributor e-Marketplaces

GitLab is activating Distributor e-Marketplaces for customers to transact via GitLab authorized resellers. There are specific requirements for partners prior to activating their e-Marketplace capability, including:

• Partner is an authorized GitLab Open or Select partner in good standing.
• GitLab e-Marketplace page that includes an overview of the partner’s technical expertise and/or services offerings.
• GitLab review of the draft page, and GitLab’s written (email) approval provided to the Distributor.

GitLab reserves the right to pause or deactivate a partner’s e-Marketplace offering if issues arise. For more information about Distributor e-Marketplaces, partners should contact their distributor, or their GitLab Channel Manager.

Partner Sales FAQ

Partners and GitLab Sellers frequently ask questions on how to collaborate with one another throughout the GitLab sales process. Refer to the following resources which document these FAQs and answers from both a Partner and GitLab Seller perspective:

• Partner FAQ - Selling with GitLab
• GitLab Sales FAQ - Selling with Partners

SFDC Field Definitions

Section I: Partner Sourced Deal Registration

• DR - Partner: The reseller partner that ‘submitted’ the Partner Sourced Deal Registration that the GitLab Sales Team subsequently ‘approved’ in the system

• DR - Partner Deal Type:

  • MSP: The partner purchases and owns the license on behalf of the customer
  • Resale: The partner is actually transacting the deal on their paper
  • Referral: The partner is bringing us the lead/opportunity but will either transact directly with GitLab or through another partner

• DR - Status: Dictates whether the Partner Sourced Deal Registration is Pending, Approved or Denied

• DR - Distributor: The GitLab-authorized distributor from which the DR - Partner is buying, when applicable

  

Section II: Primary Quote Partner Data*

• Resale Partner: The resale partner on the primary quote; the transacting partner

• Distributor: The GitLab-authorized distributor that transacts according to the primary quote

• Resale Partner Track: Value will be Select, Open, or Technology, and is determined based on Resale Partner *Stamped from primary quote when approved. Fields are locked.

  

Section III: Partner Contribution Data

• Referral: A link to the Labra/AWS registration record

• ESM/Cloud ESM Notes: ESMs and Cloud ESMs enter partner opportuity notes and next steps here

• Alliance Partner Opp ID: ESMs and Cloud ESMs enter the cloud partner (AWS or GCP) co-sell registration ID here

• Platform Partner: Customer’s platform that GitLab is being deployed

• Hyperscaler Engaged: ESMs and Cloud ESMs can select the cloud partner (AWS or GCP) engaged on early stage marketplace deals

  

Services Resale

• Partners can earn a program discount for reselling GitLab Professional Services

Incumbency Renewals

• Incumbent partners qualify for program renewal discounts. The partners that transact the most recent sale are considered the incumbent.
• A different partner can earn an incumbency discount only through formal written communications from the customer. This can be provided via email from an authorized representative from the customer.
• To earn partner discounts, partners will be required to meet compliance requirements (i.e. in good credit standing, have provided quarterly updates on the customer, review within 30 days of renewal, etc).
• GitLab Sales must work with incumbent channel partners on renewals unless the customer documents in writing that they no longer want to work with the partner. GitLab cannot offer a direct renewal quote if there is an incumbent partner.

Tender Offers (Multiple Bids)

• Tender offers are ones where the customers are requesting multiple bids for a project.
• Since all partners would be engaged in the sales process and would be creating a bid, all partners qualify for the Partner Co-Sell discount. However, if a partner was early in with the customer (pre-tender) and sourced the deal, then they could receive the higher discount with an approved Partner Sourced Deal Registration. If the partner earning the Partner Sourced discount is not awarded the deal, they would not receive additional referral compensation. Any partner offering their own services would qualify for Service Attach incentives in addition to any sales discounts for which they would qualify. The exception to the above would be for:
  • US PubSec business: In the event there is an approved Partner Sourced Deal Registration on a tender offer, the rest of the partners bidding would receive MSRP (List Price).
  • Renewals: Incumbent resellers get last year’s discount, all other resellers get MSRP (List Price) for flat renewals. Renewal add-ons for all resellers can receive program discounts based on Deal Registration Status.

Program Compliance

• For partners to transact according to program discounts, they must agree to the GitLab Partner Agreement.
• To earn partner discounts, partners are required to be program compliant.
• Non-contracted partners may transact on a one-off basis, only with explicit approval of regional channel directors, the director of channel programs, or the vice president of channels.

Unauthorized Partners

• An authorized partner is a partner that has signed a contract to transact with GitLab. In SFDC, the “Partner Status” will say “Authorized,” there will be a date in the “Signed Contract Date” field, and either the “Click-Through Agreement” box will be checked, or a manual contract will be listed in the Google docs or Contract section of the account record.
• A key goal of the GitLab Channel Program is the success of our authorized partners, which means whenever possible, we should work deals with them. We are developing our channel to provide coverage across geos, customer segments and vertical markets. However, there are some situations where customer requires a deal be transacted by a partner that is not willing to join the GitLab Partner Program. Only in those situations should we transact with an unauthorized partner, and only with the explicit approval of the programs team.
• Unauthorized partners have not signed a GitLab Partner Agreement.
• If an unauthorized partner would like to transact GitLab products or services, please have them visit the Partner Portal to sign up. Someone who has authority to accept the Agreement is required.
• Unauthorized partners cannot transact GitLab products and/or services, unless rare but explicit approval is granted by the programs team. Please reach out to the #partner-programs-ops Slack channel.

Legal Requests for Partner Contracts

The process to request the legal team’s involvement in partner contracts can be found on the legal team’s handbook page. Please note that the process for getting partner contracts signed is different from the process for any other legal request.

Partner Reporting and Tagging

Definitions

1. Deal Path: How the deal is transacted. Values can be Partner, Direct, Web Direct. Note, Partner includes Referral opportunities
2. Partner Sourced Deal Reg: Partner submits a Registration for their sourced opportunity via the Partner Portal. For the purposes of this matrix the assumption is the Deal Reg is approved. If the deal is not Partner Sourced then Deal Reg does not apply
3. DR - Deal Type: The type of Partner Sourced Deal Registration submitted by the Partner. Options include Resale, Referral, and MSP. Note, this field will be blank if there is no Partner Source Deal Registration
4. Initial Source: SFDC Lead value that is populated based on lead source. Defaults to PQL (Partner Qualified Lead) when a Partner submits a Partner Sourced Deal Reg and an Opportunity does not already exist in the system
5. Sales Qualified Sourced (SQS): Who converts/creates the Opportunity in SFDC. Can only be 1 value
6. Order Type: Customer order designation in SFDC. New First Order or Growth

Use Cases

• Numbers 1 & 2

  • Two potential paths:
    • Partner submits Partner Sourced Deal Reg and no Opportunity exists in the system. Initial source is PQL and SQS defaults to Partner Generated
    • AE or SDR creates an opportunity prior to a valid Partner Sourced Deal Reg being submitted and approved. Opportunity will automatically update SQS to Partner Generated when a Deal Registration is linked and approved
  • Number 1 is transacted via the partner that sourced the opportunity, while Number 2 is a sourced referral that was transacted directly with the customer
  • This applies to both New and Growth orders

• Number 3

  • Partner submits an order for a deal where we did not have an opportunity in the system did not submit a Partner Sourced Deal Reg

• Number 4

  • Deal is transacting thru the partner but was sourced by either a GitLab AE or SDR

Default Logic

1. If Partner Sourced Deal Reg = True and no opportunity exists, then Initial Source = PQL and SQS = Partner Generated
2. If Partner Sourced Deal Reg is linked to an existing opportunity and approved, then SQS = Partner Generated
3. If Initial Source = PQL then SQS = Partner Generated

SFDC Opportunity Source Field Values for Channel

• Initial Source - Partner Qualified Lead (PQL): Partner created and/or qualified the Lead whether they sourced it themselves or GitLab provided the inquiry to them to work.
• Sales Qualified Source: - Partner Generated:
  • Partner has converted the Lead/PQL to a qualified opportunity, or has created a brand new opportunity without a prior lead being in the system. SQS defaults to Partner when Initial Source = PQL
  • Partner submits Partner Sourced Deal Reg which (i) creates a new opportunity or (ii) is attached to an existing opportunity and approved by GitLab

Managing Partner Opportunities

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

In order to transact with GitLab, a partner must both be authorized by GitLab, and have completed at least one sales training.

Partner Co-Sell

All Channel deals are considered Partner Co-Sell opportunities unless there is an approved Partner Sourced Deal Registration or the Opportunities Sales Qualified Source = Partner Generated. These opportunities are not sourced solely by a partner, but highlight the relationship between GitLab and partners in the selling process. Partner Co-Sell deals do not require the partner to submit a deal registration, and should be processed according to standard Partner Co-Sell discounts as identified in the GitLab Partner Program.

US Public Sector Preferred Partner Co-Sell Request Process

The Partner Sourced Deal Registration process is the same for commercial and US Pubsec business. The instructions below apply only to US Public Sector CoSell opportunities.

1. Each public sector partner is provided a link to a Google form by either the SAE, ISR, or Channel Manager. This form must be completed in order for a partner to receive Preferred Partner Co-Sell discounts.
2. When a partner becomes aware of an opportunity, they must fill in the Google form, which will timestamp all of the relevant data to a Google sheet.
3. Part of filling out the Google form requires the partner to input the name and email of the SAE with whom they’ve discussed this. When that email address is inputted into the form and the form is submitted, that SAE will receive notification of a Pubsec Co-Sell opportunity.
4. The SAE will then approve or deny the submission based on Handbook guidelines.
   • The business reason for accepting a preferred partner submission must be noted on the Google form.
   • The SAE’s approval or denial will be time stamped in the Google sheet.
5. Once a partner is approved and selected, the 18-digit opportunity ID will be shared with them.
6. If a partner was previously approved but is now being removed, that SAE can selected the “Removed” option and enter the partner’s email address to notify them

All submissions will be recorded and tracked for audit purposes. The chosen preferred partner should match the Resale Partner on the quote with the Partner Co-Sell discount.

Any other partner receiving a quote for the same opportunity will be provided MSRP.

Further enablement for GitLab Team Members is available. For further information, contact the #partner-programs-ops slack channel.

Guidelines for approving US Public Sector Co-Sell Partner Submissions

The following are explicit guidelines for approved US Public Sector Partners to receive preferred pricing on GitLab-sourced opportunities.

Partner Requirements:

• Must be an approved US Public Sector Partner, authorized to transact with GitLab
• The partner must have completed one meeting with the SAE for the opportunity -This meeting must have included a conversation about alignment of how we can work together to land with vision and expand with purpose
• The partner must have filled out the Public Sector Co-Sell form and include the 18-digit Opportunity ID provided by the SAE

Partner Sourced Deal Registration

The Partner Sourced Deal Registration program rewards partners for bringing net-new business to GitLab. There are three types of Partner Sourced Deal Registrations within the GitLab Partner Program:

1. Registration of partner sourced Resale opportunities
2. Registration of partner sourced MSP opportunities (partner purchases and holds title to licenses to deliver a managed service to their end customer)
3. Registration of partner sourced Referral opportunities (partner does not transact the business they bring to GitLab)

Refer to the following sections for step-by-step instructions on how to process each registration type: Resale, MSP, and Referral.

GitLab’s Ecosystem Sales Managers, Sales Reps, and Area Sales Managers collaborate to review and action Partner Sourced Deal Registration submissions. Refer to the Partner Sourced Deal Registration: How it Works section for details on the review and approval process.

The SLA for GitLab to communicate with partners on a Partner Sourced Deal Registration is two business days. There must be contact with the registering partner within two business days, whether it be initial outreach to discuss the registration, a request for more information, approval, or rejection.

There can only be one Partner Sourced Deal Registration approved for an opportunity, as only one partner can source a deal. As a reminder, Partner Sourced Deal Registrations are opportunity-based and partners cannot register an account.

Partner Sourced Deal Registration: How it Works

The Partner Portal is hosted by Impartner and has SSO enabled with Vartopia, the partner-facing Deal Registration system.

Partner

The partner submits a Partner Sourced Deal Registration and then the following occurs:

1. An email is sent to the partner acknowledging that the deal registration has been successfully created and submitted. The registration is also viewable in the deal registration section of the partner’s portal account.
2. The system creates a Registration record on the Registration object in SFDC that includes all the details of the registration.
3. The system notifies the Ecosystem Operations team to review the registration.

Ecosystem Operations

The Ecosystem Operations team reviews the registration after it is submitted by the partner (DR-Status = “Submitted”). If there is:

• an existing customer account in SFDC, they will link the account and contact to the registration, assign the appropriate Ecosystem Sales Manager, then submit the registration for Ecosystem Sales Manager approval.
• no existing customer account in SFDC, they will create the account, link the account and contact to the registration, then hold for SFDC to assign the account territory and owner in an overnight update. Ecosystem Operations will assign the appropriate Ecosystem Sales Manager to the registration after customer account assignments are completed by system, then submit the registration for Ecosystem Sales Manager approval.

The Ecosystem Sales Manager on the registration is automatically assigned as the Account Owner of the Partner Account in SFDC. Ecosystem Operations will reassign the registration to the correct Ecosystem Sales Manager as part of their review in cases where adjustment is required to align the appropriate Ecosystem Sales Manager based on customer account territory or ownership. The Ecosystem Operations team has a 2 hour SLA to action registrations within their working hours, Monday through Friday.

GitLab Ecosystem Sales Manager

The Ecosystem Sales Manager receives an email notification to review the Partner Sourced Deal Registration once the Ecosystem Operations Team has actioned the registration and submitted it for approval (DR-Status = “Pending Sales Review”). Ecosystem Sales Managers can also view registrations in their list view within the SFDC Registration tab. The Ecosystem Sales Manager is responsible for reviewing the registration and communicating with the applicable GitLab Sales Rep and ASM during this process. The Ecosystem Sales Manager must either approve, reject, or return the registration for additional information after completing their review. If they approve, it will automatically be sent to the appropriate ASM for final review.

GitLab Area Sales Manager (ASM)

The GitLab ASM for the opportunity is responsible for final review of any Partner Sourced Deal Registration approved by a Ecosystem Sales Manager, and must either approve, reject, or return the registration for additional information. The ASM receives an email notification to review the registration only if/when the Ecosystem Sales Manager approves (DR-Status = “Pending ASM Review”). ASMs can also view registrations in their list view within the SFDC Registration tab.

**Alliance and GSI Partners

Alliance marketplace and OEM partners, and GSI partners do source opportunities for GitLab; however, they do not submit their own Partner Sourced Deal Registrations for these opportunities. The Registration process for these partners is instead initiated by the GitLab Ecosystem Sales Manager on behalf of the partner.

The steps below outline how a Partner Sourced Deal Registration is submitted on behalf of an alliance or GSI partner to initiate the Deal Registration process:

1. The GitLab Ecosystem Sales Manager opens the Alliance and GSI Partner Sourced Deal Registration document and follows the instructions to submit a Registration via the google form.
2. Ecosystem Operations team uses the data provided in the google form to submit a formal Partner Sourced Deal Registration via Vartopia on behalf of the partner.
3. The standard Partner Sourced Deal Registration process is then followed beginning with the “Partner” paragraph at the top of this handbook section.

Note, Partner Sourced Deal Registration incentives do not apply to alliance partners, as our alliance partner agreements supersede these programmatic incentives.

Partner Sourced Deal Registration: Rules of Engagement

• Partner Sourced Discount

  • To receive a quote with a Partner Sourced discount, the partner must submit a Partner Sourced Deal Registration for the opportunity which must be approved by GitLab.
  • Only one partner can earn a Partner Sourced discount per opportunity. Partners will generally receive the Co-Sell discount rate if they do not have an approved Partner Sourced Deal Registration.

• Approval Criteria

  • Partner Sourced Deal Registration approval is based on who sourced that particular opportunity. If the partner brought us the deal, then the registration should be approved. For clarity, it is not about first touch with the customer, but the actual creation/conversion of an opportunity.
  • The GitLab Ecosystem Sales Manager should communicate and align with the GitLab Sales Rep and ASM prior to approving or rejecting the Deal Registration.
  • The GitLab ASM should communicate and align with the GitLab Ecosystem Sales Manager and Sales Rep prior to approving or rejecting the Deal Registration.

• GitLab SLAs

  • The SLA for GitLab to communicate with partners on a Partner Sourced Deal Registration is two business days. There must be contact with the registering partner within two business days, whether it be initial outreach to discuss the registration, a request for more information, approval, or rejection.
  • The GitLab ASM has one business day to either approve or reject the Registration, which begins when the Registration hits their queue for approval. The ASM must communicate with the GitLab Ecosystem Sales Manager if their approval is anticipated to push beyond the one business day SLA.

• Identify and Notify Backup Approvers

  • GitLab Ecosystem Sales Managers and ASMs should always identify a backup approver prior to being out of office. This ensures approval requests can be actioned in your absence, and is crucial to meeting our SLAs (see GitLab SLAs above).

  • Ecosystem Sales Managers

    • Communicate that you will be out of office to your backup approver. The backup approver should monitor the Pending Deal Reg's by PM component of their Partner Forecast Dashboard to identify and action Deal Registrations in Pending Sales Review for the Ecosystem Sales Manager they are covering.
    • If you find an ASM is out of office while communicating with the Sales Rep and ASM during your approval process (see Approval Criteria above), align with their backup approver. If you approve the Deal Registration, chatter the backup approver to request their final approval on the record, as aligned to your discussion.

  • ASMs - Communicate that you will be out of office to your backup approver. Ecosystem Sales Managers will raise Deal Registrations for their review in your absence. Ensure your backup approver is prepared to action these requests while you are out.

• Standard Term and Extension

  • Approved deal registrations have a standard 90-day expiration from the date of original approval.
  • Deal Registration extensions beyond the initial 90-day approval are at the sole discretion of GitLab. To grant a standard 30-day extension, GitLab Partner and/or Field Sales can click the Extend DR 30 Days button on the Registration. For non-standard extensions beyond 30 days, please chatter @Partner Operations on the registration record and provide the new date that the registration should expire.

• GitLab and Partner Collaboration in the Sales Process

  • Resale and MSP opportunities - GitLab collaborates with the partner holding the approved Partner Sourced Deal Registration and is available to support the partner throughout the entire sales process.
  • Referral opportunities - The partner refers GitLab to the appropriate customer contact(s) which results in a qualified opportunity for GitLab. GitLab generally then leads the sales process to completion.

• Closed Lost Registered Opportunity

  • The GitLab Sales Rep will generally notify the partner by phone or email that the opportunity is not moving forward and then update the SFDC opportunity to Closed Lost.
  • The Deal Registration will update to Closed Lost in the system and the partner will receive a notification.

Partner Sourced Deal Registration: System Status and Information

• Deal Registration details will never override any information that the sales team forecasts on the Opportunity.
• The Deal Registration ID (DR - Deal ID) can be used to track all Deal Registrations in the system.
• Deal Registrations are individual Registration records under the Registration object in SFDC. Deal Registrations are not Lead records on the Lead object.

Partner Sourced Deal Registration: Reporting & Tools

• Deal Registration Views by Role
  • Ecosystem Sales Manager
  • Sales Rep
  • ASM
• ASM Deal Registration Guide
• Deal Registration Object Overview
• Adding the Registration Object to your Salesforce Navigation Bar
• How to View All of your Deal Registrations in SFDC
• Partner Facing Deal Registration instructions

Partner Sourced Deal Registration: Resale Opportunities

Partner Sourced Deal Registrations for resale opportunities reward partners for bringing net-new business to GitLab. An approved Partner Sourced Deal Registration generally provides the partner a deeper discount than the Co-Sell rate, as outlined in the GitLab Partner Program.

Follow the steps below to process a Partner Sourced Deal Registration for a resale opportunity:

Ecosystem Sales Manager for first review and action

1. Ecosystem Operations Team:

   • has first action to review and update the registration when DR-Status = Submitted. Important to note, the registration is not ready for Ecosystem Sales Manager review while in DR-Status = Submitted.
   • will update DR-Status to Pending Sales Review once their work is complete and the registration is ready for Ecosystem Sales Manager review (refer to How it Works for details). DR-Status being updated to Pending Sales Review sends a notification to the Ecosystem Sales Manager to review and action the registration.

2. Click the link in either your email or Deal Registration View to open the registration record in Salesforce.

3. Confirm the Deal Registration Type is “Resale” and that the partner provided sufficient detail to proceed with the registration. If registration details are:

   • accurate and complete, proceed to the next step.
   • inaccurate and/or incomplete, return the registration to request more information from the partner. Select “Returned” in the PM Approval Status field, add your information request for the partner in the PM Comments field, then click the Save button to complete the return process.

4. Discuss the opportunity with the GitLab Sales Rep and ASM and decide to either approve or reject the registration.

5. Click Link/Create Opportunity.

6. On the “Link/Create Opportunity” page, search for the opportunity in the provided list and/or perform a “Global Search.”

   • If the opportunity already exists and you plan to:
     • Approve the registration, click Link & Make Primary next to the opportunity name. You will then be brought back to the deal registration record.
     • Reject the registration, click Link next to the opportunity name. You will then be brought back to the deal registration record.
   • If there is no matching opportunity, click Create New, then choose “Standard” as the Opportunity Record Type. Click “Save” on the opportunity and you will be brought back to the “Link/Create Opportunity” page. Click Link & Make Primary and you will be brought back to the deal registration record.

7. Navigate to the Ecosystem Sales Manager Approvals section of the registration record. If you are going to:

   • Approve, select “Approved” in the PM Approval Status field, then click Save to complete your approval.
   • Reject, select “Denied” in the PM Approval Status field, select a reason in the PM Denial Reason field, then click Save to complete your rejection.

8. If you created a new opportunity during this process (see step 6 above), update Opportunity Owner to the Sales Rep who owns the customer account using the Change Opportunity Owner button on the opportunity.

   

Area Sales Manager (ASM) for final review and action (if approved by Ecosystem Sales Manager)

1. You will receive an approval request email when a registration has entered your queue for review and approval. Click the link in your email or Deal Registration View to open the registration record in SFDC.
2. Confirm alignment with the Ecosystem Sales Manager and GitLab Sales Rep prior to providing final approval or rejection on the registration.
3. Click Approve/Deny/Return Registration.
4. Select the Approve, Deny, or Return option. Add any message for the partner in the Comments sent to Partner field if applicable. Select Save to complete the process.

The deal registration form is not a quoting tool and will not have all the information needed to create a quote. The GitLab Sales Rep must connect with the partner to request any necessary information prior to creating a quote.

Partner Sourced Deal Registration: MSP Opportunities

Partner Sourced Deal Registrations for MSP opportunities reward partners for managing products and services for their end customers. An approved Partner Sourced Deal Registration generally provides the partner a deeper discount than the Co-Sell rate, as outlined in the GitLab Partner Program.

A Managed Service Provider (MSP) purchases licenses on behalf of an end user. The MSP will be the owner and manager of the licenses but their customer, the end user, is the one using the licenses. This creates specific needs in GitLab Salesforce opportunities to ensure proper reporting and compensation. Please note that the steps for an MSP opportunity differ from the steps for a resale opportunity.

Follow the steps below to process a Partner Sourced Deal Registration for an MSP opportunity:

Ecosystem Sales Manager for first review and action

1. Ecosystem Operations Team:

   • has first action to review and update the registration when DR-Status = Submitted. Important to note, the registration is not ready for Ecosystem Sales Manager review while in DR-Status = Submitted.
   • will update DR-Status to Pending Sales Review once their work is complete and the registration is ready for Ecosystem Sales Manager review (refer to How it Works for details). DR-Status being updated to Pending Sales Review sends a notification to the Ecosystem Sales Manager to review and action the registration.

2. Click the link in either your email or Deal Registration View to open the registration record in Salesforce.

3. Confirm the Deal Registration Type is “MSP” and that the partner provided sufficient detail to proceed with the registration. If registration details are:

   • accurate and complete, proceed to the next step.
   • inaccurate and/or incomplete, return the registration to request more information from the partner. Select “Returned” in the PM Approval Status field, add your information request for the partner in the PM Comments field, then click the Save button to complete the return process.

4. Discuss the opportunity with the GitLab Sales Rep and ASM and decide to either approve or reject the registration.

5. Click Link/Create Opportunity.

6. On the “Link/Create Opportunity” page, search for the opportunity in the provided list and/or perform a “Global Search.”

   • If the opportunity already exists and you plan to:
     • Approve the registration, click Link & Make Primary next to the opportunity name. You will then be brought back to the deal registration record.
     • Reject the registration, click Link next to the opportunity name. You will then be brought back to the deal registration record.
   • If there is no matching opportunity, click Create New, then choose “Standard” as the Opportunity Record Type. Click “Save” on the opportunity and you will be brought back to the “Link/Create Opportunity” page. Click Link & Make Primary and you will be brought back to the deal registration record.

   

7. Navigate to the Partner Manager Approvals section of the registration record. If you are going to:

   • Approve, select “Approved” in the PM Approval Status field, then click Save to complete your approval.
   • Reject, select “Denied” in the PM Approval Status field, select a reason in the PM Denial Reason field, then click Save to complete your rejection.

8. Change the Account Name field on the opportunity to the partner account. This should not be the MSP End User (i.e., customer) account.

9. If you created a new opportunity during this process (see step 6 above), update Opportunity Owner on the opportunity to the Sales Rep who owns the MSP End User (i.e., customer) account using the Change Opportunity Owner button.

10. Connect the GitLab Sales Rep to the MSP Partner Rep so they can discuss and align on opportunity and quote details.

11. Provide Deal Desk MSP quoting and Internal Partner Program discounting links to the GitLab Sales Rep so they have the process details necessary to manage the opportunity and create a quote.

Area Sales Manager (ASM) for final review and action (if approved by Ecosystem Sales Manager)

1. You will receive an approval request email when a registration has entered your queue for review and approval. Click the link in your email or Deal Registration View to open the registration record in SFDC.
2. Confirm alignment with the Ecosystem Sales Manager and GitLab Sales Rep prior to providing final approval or rejection on the registration.
3. Click Approve/Deny/Return Registration.
4. Select the Approve, Deny, or Return option. Add any message for the partner in the Comments sent to Partner field if applicable. Select Save to complete the process.

The deal registration form is not a quoting tool and will not have all the information needed to create a quote. The GitLab Sales Rep must connect with the partner to request any necessary information prior to creating a quote.

Partner Sourced Deal Registration: Referral Opportunities

Partner Sourced Deal Registrations for referral opportunities reward partners for bringing net-new business to GitLab, even if that partner does not transact the deal. An approved Partner Sourced Deal Registration for a referral opportunity provides the partner a back-end rebate upon GitLab successfully closing the deal as won (processed quarterly), as outlined in the GitLab Partner Program.

Follow the steps below to process a Partner Sourced Deal Registration for a Referral opportunity:

Ecosystem Sales Manager for first review and action

1. Ecosystem Operations Team:

   • has first action to review and update the registration when DR-Status = Submitted. Important to note, the registration is not ready for Ecosystem Sales Manager review while in DR-Status = Submitted.
   • will update DR-Status to Pending Sales Review once their work is complete and the registration is ready for Ecosystem Sales Manager review (refer to How it Works for details). DR-Status being updated to Pending Sales Review sends a notification to the Ecosystem Sales Manager to review and action the registration.

2. Click the link in either your email or Deal Registration View to open the registration record in Salesforce.

3. Confirm the Deal Registration Type is “Referral” and that the partner provided sufficient detail to proceed with the registration. If registration details are:

   • accurate and complete, proceed to the next step.
   • inaccurate and/or incomplete, return the registration to request more information from the partner. Select “Returned” in the PM Approval Status field, add your information request for the partner in the PM Comments field, then click the Save button to complete the return process.

4. Discuss the opportunity with the GitLab Sales Rep and ASM and decide to either approve or reject the registration.

5. Click Link/Create Opportunity.

6. On the “Link/Create Opportunity” page, search for the opportunity in the provided list and/or perform a “Global Search.”

   • If the opportunity already exists and you plan to:
     • Approve the registration, click Link & Make Primary next to the opportunity name. You will then be brought back to the deal registration record.
     • Reject the registration, click Link next to the opportunity name. You will then be brought back to the deal registration record.
   • If there is no matching opportunity, click Create New, then choose “Standard” as the Opportunity Record Type. Click “Save” on the opportunity and you will be brought back to the “Link/Create Opportunity” page. Click Link & Make Primary and you will be brought back to the deal registration record.

7. Navigate to the Partner Manager Approvals section of the registration record. If you are going to:

   • Approve, select “Approved” in the PM Approval Status field, then click Save to complete your approval.
   • Reject, select “Denied” in the PM Approval Status field, select a reason in the PM Denial Reason field, then click Save to complete your rejection.

8. If you created a new opportunity during this process (see step 6 above), update Opportunity Owner to the Sales Rep who owns the customer account using the Change Opportunity Owner button on the opportunity.

Area Sales Manager (ASM) for final review and action (if approved by Ecosystem Sales Manager)

1. You will receive an approval request email when a registration has entered your queue for review and approval. Click the link in your email or Deal Registration View to open the registration record in SFDC.
2. Confirm alignment with the Ecosystem Sales Manager and GitLab Sales Rep prior to providing final approval or rejection on the registration.
3. Click Approve/Deny/Return Registration.
4. Select the Approve, Deny, or Return option. Add any message for the partner in the Comments sent to Partner field if applicable. Select Save to complete the process.

The deal registration form is not a quoting tool and will not have all the information needed to create a quote. The GitLab Sales Rep must connect with the partner to request any necessary information prior to creating a quote.

Service Attached Registration

GitLab incentivizes Select partners and Designated Professional Services Partners (PSP) that sell their own professional services into a customer environment. The partner must submit service opportunities via a Service Attached Registration on the Partner Portal. Service Attached qualifications do not require license purchases through a services partner. Customers can obtain licenses directly from GitLab, through a services partner, or from other partners.

Refer to the program guidelines for Service Attached Registration approval requirements. Select partners and PSPs with approved Service Attached Registrations qualify for quarterly back-end rebates. GitLab sellers qualify for partners services compensation upon approval of Service Attached Registration from a Designated Professional Services Partner (PSP). Refer to the GitLab Sales Commissions Internal Handbook for further details.

Review the steps below to understand how a Service Attached Registration for an applicable GitLab software opportunity is processed.

Ecosystem Operations for First Review and Action

Ecosystem Operations has first action to review and update the registration when DR-Status = Submitted:

1. Link the Customer account
2. Link the associated software opportunity
3. Verify that the linked opportunity has no approved Service Attached Registration, as additional registrations will be denied
4. Set DR - Status and Service Attach Status to Pending
5. Add Registration Name (REGxxxxx) to Service Attach Registration on the liked opportunity
6. Add Service Attach Partner to the linked opportunity

Partner Submits Executed Statement of Work

Email your valid Statement of Work and Deal ID to partnersupport@gitlab.com. The Statement of Work (SOW) must meet GitLab Partner Program requirements.

Ecosystem Operations for Second Review and Final Action

1. Ecosystem Operations reviews the partner SOW and moves the registration to one of the following statuses:

   • Pending: Additional information or documentation is needed. Ecosystem Operations will leave the registration in Pending status and work with the partner to obtain required documentation.
   • Pending Opportunity Closure: The partner’s SOW (i) has been submitted and (ii) meets program requirements, but the related software opportunity is not yet closed-won
   • Approved: (i) The SOW has been submitted and approved, (ii) the opportunity has been closed-won, and (iii) all other program requirements have been met
   • Accepted: Qualifies for PSP, but not for rebate. Paid service engagement with a SOW signed and submitted within 12 months of registration submission and closed-won Net ARR opportunity.
   • Unqualified: The registration and/or SOW do not qualify for Service Attached program as defined by the GitLab Partner Program
   • Closed: If the opportunity has moved to Closed-Lost or if the partner or ESM communicates the partner did not win the services business

2. Ecosystem Operations adds the Service Attach Approval Date when the registration is moved to Approved. Service Reg Approval Date will be set when both requirements below are fulfilled:

   • Receipt of valid executed SOW
   • Opportunity Closed Won status
   • All other program requirements are met

Additional Resources

• Service Attached Enablement Deck
• Service Attached Enablement Recording
• Frequently Asked Questions

Additional Information

• PSP Engaged on the software opportunity will automatically check when the linked Service Attach Partner is a Designated Professional Services Partner (PSP)
• Partner Services Amount is calculated as Net ARR multipled by an attach rate as defined in the Sales Commissions Internal Handbook
• Partner Service Attached incentives are outlined in the GitLab Channel Partner Program Discounts and Incentive Guide
• Rebates and referral fees may require CRO approval
• Discounts are off list price. If GitLab is deeply discounting a large ARR customer engagement, the partner can reasonably expect to share in that with a discount reduction. The Partner, GitLab Sales, Ecosystem Sales Manager must agree on the negotiated discount amount

For more information on quoting or the Partner Program, please visit:

• Deal Desk Quote Configuration
• Partner Program
• Channel Discount Matrices for GitLab Team Members

Partner Rebate Exception Review Process

While rebates are generally intended for Partner Sourced business only, there may be corner cases where GitLab wants to provide the partner a rebate for Sourced-like activities that resulted in a different outcome. The following Partner Rebate Exception Review Process can be used to requset a rebate exception.

1. The Ecosystem Programs teams and GTM FP&A will collect Partner rebate exception requests up until the 15th of the last month of the quarter
2. Around the 15th of the last month of the quarter, GTM FP&A, Ecosystem Programs, Ecosystem Operations, Ecosystem Strategy, and Ecosystem Sales Leadership will meet to review each case. Possible outcomes include:
   • Rejecting the rebate request
   • Approving the request, funded by Global Ecosystem budget
   • Approving the request, funded by the involved account team’s budget
3. Results will be shared with you and your leaders after review and will be documented via Chatter. If the request is approved, rebates will be paid out within 45 days of the new quarter.

Partner Influence

Partners can influence GitLab opportunities without transacting the deal. The Partner Team (ESM, Cloud ESM, or SA) can submit an internal Partner Influence record to track their partner’s influence activities.

Partner influence activities include customer executive engagement and advocacy and/or working side by side with GitLab on the customer pursuit in the following ways:

• Intro to customer decision maker/C-Suite
• Host/participate in Exec briefing, advocating for GitLab
• Trusted exec or technical advisor proactively advocating for GitLab
• Intro and/or position GitLab as part of a better together software sale
• Deliver presentation, demo, POC, or RFP response
• Deliver customer strategy that recommends GitLab
• Advise GitLab acct. Team on customer strategy/use case/pain points

Follow the steps below to track a partner’s influence on an opportunity:

1. From the Related List Quick Links at the top of the opportunity page, hover your cursor over Influence Partners and select New Influence Partner
2. Add a partner to the Influence Partner field using the lookup button
3. Select the applicable Influence Type:
   • Customer executive engagement and advocacy
   • Working side by side with GitLab on customer pursuit.
4. Select one or more applicable partner influence activities using Influence Details:
   • Introduction to a customer decision maker or C-Suite
   • Host or participate in exec briefing advocating for GitLab
   • Trusted exec or technical advisor proactively advocating for GitLab
   • Introduce and/or position GitLab as part of better together software sale
   • Deliver presentation demo, POC, or RFP response
   • Develop customer strategy that recommends GitLab
   • Advise GitLab account team on customer strategy/use case/pain points
5. Provide a detailed description of the partner’s influence activities using Description of Partner Influence
6. Do not edit Opportunity Owner, ASM, Ecosystem Sales Manager and Customer Account. These will auto-populate upon save
7. Save the Influence Partner Record
8. Attach any supporting documentation that highlights the partner’s influence on the opportunity via Google Docs, Notes, & Attachments section.

Channel Approvals

Channel Approvers for opportunities are based on the Opportunity Owner’s User Region. Whenever an approver changes, an issue must be opened with Sales Systems to replace the old approver with the new. Current channel approvers can be seen in our channel approver matrix.

If an approver will not be able to approve opportunities due to PTO or some other reason, they must assign a delegate in SFDC to approve opportunities on their behalf.

Letters of Authorization

When a partner needs a Letter of Authorization (“LOA”), they must log into the partner portal and request one from the “Request a Letter of Authorization” button on the “Common Requests” page. If a partner does not log in to the portal, they will not be able to access this request. This helps ensure that only authorized partners can access the link and request a LOA.

The partner will be prompted to input basic company information that will auto-fill the LOA. Upon submission, the LOA will automatically be sent to the Ecosystem Operations team for review and confirmation that the entity requesting the LOA is a valid and authorized partner. Once appproved by Ecosystem Operations, the LOA will automatically be sent to the legal team who will approve and initial the LOA before sending it to GitLab’s PAO for signature. Once signed, the LOA will be sent directly to the partner via email. The letter is good for one calendar year from the date on the letter.

Program and Incentive Definitions

• The GitLab Ecosystem Program provides partners with set discounts based on their program status and whether or not there is an active deal registration.
• At least one partner employee must complete the GitLab Foundations for Partners training for the partner to qualify for deal registration and program discounts.
• GitLab employees can access the partner discount guidance here
• Partners can find the discount table in the Asset Library on the GitLab Partner Portal.

Channel Partner Price Files

The following price files are provided by Partner Ops in Google Sheet, Excel, and PDF format:

• Distribution Price Files for Resale Opportunities, including reseller and distributor discounts for the main program.
• Public Sector Price Files for Resale Opportunities, including reseller and distributor discounts for the main program.
• Partner (Direct Reseller) Price Files for Resale Opportunities, including reseller discounts for the main program.
• List Price File with no discounts.

How to Access the Price Files (Partners)

Distributor and Reseller partners can access the Partner Portal for the current GitLab Price File. If you have any issues accessing the Partner Portal, please contact the Ecosystem Operations team at partnersupport@gmail.com.

How to Access and Share the Price Files (GitLab Team Member, Internal Use Only)

When sharing a Channel Price File with a partner (either a distributor or reseller), please do NOT share the Channel Price File folder or file location. To share a price file, please direct the distributor or partner to log into the Partner Portal, select Asset Library in the menu and search “Price File”. The partner will be able to access and download their most up-to-date Channel Price File via this route.

Price Files for internal use can be found in this folder.

Price File Update Process

At the beginning of the second month of every quarter, Ecosystem Operations will create an issue and tag product and professional services (PS) departments to collect information on any new changes, additions, or discontinuations of part numbers. It is the responsibility of the product/PS departments to provide any and all information about SKUs that will be active on the first date of the next quarter.

The following departments/people will be tagged for gathering this information:

• 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 (any changes to existing/ new channel/ distributor discounts)
• Customer Success Management - Sherrod Patching

The following departments/people will be tagged for FYI/Additional Input:

• Ecosystem Operations: Marcella Summers
• Partner Programs: David Forsch
• Deal Desk: Jesse Rabbits
• PubSec Channel: Pilar Meija
• Business Technology: Caroline Swanson

Once the Price Files are updated for the upcoming quarter, Partner Support will upload the files to the Partner Portal and share them via email with the below distributors 30 days prior to the new quarter.

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

If there are no updates to the files, this will be documented on the version changes tab.

Please reach out to the #partner-programs-ops Slack channel for assistance.

*Exceptions can be made for updates to core GitLab products (Ultimate and Premium)

Internal Price File Communications

Partner Support will post a message on the slack channel #partner-fyi to share the updated Price Files and call out any major changes.

SFDC Channel Manager Activity Tracker

The Channel Managers use a tracking system in Salesforce to record their sales and marketing activities. This tracker allows them to extract data for sales analysis and goal setting (QBRs, OKRs, Business Plans, 1:1s). In addition, it enables the creation of activity frameworks to set engagement standards and further develop relationships with GitLab’s partners. This activity tracker is available to all Channel Managers.

GitLab Ecosystem Certification Dashboard

The GitLab Ecosystem Certification Dashboard is an interactive scorecard that provides a comprehensive outline of certification and accreditation journeys by partner and region.

Dashboard Features:

• The Partner Scorecard provides a holistic view of GitLab partner certification totals. You can drill down by quarter and badge.
• The Regional Scorecard provides certification counts by badge, and by partner and user. You can drill down by country, quarter, and badge.
• The PSE Vouchers Used tab lists partner PSE voucher codes and expiration dates
• The PSP Eligibility tab provides visibility into each partners PSP and compliance status

Partner Insights

The Ecosystem Operations team provides Partner Insights data to Ecosystem Sales Managers to help with building partner Business Plans and preparing for QBRs and partner meetings. These insights are intended to help Ecosystem Sales Managers have productive conversations with partners to identify what is going well so it can be replicated, as well as address opportunities for improvement to develop stronger and more valuable partnerships.

Ecosystem Sales Managers can:

• generate their Partner Insights data by accessing this self-service spreadsheet. Please follow the instructions on the first tab of the spreadsheet to generate a PDF with charts and metrics for your selected partner.
• create a Partner Insights PowerPoint by accessing this step-by-step guide.

If you need assistance with accessing the spreadsheet or PowerPoint step-by-step guide, please contact us at #partner-program-ops in Slack. If you have a customized reporting request that’s not on the self-service spreadsheet, please open an issue on the Ecosystem Operations board.

Partner Award Program

The GitLab Partner Awards are awarded on an annual basis. No submissions or applications are solicited; partners are assessed on our published award criteria outlined below.

Results are evaluated on the previous GitLab’s fiscal year, which runs February through January - i.e. FY25 Awards will be evaluated on FY24 data. All awards must be approved by regional Channel directors and VP of Global Channels and Alliances prior to announcement.

Winners receive a physical award, virtual badge for use on the partner’s website and social media, and online promotion by GitLab, which may include a blog post and social media announcements.

Award Program DRI(s):

• Channel Program DRI
  • Channel Program Director solicites data from SSOT to analyze to determine winners
• Channel Sales DRI(s)
  • Director(s) and VP of Global Channels and Alliances nominate and approve award winners
  • Director(s) provide short write-up about winners to include in PR efforts and presentations
• Channel Marketing DRI
  • Manages award ordering and shipments
  • Creates issue for PR assistance
• Corporate Communications DRI
  • Creates press release or blog post announcing award winners

Award Categories - proposed for FY25:

• Americas and Public Sector Categories
  • AMER Partner of the Year
  • AMER Emerging Partner of the Year (optional)
  • 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 Categories
  • APAC Partner of the Year
  • APAC Emerging Partner of the Year (optional)
  • APAC Distributor of the Year
  • APAC Services Partner of the Year
• Europe-Middle East-Africa Categories
  • EMEA Partner of the Year
  • EMEA Emerging Partner of the Year (optional)
  • EMEA Distributor of the Year
  • EMEA Services Partner of the Year

Award Consideration Timing: GitLab will announce the Partner Award winners at a Global-level event within their Q1 timeframe. Awards will be shipped to the winners 4-6 weeks post-announcement. Award celebrations will be held at Partner Leadership Summit or other similar event.

Awards Criteria (taken from previous FY): The GitLab Ecosystem Operations team is responsible for compiling the reports outlined in the criteria below from our SSOT data in SFDC. Channel Sales Directors and the VP of Global Channel and Alliances will review, assess and evaluate these reports based on the criteria outlined below.

• [Regional] Partner of the Year

  • Total revenue
  • Partner Sourced - approved deal reg
  • New logos
  • Example of great deal, service offering, campaign or field collaboration

• [Regional] Emerging Partner of the Year (optional award)

  • Rapid revenue and pipeline growth
  • Rapid services engagement
  • Example of great deal, service offering, campaign or field collaboration
  • May be new partner or existing partner that ramped rapidly in the prior year

• [Regional] Services Partner of the Year

  • Professional Services subcontracting delivery - GitLab Services revenue impact
  • Service attach deal registrations
  • GitLab service offers - number of offers, quality of offers, level of GitLab sales engagement with the offers

• [Regional] Distributor of the Year

  • Total revenue
  • Open partner compliance improvements
  • Number of compliant partners
  • Number of accreditations
  • Pipeline generated

Ecosystem Forecast and MBO Salesforce Dashboards

The following Ecosystem forecast dashboards have been published for FY26. Please use the dashboard relevant to your region or segment. You will only have access to view data from your region based on salesforce permissions.

Ecosystem Operating Dashboards:

• Global
• AMER
• APJ
• EMEA
• PubSec

Ecosystem MBO Dashboards:

• Global
• AMER
• APJ
• EMEA
• PubSec

Alliances and OEMs

Please visit the Alliances Handbook for an overview of the GitLab Alliance Team. If you are a GitLab employee, the Private Alliance Handbook is another available resource. The Alliances Salesforce Dashboard is also available. For any questions regarding our Alliance partners, please reach out to the #cloud-aws or #cloud-gcp Slack channel. If your inquiry is deal-specific, please use one of these Slack channels: #a_gcp_deal_registration, #a_aws_deal_registration, #a_ibm_deal_registration.

Opportunity Tagging for Marketplace Deals

Use Case 1: Partner Co-Sell (Marketplace transaction with no source credit)

If a deal is being transacted through GCP Marketplace or AWS Marketplace, then the following fields need to be filled out on the opportunity:

• Resale Partner = GCPor AWS *Be sure to use the correct SFDC account. Click on the link to confirm the GCP and/or AWS account.)

Use Case 2: Partner Sourced Deal Registration (No Marketplace transaction)

If GCP or AWS brought us a lead/referred GitLab a deal, but will not be transacting on Marketplace, then the following fields should be filled out on the opportunity:

• DR - Partner should be filled out using GCP or AWS account
• DR - Partner Deal Type = Referral

Use Case 3: Partner Sourced Deal Registration (Marketplace transaction) If GCP or AWS brought us a lead/referred GitLab a deal, and will be transacting on Marketplace, then the following fields should be filled out on the opportunity:

• DR - Partner should be filled out using GCP or AWS account
• DR - Partner Deal Type = Resale

Use Case 4: Partner Influence (No Marketplace transaction and no source credit)

If GCP or AWS support a deal and help drive the customer to buy GitLab, but were not the original source of the opportunity nor are they transacting the deal, then the following field should be filled out on the Opportunity:

• Influence Partner should be filled out using GCP or AWS account

Quote Tagging for Marketplace Deals

• If a deal is being transacted through the Google Cloud Marketplace, use the following values in the quote:
  • Invoice Owner = Google Cloud Marketplace
  • Invoice Owner Contact = Cloud Marketplace Payments Note: search “Payments” (with quotation marks) for the correct contact to populate in this field)
  • Resale Partner = Google Cloud (Partner)
• If a deal is being transacted through the Amazon Web Services Marketplace, use the following values in the quote:
  • Invoice Owner = Amazon Web Services, Inc.
  • Invoice Owner Contact = Accounts Payable (AWS)
  • Resale Partner = Amazon Web Services

Opportunity Tagging for Carahsoft Distributor Seller of Record (DSOR) AWS Marketplace Transactions

Carahsoft’s DSOR (Distributor Seller of Record) Program is a partner program designed to provide ISV clients a 2-Tier channel enablement in expanding their business growth through the AWS Marketplace. Under the program, Carahsoft would list GitLab’s products on AWS Marketplace and drive the private offer selling motion. Carahsoft develops the selling opportunity and authorizes the Consulting Partner within the AWS Marketplace to release a private offer to the customer.

For deals transacting through the Carahsoft DSOR program, the quote should reflect a normal two-tier channel transaction where the Distributor = “Carahsoft Technology Corporation” and Resale Partner = the reseller working the opportunity. For more information/instructions on quoting two-tier distribution deals, please refer to this Deal Desk handbook section.

To recognize and properly compensate these transactions, please ensure the CPPO or DSOR Partner field = “Amazon Web Services” on the opportunity record. Please chatter Chris Novello or Pilar Meija on your DSOR opportunity so they can review the opportunity and update the CPPO or DSOR Partner field.

IBM (OEM) Partner Requests & QTC Process

See IBM (OEM) Partner Requests & QTC Process for a step-by-step guide of the IBM (OEM) Quote to Cash process.

Consulting Partner Private Offers (CPPO)

For more information on our AWS CPPO Program, please reference the following program guide.

Registering Opportunities with Marketplace Providers

Just as our partners register opportunities with GitLab, Ecosystem Sales Managers should register their marketplace opportunities with the prospective cloud provider. Instructions for submitting registrations to AWS and GCP are shown below.

Amazon Web Services

AWS registrations can be received and submitted directly through your SFDC opportunity using the Labra Referrals and Labra Leads tools. Instructions can be found in this Labra Process Guide.

Google Cloud

GCP registrations are submitted on GitLab’s behalf by the GCP team. To register a new opportunity with GCP, please click the following link and fill out the form.

New GitLab Opportunity Registration for GCP

Compensation on Ecosystem Opportunities

The executed compensation letter should be the approved and legal source of truth for compensation. However please use the following resources to assist in clarification or exceptions.

Sales Commissions Internal Handbook

FY25 Partner Comp Exception Process