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

Channel Operations

  1. You are here:
  2. Handbook
  3. Sales
  4. Field Operations
  5. 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.

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 Channel 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. Chose a template

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

3. Before you submit

Please ensure your issue is unassigned as our team will be assigning issues based on the team bandwidth.

Issue Templates Video

Communicating with the Channel 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
channel-fyi Updates to the Channel & Sales teams on Channel program, operations, enablement and marketing. Questions from team members should be posted on the #channel-programs-ops or #channel-sales blank any Channel Operations, Channel Programs, Michelle Hodges, Nima Badiey
channel-program-ops Questions and comments about channel programs and operations https://about.gitlab.com/handbook/resellers/ and https://about.gitlab.com/handbook/sales/field-operations/channel-operations/ any any
channel-sales Questions and comments about opportunities, partner connections, field engagement, and other channel sales questions blank any any
channels-emea A channel for the EMEA channels team and stakeholders to collaborate Team coverage: Matthew: France, Russia, Spain, MEA; Ilaria: DACH, Poland, Italy, Cze; Kevin: UK, I, Nordics, BeneLux; Bastian: Commercial (Open partners pan EMEA + Amazic); Camille: Partner Support Helpdesk; Adrian: Solutions Architect - pan EMEA any any
channels-amer A channel for the AMER channels team and stakeholders can collaborate Team coverage: Jennifer Bailey: Canada & US - West; Sergio Cortes: LATAM & US - Central; Shannon Thomas: US - East; Kyle Olsen: AWS; Kasim Ahmad: GCP; Annie Rooke: Director any any
pub-sec-channels A channel for the Pubsec channels team and stakeholders to collaborate Team Coverage any any
apac_partners A channel for the APAC channels team and stakeholders can collaborate blank any any
channel-services Questions and comments about channel services program, enablement and field engagement   any any
channel-team-announcements* Updates to channel team members ONLY https://about.gitlab.com/handbook/resellers/ and https://about.gitlab.com/handbook/sales/field-operations/channel-operations/ channel and alliance team members ONLY Channel Operations, Channel Programs, Michelle Hodges, Nima Badiey

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.

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.

For ease with quoting, there is a Partner Discount Cheat Sheet for use by internal GitLab Team Members.

Channel-specific quoting instructions can be found in the Deal Desk Quote Configuration handbook page.

Opportunity Requirements to Request a Quote

Sales Reps are responsible for quoting all GitLab direct and reseller-direct quotes. For quotes going through distribution, please review "Transacting Through Distribution" and "Internal Distributor Quote Requests" below, then Chatter @Partner Operations on the opportunity with the following information:

Transacting Through Distribution

Distributors are equipped to self-quote new business or other order types without receiving an official GitLab quote, as long as partner discounts are confirmed to them. So, there may be times, especially in multiple bid scenarios, where you may not be aware of all the partners bidding on an opportunity if they haven’t submitted a Deal Registration, until we receive a PO.

If a reseller requests a quote from a distributor via the aliases above, the distributor will contact partnerorderops@gitlab.com to request an official quote and Partner Operations will generate the quote for the distributor to generate their official PO to place an order.

Internal Distributor Quote Requests

If you are working with an Open partner and need a distributor quote sent, please email the necessary quote information and opportunity link to partnerorderops@gitlab.com.

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 or the Opportunities Sales Qualified Source = Channel 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 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 two business days. There must be contact with the registering partner within two business days, 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 there is a Service Attach Type in the Service Attach Type field.
    • Note that there could likely be another Partner Sourced Deal Registration for the license resale opportunity. The resale registration will populate in the opportunity fields, while the Service Attach registration will only be linked to the opportunity.
    • 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.
  3. Discuss the opportunity with the appropriate AE/SAL and decide to either approve or deny the registration(s).
  4. Click “Link/Create Opportunity.” 9-Link_Create_Opp
  5. 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.
    • 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.
  6. Click Approve/Deny/Return Registration. 7-Approve_Deny_Return
    • The following steps consider the registration approved.
  7. 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.
  8. 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
  9. 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.
  10. Partner delivers services, either before, during, or after the license sale completes.
    • The services can be completed up to six months before the resale opportunity closes, or up to six months after the resale opportunity closes. Services delivered more than six months before or after the resale opportunity closes do not qualify for the Service Attach Rebate.
  11. The Partner goes through the Proof of Execution process:
    • The partner sends the Proof of Execution (POE), customer signed statement of work (SOW), or other customer-verified proof of execution to Partnersupport@gitlab.com.
    • The partner completes the POE form.
  12. The Partner Help Desk will ensure the Deal ID is listed on the POE, upload it to the opportunity, and chatter the Channel Manager. The Partner Help Desk will then update the Service Attach Deal Registration Status to Closed-Won.
  13. After the close of quarter in which the resale deal is closed-won*, Channel Operations will pull a report of Closed-Won Service Attach Deal Registrations for rebate payments. Channel Operations sends the report to Partner Help Desk.
  14. Partner Help Desk 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

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

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, 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, ensuring that only authorized partners can access the link.

The partner will be prompted to input basic company information that will auto-fill the letter of authorization. When they click submit, an email will be sent to the Partner Help Desk, who will need to validate that the partner is authorized, and then click the “approve” button in the email.

Upon approval, the letter of authorization will be automatically sent to the legal team who will approve and stamp the letter before sending it directly to the partner via email. The letter is good for one calendar year from the date on the letter.

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. Please review Working with Partner Help Desk.

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.

## 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.

Business Plans

The business plans are created in Salesforce and our partners can access the content through the partner portal (view only access)

How to get started:

  1. Watch the training and video and understand the Business Planning Module.
  2. Identify who from your partner contacts should have access to the plan on the partner portal.
  3. Create a new plan for your FY23 Select Partners in Salesforce.

Note: use the following format for the Business Plan Name field: Partner name, Fiscal year, Business Plan e.g. BoxBoat FY23 Business Plan

Note: if you are creating a Business Plan for a Pubsec partner, please include “Pubsec” after partner name e.g. BoxBoat (Pubsec) FY23 Business Plan

  1. Please submit your contacts in the Business Plan Sheet for the Channel Operations team to grant them access.
  2. Review status with Select Partner during QBR’s

Feedback: You can submit your feedback on the second tab of the Business Plan Sheet

Channel Ops DRI: Aura Villalobos or post questions in #channel-programs-ops.

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

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.

FY23 Channel & Alliance Comp & Splits Matrix

FY23 Channel & Alliance Comp FAQ

FY23 Channel & Alliance Comp Exception Process

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.

Open in Web IDE View source