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

Channel Operations

Welcome to the Channel Operations page

Pinned Announcement

With the new partner program changes that went into effect on May 3, 2021, the Channel Operations Team created a brief document for internal GitLab Team Members to answer a few basic questions about the system and operational changes to go along with the update. To view this FAQ, click here. For information about the new program details (not operational), click here.

Meet the Team

Who We Are

How to Contact Us

The #channel-programs-ops Slack channel is monitored by several teams to provide direction and guidance. The entire Channel Operations team can be reached via this channel.

The Channel Operations Issue Board

The channel operations issue board can be found here. 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, visit this link and choose “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 here. 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 can sign up to become authorized here.

Policy and Process

All Partner Soured and Partner Assist channel opportunities require a Partner to submit a Deal Registration via the Partner Portal in order to receive programmatic discounts. Fulfillment channel opportunities do not hold this requirement. In the event that a Partner does not submit a Deal Registration (excluding: Alliances and GSIs), but it is a Partner Sourced deal, the logic needs to match Sales Qualified Source = Channel Generated on the opportunity. For more details on the partner deal registration process and program, click here.

Transacting Through Distribution

As of May 3, 2021, all partners in India must transact through our distribution partner, Redington.

Quoting Requirements for Channel Deals

Any time a deal is being transacted via the Channel, a GitLab quote is required to be created in SFDC if any pricing is being offered other than MSRP (List Price) or the programmatic fulfillment discount.

At a minimum, a Draft Proposal needs to be created and provided to the Partner. If a Partner has an approved Deal Registration, then an approved quote needs to be created and provided to that Partner before they place an order.

Discounted quotes that are not in the system and sent to a Partner are not permitted. This includes providing product and pricing quotes details in email. This applies to all GEOs and Segments.

Only GitLab-authorized partners with at least one sales certification are able to receive a discounted quote and transact GitLab products.

SFDC Field Definitions

For more details on Partner Engagement definitions go here.

Channel Reporting and Tagging

Reporting_Tagging_Matrix_FY22Q2

Definitions

  1. Deal Path: How the deal is transacted. Values can be Channel, Direct, or Web. Also, includes Referral Ops for Channel.
  2. Deal Reg: Partner submits a registration for their opportunity via the Partner Portal. For the purposes of this matrix the assumption is the Deal Reg is approved.
  3. Initial Source: SFDC Lead value that is populated based on lead source. Will default to CQL when a Partner submits a Deal Reg and an Opportunity does not already exist in the system.
  4. SQS: Who converts/creates the Opportunity in SFDC. Can only be one value.
  5. DR - Partner Engagement: Partner value on the deal via the Partner Program definitions. This is manually selected in most cases.
  6. Order Type: Customer order designation in SFDC. New First Order or Growth.

Use Cases

  1. 1 and 3
    • Channel submits Deal Reg and no Opportunity exists in the system. Therefore the Initial source is CQL, and SQS and DR-Partner Engagement default to Channel and Partner Sourced.
      • This applies to both New and Growth orders.
  2. 2 and 4
    • AE Creates Opportunity prior to Deal Reg being submitted - CAM to escalate for exception.
    • Opportunity stalled and Channel helps to drive to closure - If channel is simply unsticking an open opp then this is technically Assist. Exceptions can be reviewed.
    • Aged opportunities that are closed and revived due to Channel - Automated clean up with Sales Ops stale Opp policy - Exception: In the event an exception is needed per the scenarios below and exception can be submitted for review and have the ability “override” and restate these are Channel SQS.

Default Logic

  1. Deal Reg = True and no Opp Exists then Initial Source = CQL > SQS = Channel, defaults to Partner Sourced.
  2. Alliances: Does not have same logic and currently need to be reported separately.

Deal Registration

Rules of Engagement for Deal Registration

Guidance for Deal Registration Processing

Why is this important?

Deal Registration Process

Note: The Partner Portal is 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.

When a partner submits a Deal Registration, the Managed Services team will handle the initial submission. Upon submission, the following things happen:

  1. An email is sent to the partner acknowledging that the deal registration has been successfully created.
  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.

Deal Registration Instructions/How to Manage a Deal Registration

The Channel Managers need to review the deal registration and either approve or deny. It is highly recommended to work with the applicable GitLab Sales Rep prior to taking action.

