Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Channel Operations

Welcome to the Channel Operations page

Pinned Announcement

New partner program changes are effective on August 15, 2021. Please visit the Channel Ops Document Library for updates and collateral. For information about the program (not operational), visit the Channel Partner Handbook.

Meet the Team

Who We Are

How to Contact Us

The #channel-programs-ops Slack channel can be leveraged for inquiries. Both the Channel 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 Channel Operations Issue Board for operational issues, or the Channel Team’s Issue Board for program issues.

The Channel Operations Issue Board

On the Channel Operations Issue Board, each column represents a type of request (feature request, alliances, data & reporting, etc.). When you submit a request to the Channel Operations board, the team will assign the issue and add the corresponding tags. The Channel 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 Channel Operations and select New Issue.

Channel & Alliance SFDC Dashboards
Google Sheet Reporting
Sisense Reporting

Reports by Territory

AMER
APAC
EMEA
PUB-SEC

For a global view of current and next fiscal quarter channel renewals, click here. All required team reporting is included above. In the event you need a special report, please open an issue on the Channel Operations Board. For the reporting training video hosted by the Channel Operations team, as well as quick reference “cheats” to help with your Salesforce reporting, click here.

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 Partner Sourced Deal Registration logic needs to match Sales Qualified Source = Channel Generated on the opportunity.

For more information: Deal Registration Program Overview.

Transacting Through Distribution

As of May 3, 2021, all partners in India must transact through our distribution partner, Redington. For the US and EMEA, we encourage Open Partners to purchase through Distribution, but it is not a requirement.

All US PubSec deals are transacted through Carahsoft or Immix (GSA only).

Billing Contacts in Partner Accounts

When onboarding a new partner that will be purchasing directly from GitLab, a billing account must be created. Upon being notified of a new partner, the Channel Manager should ensure there is a contact created within the account that represents the partner's account's payable contact information. Chatter '@billing-ops' on the account record, provide the accounts payable contact information, and ask for a billing account to be set up. Partner accounts that will transact via distribution do not need a billing account set up. More information on billing accounts can be found on the Billing Operations Handbook Page.

Quoting Requirements for Channel Deals

When a deal is being transacted via the Channel, and a discount other than the defined Program discounts are 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.

Opportunity Requirements to Request a Quote

Channel Managers or Sales Reps are responsible for quoting all GitLab direct and reseller-direct quotes. For quotes going through distribution, chatter @Partner Help Desk on the opportunity with the following information:

SFDC Field Definitions

Section I: Partner Sourced Deal Registration

1-PSDR_Definitions

Section II: Primary Partner Quote Data (Closed-Won Order Data)*

2-Primary_Quote_Definitions

Section III: Partner Contribution Data

3-Partner_Contribution_Definitions

Services Resale

Incumbency Renewals

Tender Offers

Program Compliance

Unauthorized Partners

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.

Channel Reporting and Tagging

4-Ch_Reporting_Tagging

Definitions

  1. Deal Path: How the deal is transacted. Values can be Channel, Direct, or Web. Includes Referral Ops for Channel.
  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. Initial Source: SFDC Lead value that is populated based on lead source. Will default to CQL (Channel Qualified Lead) when a Partner submits a Partner Sourced Deal Reg and an Opportunity does not already exist in the system.
  4. SQS (Sales Qualified Sourced): Who converts/creates the Opportunity in SFDC. Can only be 1 value
  5. Deal Type: Whether or not the partner is taking paper or not
  6. Order Type: Customer order designation in SFDC. New First Order or Growth

Use Cases

Default Logic

  1. If Partner Sourced Deal Reg = True and no opportunity exists, then Initial Source = CQL > SQS = Channel Generated
  2. Alliances and OEM Logic: No Deal Registration applied but if Initial Source = CQL then SQS = Channel Generated

SFDC Opportunity Source Field Values for Channel

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. 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 CoSell 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 SAL, 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 SAL with whom they’ve discussed this. When that email address is inputted into the form and the form is submitted, that SAL will receive notification of a Pubsec Co-Sell opportunity.
  4. The SAL 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 SAL’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 SAL 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 #channel-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:

Partner Sourced Deal Registration

