This page serves as the Ecosystem Operations team page and includes standard channel reporting links, and details for managing partner opportunities
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 #partner-programs-ops Slack channel can be leveraged for inquiries. Both the Ecosystem Operations Team and the Channel Programs Team monitor this slack channel.
If you are reporting a problem or have suggestions, changes, or similar, 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
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
~~~partner-fyi~~~
Updates to the Channel & Sales teams on Channel program, operations, enablement and marketing. Questions from team members should be posted on the #partner-programs-ops or #channel-sales
blank
any
Channel Operations, Channel Programs, Nima Badiey
partner-program-ops
Questions and comments about channel programs and operations
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:
Net-new to GitLab
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.
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:
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.
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.
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.
Billing Account - Refer to “Billing Account” in the related list quick links section at the top of the Partner Account record
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.
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:
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
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:
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.
Deal Path: How the deal is transacted. Values can be Partner, Direct, Web Direct. Note, Partner includes Referral and Influence opportunities
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
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
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
Sales Qualified Sourced (SQS): Who converts/creates the Opportunity in SFDC. Can only be 1 value
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
If Partner Sourced Deal Reg = True and no opportunity exists, then Initial Source = PQL and SQS = Partner Generated
If Partner Sourced Deal Reg is linked to an existing opportunity and approved, then SQS = Partner Generated
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
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.
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.
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.
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.
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.
Once a partner is approved and selected, the 18-digit opportunity ID will be shared with them.
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.
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:
Registration of partner sourced Resale opportunities
Registration of partner sourced MSP opportunities (partner purchases and holds title to licenses to deliver a managed service to their end customer)
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:
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.
The system creates a Registration record on the Registration object in SFDC that includes all the details of the registration.
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:
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.
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 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
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.
Click the link in either your email or Deal Registration View to open the registration record in Salesforce.
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.
Discuss the opportunity with the GitLab Sales Rep and ASM and decide to either approve or reject the registration.
Click Link/Create Opportunity.
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.
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.
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)
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.
Confirm alignment with the Ecosystem Sales Manager and GitLab Sales Rep prior to providing final approval or rejection on the registration.
Click Approve/Deny/Return Registration.
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 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
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.
Click the link in either your email or Deal Registration View to open the registration record in Salesforce.
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.
Discuss the opportunity with the GitLab Sales Rep and ASM and decide to either approve or reject the registration.
Click Link/Create Opportunity.
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.
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.
Change the Account Name field on the opportunity to the partner account. This should not be the MSP End User (i.e., customer) account.
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.
Connect the GitLab Sales Rep to the MSP Partner Rep so they can discuss and align on opportunity and quote details.
Area Sales Manager (ASM) for final review and action (if approved by Ecosystem Sales Manager)
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.
Confirm alignment with the Ecosystem Sales Manager and GitLab Sales Rep prior to providing final approval or rejection on the registration.
Click Approve/Deny/Return Registration.
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 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
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.
Click the link in either your email or Deal Registration View to open the registration record in Salesforce.
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.
Discuss the opportunity with the GitLab Sales Rep and ASM and decide to either approve or reject the registration.
Click Link/Create Opportunity.
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.
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.
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)
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.
Confirm alignment with the Ecosystem Sales Manager and GitLab Sales Rep prior to providing final approval or rejection on the registration.
Click Approve/Deny/Return Registration.
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 and Opportunities
GitLab incentivizes partners that sell their own professional services into a customer environment. The customer could have purchased licenses from the services partner, but that is not required to qualify for Service Attach. They could have purchased licenses directly from GitLab or from another partner. An approved Service Attached Registration makes the partner eligible for a back-end rebate (processed quarterly) once (i) GitLab successfully closes the related software deal as won and (ii) the partner completes their services and provides Proof of Execution, as outlined in the GitLab Partner Program. This is separate from the Partner Sourced Deal Registration for the license sale.
To track the Partner Services, the partner must register the deal on the Partner Portal.
Follow the steps below to process a Service Attached Registration for an applicable GitLab software sale opportunity:
Ecosystem Sales Manager for first review and action
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.
Click the link in either your email or Deal Registration View to open the registration record in Salesforce.
Confirm the Program Name is “Service Attached Registration”, Services Attach Type is populated with the relevant service, and that the partner provided sufficient detail to proceed with the registration. If registration details are accurate and complete, proceed to the next step. If registration details are 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. Important to note:
There may also be a Resale or Referral Partner Sourced Deal Registration for the license sale. The Resale or Referral registration will populate in the opportunity fields, while the Service Attached registration will only be linked to the opportunity.
A Service Attached Registration must attach to a license sale opportunity.
There should already be an existing license sale opportunity in the system prior to processing approvals on a Service Attached Registration. If there is no existing license opportunity, the Ecosystem Sales Manager should request that the partner submit a Partner Sourced Deal Registration for the license sale. Once the Ecosystem Sales Manager has processed the Partner Sourced Deal Registration, they can attach the Service Attached Registration to the existing opportunity and proceed with approvals.
Discuss the Service Attached registration with the GitLab Sales Rep and ASM and decide to either approve or reject.
Click Link/Create Opportunity.
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, click Link next to the opportunity name. You will then be brought back to the deal registration record.
If there is no matching opportunity, and you plan to:
Approve the registration, click the Back button and refer to Step 2 above for next steps.
Reject the registration, click the Back button and proceed to the next step.
The opportunity must be less than 6 months old to qualify for the incentive. If the opportunity is greater than 6 months old, the Ecosystem Sales Manager should reject the registration and work with the partner to see if there is an upcoming licensing opportunity that would qualify for partner services.
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.
Area Sales Manager (ASM) for final review and action (if approved by Ecosystem Sales Manager)
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.
Confirm alignment with the Ecosystem Sales Manager and GitLab Sales Rep prior to providing final approval or rejection on the registration.
Click Approve/Deny/Return Registration.
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.
Post-Approval
The registration and opportunity records will be updated with the approval information.
A Service Attached registration will not populate the Partner Sourced Deal Registration section of an opportunity. Click the related list link at the top of the opportunity to locate the Service Attached registration. This will bring you to a list of any registration attached to the opportunity, including the Service Attached Registration.
Alternatively, you can scroll to the “Registrations” section toward the bottom of the opportunity.
The Partner delivers services, either before or after the license sale is completed.
The services can be completed up to six months before or after the license opportunity closes.
Services delivered more than six months before or after the opportunity closes do not qualify for the Services Attach Rebate.
The Partner provides Proof of Execution (POE) to partnersupport@gitlab.com which can include customer signed statement of work (SOW) or other customer-verified POE.
The Ecosystem Operations team will ensure the DR - Deal ID is listed on the POE, upload it to the opportunity, and chatter the Ecosystem Sales Manager. The Ecosystem Operations team will then update the Service Attached Registration Status to Closed-Won.
After the close of quarter in which the software deal is closed-won (rebate payouts are reported and paid after each GitLab quarter close), Ecosystem Operations will pull a report of Closed-Won Service Attached Registrations for rebate payments.
Ecosystem Operations submits the payments to Coupa for reseller payouts. Resellers should receive payment within 45 days of the start of the new quarter.
Rebate payouts will be reported and paid after each GitLab quarter close.
Additional Information
The resale discount will be administered as an upfront discount from the GitLab license price on the most recent product sale net license price. The Service Attach incentive will be paid out at the end of each GitLab fiscal quarter.
Partners must hold an approved Service Attached Registration and provide proof of performance/execution to qualify for the incentive.
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:
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.
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
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
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:
From the Related List Quick Links at the top of the opportunity page, hover your cursor over Influence Partners and select New Influence Partner
Add a partner to the Influence Partner field using the lookup button
Select the applicable Influence Type:
Customer executive engagement and advocacy
Working side by side with GitLab on customer pursuit.
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
Provide a detailed description of the partner’s influence activities using Description of Partner Influence
Do not edit Opportunity Owner, ASM, Ecosystem Sales Manager and Customer Account. These will auto-populate upon save
Save the Influence Partner Record
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 “Letter of Authorization” button along the top of the 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.
External Communication: Email partnersupport@gitlab.com to include a partner or other external stakeholder for help with partner-related requests. PHD team members monitor the queue and email inbox throughout the day in all time zones.
Tagging Ecosystem Operations in Salesforce
Here is a general list of items you can chatter @Partner Operations for assistance with in Salesforce. Please continue to refer to our respective handbooks for in-depth information before tagging.
Most internal Salesforce (SFDC) and Vartopia system questions and changes, including:
Channel Compensation Questions
Ecosystem Manager Territory Mapping and Account Assignment
Deal Registration Record Updates
Specific Ecosystem Quoting Questions (Discounts, Approvals,etc.)
Distributor Quote Requests
SFDC Reporting Issues
Most partner-facing questions and changes to the Impartner (Partner Portal) system, including:
General Channel Program Questions
Partner Portal Access Issues and Resources
Reseller Deal Registration Activation
Partner Training and Certifications
Partner Rebates and Payment Set-Up in Coupa
Partner Not-for-Resale (NFR) Licenses
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.
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, click on Library 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: Nick Scala, 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.
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 Salesforce Dashboards
The following partner forecast dashboards have been published for FY25. 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.
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.
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.
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.
This page documents frequently asked questions from our GitLab Sellers on how to collaborate with partners throughout the sales process. Please contact us at #partner-programs-ops in slack or @Partner Operations in SFDC chatter if you have any questions or would like to see another question/answer documented on this page.
Deal Registration
When should my partner submit a Deal Registration? What opportunities are they able to register?
GitLab has a Partner Sourced Deal Registration (DR) program for Resale, MSP, and Referral opportunities. The partner should submit a Partner Sourced DR for an opportunity where they are bringing net-new business to GitLab, which can apply to opportunities for new logo, co-term add-on/upsell, or add-on/upsell as part of a renewal. Note, we can only approve one Partner Sourced DR for an opportunity, as only one partner can source a deal. Partners should not submit a Partner Sourced DR if they did not source the opportunity, and will generally receive Co-Sell discounts for these deals. Please refer to GitLab’s Internal Incentive Guide for more information on partner program discounts.
This page documents frequently asked questions from our partner community on how to collaborate with GitLab throughout the sales process. Please contact us at partnersupport@gitlab.com if you have any questions or would like to see another question/answer documented on this page.
Deal Registration
When should I submit a Deal Registration? What opportunities am I able to register?
GitLab has a Partner Sourced Deal Registration (DR) program for (i) Resale, (ii) MSP, and (iii) Referral opportunities. You should submit a Partner Sourced DR for an opportunity where you are sourcing net-new business for GitLab, which can apply to opportunities for new logo, co-term add-on/upsell, or add-on/upsell as part of a renewal. Note, there can only be one Partner Sourced DR approved for an opportunity, as only one partner can source a deal. You should not submit a Partner Sourced DR if you did not source the opportunity, and you will generally receive Co-Sell discounts for these deals. Partner Sourced and Co-Sell opportunities are discussed further in the Partner handbook.