The SLA for GitLab to respond to partners on a 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 deal registration can be approved for a specific opportunity. As a reminder, deal registrations are opportunity based and partners cannot register an account.

Before approving or denying the Deal Registration the Channel Manager needs to check to see if an Opportunity already exists and either link or create one.

When a CSM receives an email about a deal registration to be managed, they should click the link to the reg and review the notes from the partner.

It is best practice for a CSM to respond to a licensing deal registration first, and a managed service deal registration second. The process to approve/deny a managed service deal registration is the same as a resale deal registration.

To Approve a Deal Registration

Reg_Record_Steps

Follow these steps in order:

Link_Opportunity_Select

  1. Click “Link/Create Opportunity.”
    1. On the Link/Create Opportunity page, first search for the opportunity in the provided list and/or by doing a “Global Search.”
    2. If the opportunity exists, click “Select” next to the opportunity name. You will then be brought back to the deal registration record.
    3. 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.
  2. Click Approve/Deny/Return Registration.
  3. 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.
    • If a distributor is involved, chose the distributor in the field that appears. If no distributor is involved, this field can be left blank.
  4. Both the registration record and the opportunity record will be updated with the approval information.
  5. Chatter @sales-support, @kim stagg, or @dennis zeissner and request that the opportunity owner be updated to the name of the sales team member who owns the customer account.

When a new customer account is created by "User Vartopia" during a deal registration, that customer account should be reassigned to the appropriate sales rep. For more information, click here, or chatter @sales-support on the newly created customer account.

To Deny or Request More Information on a Deal Registration

  1. Skip # 1 in the “Approve” process above, and click the “Approve/Deny/Return Registration.”
  2. Choose “Deny” or “Return.”
    1. If you choose “Deny,” either choose the standard denial reason, or type out the reason for denial. This will be sent to the partner.
    2. If you choose “Return,” be sure to fill in the comments section with what the partner needs to do to complete a deal registration for approval.

Correcting Registrations Submitted Incorrectly If a partner submits a deal registration incorrectly (example: the wrong type of deal registration, deal, or incorrect information), GitLab Team Members cannot update this. At any point during the opportunity (until it is closed), the DR - status field can be changed to "returned." This will send an alert to the partner that there needs to be an update made. Please be sure to communicate with the partner and help them to provide the most accurate information.

Deal Registration System Status and Information

Other Resources and Instructions

Any questions or issues, please reach out to the #channel-programs-ops Slack channel.

Other Channel Opportunities

Managed Service Provider (MSP) Opportunities

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.

With an MSP opportunity, the Sales Reps need to follow these additional steps in the creation of the opportunity:

  1. The opportunity must be created using the MSP partner account, NOT the potential customer on whose behalf they are purchasing.
  2. Change the opportunity owner to the correct Sales Rep that owns the end-user account, even though the opportunity is created under the Partner MSP account.
  3. Fill out the Partner and Deal Registration Information Section per the following:
    1. DR-Partner: this must list the MSP’s Partner account (same as the opportunity is created under)
    2. DR-Deal type: "MSP"
    3. DR-Engagement: Select applicable answer
      1. If there is an approved Deal Registration, the Partner data will automatically be added when the Deal Registration is linked to the Opportunity. The DR-Engagement will be the only piece that needs to be filled out.
  4. When filling out the quote for this opportunity, select the MSP quote template.
    1. Invoice owner: The MSP Partner (same as DR-Partner referenced above).
    2. Special Terms and Notes: Name of the End-user Customer (the MSP owns the licenses on behalf of).

Service Attach Opportunities

A Service-Attached Deal Registration needs to be created to track when a partner offers their own professional services along with GitLab licenses. This is separate from the Deal Registration for the license sale.

To track the Partner Services, the partner must register the deal on the partner portal.

Please follow the steps above in the Deal Registration Process

Next, select the opportunity that is applicable to the GitLab sales of licenses that the services are being performed for. This GitLab sale opportunity may be open or closed won.

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

Multiple-bid Process

For opportunities where there are multiple partners bidding on the same opportunity, it’s important that each partner gets the appropriate pricing for the opportunity.

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

Channel Tagging for PubSec FSI Deals - Temporary Exception Process

Effective Q2 FY22

This process is specifically designed to recognize FSI Assist opportunities only, that eventually require fulfillment quotes to transact.