There are three types of Partner Sourced Deal Registrations within the GitLab Partner Program. For step-by-step instructions on how to process each of these opportunities, see the specific sections: Resale, MSP, and Referral .

The Partner Sourced Deal Registration program not only rewards partners for bringing net-new business to GitLab, but also rewards partners for selling their own services into the customer account.

Channel Managers are responsible for reviewing Partner Sourced Deal Registrations and must either approve, deny, or return the registration for additional information. It is recommended that the Channel Manager communicate with the applicable GitLab Sales Team Member during this process.

The SLA for GitLab to respond to partners on a Partner Sourced Deal Registration is 48 hours. There must be contact with the registering partner within 48 hours, whether it be approval, denial, or a request for more information.

While multiple partners can submit a deal registration for an opportunity, only one Partner Sourced Deal Registration can be approved for a specific opportunity. As a reminder, Partner Sourced Deal Registrations are opportunity-based and partners cannot register an account.

Partner Sourced Deal Registration: What to Expect

To view individual processing steps for each type of Partner Sourced Deal Registration Opportunity, click the appropriate type of deal: Partner Sourced Deal Registrations for Resale | MSP | Referral.

Note: The Partner Portal is hosted by Impartner and has SSO enabled with Vartopia, the partner-facing Deal Registration system. GitLab uses a third-party managed services team to help manage administrative processes for Deal Registration..

GitLab has three Deal Registration programs: Partner Sourced Deal Registration for resale opportunities, MSP Deal Registration for partners providing their own managed services, and Referral Deal Registrations for partners who do not transact the business they bring to GitLab.

Partner Sourced Deal Registration: How it Works

When a partner submits a Partner Sourced Deal Registration, the Managed Services team will handle the initial submission. Upon record creation, the following occurs:

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

The Managed Services team will evaluate the registration, link it to the appropriate customer account and contact in SFDC, and then send an email to the applicable Channel Manager to approve/deny the registration.

By default, the Channel Manager is assigned as the Account Owner in the Partner Account in SFDC. GitLab’s Managed Services team will manually reassign the registration to the correct owner in cases where there may be more than one owner due to segment or territory. There is a 4 hour SLA for the Managed Services team once the Deal Registration has been submitted by the Partner.

Once a Channel Manager is assigned a Partner Sourced Deal Registration, they receive an email notification. Channel Managers can also view the registrations in their list view within the SFDC Registration tab. To view the details of the Registration they can either click on the link in the email or the specific record in the Registration view in SFDC.

Rules of Engagement for Partner Sourced Deal Registration

5-Extend_DR

Partner Sourced Deal Registration System Status and Information

Deal Registration Reporting & Tools

Partner Sourced Deal Registration: Resale Opportunities