In the event an FSI provides Assistance on a deal (per the GitLab Partner Program definition of Assist) then the following tagging on the PubSec Opp can apply. An FSI is a Federal System Integrator and can be identified as part of their Account Record in SFDC.

PubSec_TempProcess

The expectation is that the Quote will receive the Partner Program “Fulfilment” discount instead of the standard Assist discount. Since the Opportunity is tagged as Assist, this will trigger Channel Approvals on these quotes. The following comments should be added to the note section on the approval by the PubSec Channel Director:

“Discount exception approved due to interim FSI process”

Since PubSec does not qualify for Comp Neutral, comp neutral calculations will not be impacted.

Expectation is that the FSI account owner will receive quota retirement and comp on these Opportunities against their Assist component of their plan. Regional bookings will apply to the transacting Partner Account Owner/rest of the PubSec Channel team.

For any questions, please reach out to #pub-sec-channels.

SFDC Opportunity Source Field Values for Channel

SFDC Opportunity Fields:

*For additional definition and qualification of Deal Engagement type go here.

**For additional Source definition please visit the Marketing Handbook Page.

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 Program Discounts

Partners can find the discount table in the Asset Library on the GitLab Partner Portal.

Partner Engagement Types

Partner Sourced

Partner Assist Opportunity

Partner Fulfill Opportunity

Services Attach Opportunity

Services Resale

Incumbency Renewals

Tender Offers

Program Compliance

Unauthorized Partners

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.
  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-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. Each price file will have three formats: Google Sheet, Excel Spreadsheet, and PDF. 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.

For example:

If there are three folders within the Price List Folder. One is dated two months ago, and one is dated for one month in the future. The one dated two months ago says [ACTIVE] in front of the file name.
The file dated two months ago is the one currently in use with our partners. For current questions and quoting purposes, this is the file that should be used.

The file dated one month in the future is the file that should be provided to partners (especially distributors) to set up their systems. It will go into effect on the date in the file name.

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

Alliances and OEMs

Alliances Salesforce Dashboard

Internal Only Alliance Handbook

For any questions regarding our Alliance partners, please reach out to the #alliances Slack channel.

Opportunity Tagging for Google Cloud and Amazon Web Services Deals

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

If Google or AWS has brought us a lead/referred us a deal but will not be transacting on their Marketplace, then the following fields should be filled out on the Opportunity:

If Google or AWS has assisted on a deal and helped drive the customer to buy GitLab, but was not the original source of the opportunity, then the following fields 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 provided, it will be routed internally for approval. For more information, visit the Private Alliance Handbook.

IBM Partner Requests & QTC Process

  1. IBM Partner Requests: Visit the Private Alliance Handbook for further information on partner requests.

  2. IBM QTC Process: Once informed by IBM of a potential opportunity:

    • Sales creates an opportunity in SFDC per standard process under the customer account
    • Sales adds “(IBM OEM)” to the opportunity name and includes IBM in the Partner Section of the opportunity
    • Alliance Ops adds the contact information on the opportunity, creates the quote and attaches proper documentation
    • Alliance Ops chatters Sales-Support with documentation links
    • Deal Desk validates the details and process for closing

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.

As a reminder, comp neutrality only applies to comp and does not retire quota. For additional information, please review Channel Neutral Compensation within the Sales Ops commission section of the Handbook.

Internal: Partner Program Discount Matrix

For Partner Program discounts for PubSec, please reach out to #channel-ops on Slack.

Comp Neutral Calculation in SFDC

In the event the opportunity is going thru a Partner and therefore qualifies for CN, then the appropriate partner information must be filled out on the Opportunity and Quote in order for the CN field to calculate properly.

Required Partner Fields on the Opp:

Required Partner Info on the Quote

Example Calculation No. 1:

Partner Track               : Select
Product                     : Standard (Previously Premium)
QTY                         : 25
Term                        : 1 year
Partner Deal Type           : Resale
Partner Engagement          : Partner Sourced
Deal Registration           : Approved
Partner Program Discount    : 15%

Example Calculation No. 2 (PubSec):

Partner Track               : Open
Distributor                 : True
Product                     : Ultimate
QTY                         : 50
Term                        : 1 year
Partner Deal Type           : Resale
Partner Engagement          : Assist
Deal Registration           : Approved
Partner Program Discount    : 10%

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 DR - 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