Partner Sourced Deal Registrations for resale opportunities reward partners for bringing net-new business to GitLab. With an approved Partner Sourced Deal Registration, a partner will receive a deeper discount than Partner Co-Sell opportunities, according to the [GitLab Partner Program(https://handbook/resellers/).

To process a Partner Sourced Deal Registration for a resale opportunity, follow the steps below:

  1. Click the link in either the email or the Deal Registration Report to open the registration object in Salesforce.
  2. Check to make sure that the Partner Sourced Deal Registration type says resale.
  3. Click “Link/Create Opportunity.” 9-Link_Create_Opp

  4. On the Link/Create Opportunity page, first search for the opportunity in the provided list and/or by doing a “Global Search.”
    • If the opportunity exists, click “Select” next to the opportunity name. You will then be brought back to the deal registration record. 6-Link_Opportunity_Select
    • If there is no matching opportunity, click “Create New,” and then choose “Standard” in the Opportunity Type. The system will then populate all the necessary fields, including the DR-mapped fields. Click “Save” and you will be brought back to the registration record.
  5. Click Approve/Deny/Return Registration. 7-Approve_Deny_Return
  6. On the next page, choose approve, and if you have a message for the partner about the deal, you can add that into the “comments” section. This is not required, but anything included in this field will be sent back to the partner. 8-Approve_Deny_Details.png
    • If a distributor is involved, choose the distributor in the field that appears. If no distributor is involved, this field can be left blank.
    • Both the registration record and the opportunity record will be updated with the approval information.
  7. If you have created a new opportunity during this process, chatter @sales-support and request that the opportunity owner be updated to the name of the sales team member who owns the customer account.
  8. For quotes going through distribution, please chatter @Partner Help Desk with all the information for quote creation.
    • The deal registration form is not a quoting tool and will not have all the information needed to create the quote. You must get this information from the partner or elsewhere before requesting the quote.

Partner Sourced Deal Registration: MSP Opportunities

Partner Sourced Deal Registrations for MSP opportunities reward partners for managing products and services for their customers accounts. With an approved Partner Sourced Deal Registration for MSP, a partner will receive a different discount than other resale opportunities, according to 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.

To process a Partner Sourced Deal Registration for an MSP opportunity, follow the steps below:

  1. Click the link in either the email or the Deal Registration Report to open the registration object in Salesforce.
  2. Check to make sure that the Partner Sourced Deal Registration type says MSP.
  3. Click “Link/Create Opportunity.” 9-Link_Create_Opp
  4. On the Link/Create Opportunity page, first search for the opportunity in the provided list and/or by doing a “Global Search.”
    • If the opportunity exists, click “Select” next to the opportunity name. You will then be brought back to the deal registration record. 6-Link_Opportunity_Select
    • If there is no matching opportunity, click “Create New,” and then choose “Standard” in the Opportunity Type. The system will then populate all the necessary fields, including the DR-mapped fields. Click “Save” and you will be brought back to the registration record.
  5. Click Approve/Deny/Return Registration. 7-Approve_Deny_Return
  6. On the next page, choose approve, and if you have a message for the partner about the deal, you can add that into the “comments” section. This is not required, but anything included in this field will be sent back to the partner. 8-Approve_Deny_Details.png
    • If a distributor is involved, choose the distributor in the field that appears. If no distributor is involved, this field can be left blank.
    • Both the registration record and the opportunity record will be updated with the approval information.
  7. Manually change the Account Namefield to the partner name. This should not be the name of the customer.
  8. If you have created a new opportunity during this process, chatter @sales-support and request that the opportunity owner be updated to the correct Sales Rep that owns the end-user account, even though the opportunity is created under the Partner MSP account.
  9. When creating a quote for an MSP opportunity, select the MSP quote template
    • Invoice owner: The MSP Partner (same as DR-Partner referenced above).
    • Special Terms and Notes: Name of the End-user Customer (the MSP owns the licenses on behalf of).
  10. For quotes going through distribution, please chatter @Partner Help Desk with all the information for quote creation.

The deal registration form is not a quoting tool and will not have all the information needed to create the quote. You must get this information from the partner or elsewhere before requesting the 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. With an approved Partner Sourced Deal Registration for a referral, a partner will receive a back-end rebate, processed quarterly, according to the GitLab Partner Program.

To process a Partner Sourced Deal Registration for a referral opportunity, follow the steps:

  1. Click the link in either the email or the Deal Registration Report to open the registration object in Salesforce.
  2. Check to make sure that the Partner Sourced Deal Registration type says referral.
  3. Click “Link/Create Opportunity.” 9-Link_Create_Opp
  4. On the Link/Create Opportunity page, first search for the opportunity in the provided list and/or by doing a “Global Search.”
    • If the opportunity exists, click “Select” next to the opportunity name. You will then be brought back to the deal registration record. 6-Link_Opportunity_Select
    • If there is no matching opportunity, click “Create New,” and then choose “Standard” in the Opportunity Type. The system will then populate all the necessary fields, including the DR-mapped fields. Click “Save” and you will be brought back to the registration record.
  5. Click Approve/Deny/Return Registration. 7-Approve_Deny_Return
  6. On the next page, choose approve, and if you have a message for the partner about the deal, you can add that into the “comments” section. This is not required, but anything included in this field will be sent back to the partner. 8-Approve_Deny_Details
    • If a distributor is involved, choose the distributor in the field that appears. If no distributor is involved, this field can be left blank.
  7. Both the registration record and the opportunity record will be updated with the approval information.
  8. If you have created a new opportunity during this process, chatter @sales-support and request that the opportunity owner be updated to the name of the sales team member who owns the customer account.
  9. For quotes going through distribution, please chatter @Partner Help Desk with all the information for quote creation.

The deal registration form is not a quoting tool and will not have all the information needed to create the quote. You must get this information from the partner or elsewhere before requesting the quote.

Service Attach Opportunities

GitLab incentivizes partners that sell their own professional services into a customer environment at the time of a GitLab product sale. To be eligible for this back-end rebate, the partner needs to submit a Service Attached Deal Registration that is approved by a GitLab Channel Manager. 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.

When a Channel Manager either receives an email alert, or sees a new registration in the Deal Registration Report, the following steps should be taken:

  1. Click the link in either the email or the Deal Registration Report to open the registration object in Salesforce.
  2. Check to make sure that the Partner Sourced Deal Registration type says resale.
  3. Click “Link/Create Opportunity.” 9-Link_Create_Opp
  4. On the Link/Create Opportunity page, first search for the opportunity in the provided list and/or by doing a “Global Search.”
    • If the opportunity exists, click “Select” next to the opportunity name. You will then be brought back to the deal registration record. 6-Link_Opportunity_Select
    • If there is no matching opportunity, click “Create New,” and then choose “Standard” in the Opportunity Type. The system will then populate all the necessary fields, including the DR-mapped fields. Click “Save” and you will be brought back to the registration record.
    • A Service Attach Deal Registration MUST attach to a license sale opportunity. There will almost always be an opportunity in the system, and it is best practice for a Channel Manager to process the Partner Sourced Deal Registration first, if there is one, before processing the Service Attach Deal Registration.
    • The opportunity must be either new or no older than 6 months old to qualify for the incentive. If the appropriate opportunity is older than 6 months old, the Channel Manager should deny the registration and work with the partner to see if there is an upcoming licensing opportunity that would make sense for the services.
  5. Click Approve/Deny/Return Registration. 7-Approve_Deny_Return
  6. On the next page, choose approve, and if you have a message for the partner about the deal, you can add that into the “comments” section. This is not required, but anything included in this field will be sent back to the partner. 8-Approve_Deny_Details
    • If a distributor is involved, choose the distributor in the field that appears. If no distributor is involved, this field can be left blank.
  7. Both the registration record and the opportunity record will be updated with the approval information.
    • A Service Attach registration will not populate the Partner Sourced Deal Registration section of an opportunity. To find the Service Attach Deal Registration, click the related list link at the top of the opportunity. This will bring you to a list of any registration attached to the opportunity, including the Service Attach Deal Registration. 10-Reg_Related_Lists
    • Alternatively, you can scroll to the “Registrations” section toward the bottom of the opportunity. 11-Reg_for_Svc_Att
  8. If you have created a new opportunity during this process, chatter @sales-support and request that the opportunity owner be updated to the name of the sales team member who owns the customer account.

Rebate payouts will be reported and paid after each GitLab quarter close.

Additional Information

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

Chatter Aliases to Use for SFDC Opportunity and Account Tagging

When working within an opportunity (or account) in SFDC, please be sure to tag the appropriate team for fastest tag management and to keeo our deals moving smoothly.

Tag Reason Correct Chatter Alias
Update Partner Account Owner @ Partner Operations
Update Customer Account Owner @ Sales-Support
Update Opportunity Owner @ Sales-Support
Update SQS @ Partner Operations
Move a linked Deal Reg @ Partner Help Desk
System issue related to Deal Reg info @ Partner Operations
System issue related to quote @ Sales-Support & @ Partner Operations
Extend a Deal Reg @ Partner Operations
Account Data Review @ Partner Operations
Opportunity Compensation Questions @ Partner Operations
ARR Review @ Sales-Support & @ Partner Operations
Merging Records @ Partner Operations
Opportunity Approval @ Partner Operations
Opportunity Data Review @ Partner Operations
Opportunity Question @ Partner Operations
Process Question @ Sales-Support & @ Partner Operations
Quote Approval @ Sales-Support & @ Partner Operations
Quoote Review @ Sales-Support & @ Partner Operations
System Error @ Partner Operations
Partner Discount Matrix Questions @ Partner Operations
Standard Approval Matrix Questions @ Sales-Support
Marketplace Private Offer Requests @ Partner Operations
Partner Deal Registration Access @ Partner Help Desk
Setup Billing Accounts @ Billing Ops
Invoice Issues/Questions @ Billing Ops
Basic Quote Assistance @ Sales-Support
Ramp Deal @ Sales-Support
Flat Renewal @ Sales-Support
Contract Reset/Co-term @ Sales-Support
Non-standard Deal Structure @ Sales-Support & @ Partner Operations

Partner Help Desk Support and Communication

Internal Team Members: Chatter @Partner Help Desk in Salesforce or for general questions, post in the Slack channel #channel-programs-ops.

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.

Partner Help Desk’s primary internal communication channel is Salesforce Chatter. When you chatter @Partner Help Desk, it will automatically create a case in the Partner Help Desk (PHD) queue.

Please do not tag PHD team members directly in chatter or make a request through Slack direct message. Always use @Partner Help Desk for SFDC requests or post in #channel-programs-ops in Slack for general questions.. This ensures our team is working as efficiently as possible for everyone and that you are covered in case the team member who replied first becomes unavailable. If someone is working on a case, they will continue to support until the case is closed. If a matter was resolved, but needs to be revisited, please chatter @Partner Help Desk to reopen a case. To Chatter the PHD team, tag @Partner Help Desk in Chatter on the related opportunity or account page and a short sentence on your request. If the PHD team needs more information or needs to pull in another team, we will follow up directly via Chatter. If you need to involve a partner, please email partnersupport@gitlab.com, instead of an individual PHD team member so any team member can jump in as something moves forward.

Program and Incentive Definitions

Partner Applicant Approval / Denial - Granting Portal Access

Partner Program participation sign ups must be initiated by the Partner in the Partner Portal application form which can be found here. In the partner application process, channel partners review the partner contract, including both the resale and referral addenda, review the partner program guide, complete their application form and agree to program terms and conditions. Technology partners are not able to agree to the terms and conditions during the application process. If an authorized representative of the channel partner accepts the agreement terms, they (or the person entering the application) will need to select “Yes” that they agree to terms on the application form. Once they have agreed, they will automatically be set to “ Authorized” and will get immediate access to the partner portal. At this time, partners will be set up in both Salesforce and the partner portal at Authorized and their track set to Open. The partner will receive an email confirming the receipt of their application, and applicable Channel Sales or Alliance Manager will receive a New Partner notification email from Partnersupport@gitlab.com notifying there is a new partner applicant in that region. Channel Sales Managers will be notified of each partner application in their regions, whether they agreed to the terms or not. Upon receiving notification they will be responsible for reviewing the partner’s information and deactivating any inappropriate partners. They will also need to set the Partner Type in Salesforce for newly authorized partners. For partners that have questions about the contract or need to negotiate terms and conditions, Channel Sales Managers are responsible for working with the partner offline to address questions and come to agreement on program terms. Upon receiving the New Partner Applicant notification email, the applicable Channels Sales Manager needs to complete the following:

  1. Contact the partner and qualify them.
  2. If the decision is to move forward with the partner first check to see if a partner account already exists in Salesforce. If it is a duplicate, request for the accounts to be merged by the Channel Operations team. If the decision is to deny the partner then go to step #7.
  3. To start the contracting process click the Legal Request button in SFDC on the partner account record.
    • Request the appropriate contract addendum (Resale, Referral/Services or both OR MSP OR OTHER). Default should be Resale and Referral/Services.
    • The detailed process for a legal request can be found on the legal team's handbook page.
  4. Once the contract is fully executed and attached to the partner account record in SFDC the following fields need to be updated by the Channel Sales Manager and are required(*) in order to save the account.
    • *Change Partner Status = Authorized.
    • *Select Partner Type.
    • For partners that signed standard contract terms, set Partner Program Status to “New”.
    • Please update the partner record to be as complete as possible.
    • For additional information on the Partner Program review here
  5. Once a partner is authorized, each SFDC contact for that partner will automatically receive a message with login credentials to the portal.
  6. Additional partner employees can go to partners.gitlab.com to register. Once they are linked to an authorized partner account (they must select the correct account upon registering), they will automatically receive a message with login credentials. If the account is still a Prospect they will not have access until the account has an executed contract and is moved to Authorized.
  7. If the decision is to not move forward with the partner, the Channel Sales Manager needs to set Partner Status = Denied. Technology partners use the same form, but are not able to agree to the terms and conditions. Once they submit the form, they will be set to active. If the Alliances team wants to establish a contract with the partner, they must follow the Legal Request process in Salesforce. If for any reason, a partner account needs to be created in Salesforce directly, requests for account creation can be made to #channel-programs-ops within Slack. Visit the Partner Applicant/Partner Portal FAQ for additional information.

Channel Partner Price Files

GitLab will provide Channel Price Files for distributors and direct resellers approximately 30 days before intended changes. Only Channel Managers should be sharing Channel Price Files. The following price files are provided by Channel Ops:

Locating and Sharing Channel Price Files

Price Files can be found in this folder.

When sharing a Channel Price File with a partner (either a distributor or reseller), please do NOT share the folder or file location. To share a document, please either copy it into your own google drive and update the permissions accordingly when you share a link, or attach a downloaded copy to an email to a partner. No partners should be given access to this folder. Only Channel Managers should be sharing Channel Price Files.

Naming Conventions and Which File to Use

Within the Price List Folder, there are other folders. For the current active price file, always use the one with the most recent date that has not passed yet. The folder name will also say "ACTIVE" at the front of it.

12-Price_File_Folders

13-Price_File_List

If there are any questions, please reach out to the #channel-programs-ops Slack channel.

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 #alliances 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 GCP and AWS 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:

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:

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:

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:

Requesting Google Cloud Credits

Required fields when requesting Google Cloud Credits on an Opportunity

  1. Have you engaged with the GCP Team already? (Drop down: Yes, No)
  2. Customer open to being a reference? (drop down: logo use, case-study, joint speaking session, etc.)
  3. Credits being requested (Sales Rep enters in the amount of credits required to close the deal) Once all required information is submitted, the request will be routed internally for approval. If approved, the opportunity is updated to ‘approved’ and the opportunity owner is notified via email. GCP Credits are provided directly to the customer by the GCP Team after acceptance of the private offer. For more information, visit the Private Alliance Handbook.

IBM Partner Requests & QTC Process

  1. IBM Partner Requests: Visit the Private Alliance Handbook
  2. Common Use Cases:
    • IBM Partner Request
    • IBM/GitLab Identify Opportunity
    • IBM Partner Order Additional Information on the QTC Process is available in the Private Alliance Handbook.

Compensation on Channel Opportunities

Channel Compensation Policy for Cross-Geo Partner Deals

Cross-Geo Partner Deals are defined as opportunities that land (ship to) a GEO that differs from the Partner's GEO headquarters (i.e. ‘Landing GEO’ vs. ‘HQ GEO’). GitLab must support Cross-GEO Deals in order to strengthen and enforce the channel business behaviors: collaboration, results and efficiency. The primary focus of Channel Managers is building revenue in their assigned territory and GEO. Therefore, managers should engage their peers on Cross-GEO Deals to ensure success for both GitLab and the Partner. In the event of a Cross-GEO Deal, the Channel Manager located in the ‘Landing GEO’ is the Channel Manager of record and receives compensation on the opportunity. The expectation is that the ‘Landing GEO’ Channel Manager takes lead on the opportunity and works with the partner and customer to drive the deal. To ensure correct compensation, the applicable Channel Manager needs to populate their name in the Channel Manager field in SFDC on the Opportunity.

Channel Neutral

Comp Neutrality applies to all GitLab Opportunities where a Partner is involved in the physical transaction (takes paper) and a Partner Program discount is applied on the executed Partner Order Form. The maximum Comp Neutral payout is based on the applicable GitLab Partner Program discount matrix. If additional discount is needed in order to close the deal, that portion is not eligible for Comp Neutrality. In the event a lesser discount is applied on the deal then what the Partner Program allocates, then the lesser discount will also be what is calculated for Comp Neutrality. Other factors:

2-Tier Opportunities

If the Opportunity is going through a 2-Tier Channel (Distributor + Reseller), both Partner Accounts must be included on the Opportunity in the Partner Information section in order for both Program discounts to apply AND for Comp Neutral to calculate on both. Reseller should be in the Partner field and the applicable Distributor in the Distributor field on the Opportunity.

Opportunities with GCP and AWS

For deals going through GCP and AWS, the Partner fields should still be filled out on the Opportunity but comp neutral will not calculate until the deal closes as partner discounts are done after the quote/order form is generated. Deal Desk will assist with this process.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license