To be a team of subject matter experts that support the key needs of the partner business both internally and externally with a focus on overall partner experience. To continue to drive initiatives that allow for growth and scale and aligns with the future vision of the business.
Key Tenets
The #partner-programs-ops Slack channel can be leveraged for inquiries. Both the Partner 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 Partner Operations Issue Board for operational issues, or the Channel Team’s Issue Board for program issues.
On the Partner Operations Issue Board, each column represents a type of request (feature request, alliances, data & reporting, etc.). When you submit a request to the Partner Operations board, the team will assign the issue and add the corresponding tags. The Partner 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 Partner 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 Partner Operations team has created issue templates.
How to get started
1. Create New Issue
When you create a new issue, you get the option to "Choose a template"
2. Choose a template
Once a template has been selected, the description box will be populated with the content of the template ready for completion.
- Select Ad hoc Reporting for custom reporting requests.
- Select Data Upload Request for bulk updates to data.
- Select Feature Request for requesting enhancements to current systems.
- Select Partner M&A and Name Changes when requesting a partner account change related to mergers and acquisitions, merging duplicate accounts or moving them into an account hierarchy, or to change a partner account name.
- Select Procedures & HB Updates to request edits or reviews for certain procedures/processes or handbook updates managed by Partner Operations, esepcially if more discussion is needed prior to submitting a MR for a page.
3. Before you submit
Please ensure you have followed the prompts to fill in the selected issue template and that your issue is unassigned. Our team will be assigning issues based on team bandwidth.
Issue Templates Video
There are a number of different slack channels to serve the different needs of the organization. Below is a list of the most common channels, as well as their uses, intended audience, and posting permissions. Please refer to this list often to ensure you’re posting information and asking questions to the appropriate channel.
| Slack Channel | Description | Topic | Audience | Posting Permissions |
|---|---|---|---|---|
| partner-fyi | Updates to the Channel & Sales teams on Channel program, operations, enablement and marketing. Questions from team members should be posted on the #partner-programs-ops or #channel-sales | blank | any | Channel Operations, Channel Programs, Nima Badiey |
| partner-program-ops | Questions and comments about channel programs and operations | 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 | any | any | |
| channels-emea | A channel for the EMEA channels team and stakeholders to collaborate | any | any | |
| channels-amer | A channel for the AMER channels team and stakeholders can collaborate | any | any | |
| pub-sec-channels | A channel for the Pubsec channels team and stakeholders to collaborate | any | any | |
| apac_partners | A channel for the APAC channels team and stakeholders can collaborate | any | any | |
| channel-services | Questions and comments about channel services program, enablement and field engagement | any | any | |
| alliances | A channel for collaboration with the alliances Team | https://about.gitlab.com/handbook/alliances/ | any | any |
| alliance_sales_ops | Questions and comments about alliance operations | https://about.gitlab.com/handbook/alliances/ and https://about.gitlab.com/handbook/sales/field-operations/channel-operations/ | any | any |
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.
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:
An approved Partner Sourced Deal Registration results in Sales Qualified Source = Partner Generated on the opportunity.
For more information: Deal Registration Program Overview.
Billing Account and billing account Contact records must be created when onboarding a new partner that will be purchasing directly from GitLab. The Channel Manager should take the following action upon being notified of a new partner:
@Billing Ops on the Partner Account with the partners accounts payable contact information to request that they create a Billing AccountPartner accounts that will transact via distribution do not need a Billing Account or billing account Contact.
More information on billing accounts can be found on the Billing Operations Handbook Page.
The Invoice Owner and Invoice Owner Contact on a partner quote represent the partner’s Billing Account and billing account Contact records, respectively.
Distributors - GitLab sellers can access the Billing Account and billing account Contact records for our distributors here.
Note, partners that transact via distribution do not need billing records, as the distributor information will be used on the quote.
Resellers and MSPs - To find Billing Account and billing account Contact records in SFDC for partners that transact directly with GitLab, first navigate to the Partner Account record.
Sold To Work Email (i.e., their Accounts Payable email address). Search for this email in SFDC to determine if a contact record already exists under the Partner Account record
When a deal is being transacted via a Partner, and a discount other than the defined Program discount is being offered, a GitLab quote is required. At a minimum, a Draft Proposal needs to be created and provided to the Partner. Discounted quotes not in SFDC and sent to a Partner are not permitted within any GEO or Sales Segment. This includes providing product and discounted pricing quote details in an email.
Sales Reps and/or Renewal Managers are responsible for quoting and PO remittance on all standard GitLab direct and partner opportunities.
Creating a partner quote is very similar to the process of creating a direct customer quote. There are only a few minor differences when quoting via partners, which are documented in the following Deal Desk handbook sections:
Refer to the Quote Studio Highspot page for quoting walkthroughs, including the following step-by-step guides specific to partner deals:
Refer to the partner billing information section of this handbook for guidance on how to create or find partner billing records in SFDC and then use them for quoting.
GitLab is building out a global Authorized Distributor network similar to many other tier-one software companies. Distributors bring GitLab, our partners, and our customers several valuable offerings:
For Commercial Markets:
gitlab@amazic.combilly.tjong@techdata.com
gitlab@redington.co.ingitlab-info@networld.co.jpgitlab@got.co.thGitLab sellers can also refer to the partner billing section of this handbook for a link to our distributor billing records and guidance on how these records are used in the quoting process.
For US PubSec:
gitlab@carahsoft.comDistributors work directly with GitLab Sellers on the quoting and ordering process. GitLab Sellers can leverage the partner quoting resources, distributor contact information, and GitLab Sales FAQ - Selling with Partners to aid in the quote and order process.
If a reseller requests a quote directly from a distributor via the aliases above, any non-PubSec distributors may contact partnersupport@gitlab.com to request an official quote. Partner Support will forward the request to the GitLab Sales Rep that owns the customer account/opportunity for Sales to work the opportunity with the distributor, including creating and providing the quote.
If a GitLab Sales Rep is working directly with a reseller and needs to quote that reseller via a distributor (e.g., they are an Open partner), Sales can leverage the resources linked in this section above to create the quote and send to distribution.
Important to note for GitLab Sellers:
GitLab is activating Distributor e-Marketplaces for customers to transact via GitLab authorized resellers. There are specific requirements for partners prior to activating their e-Marketplace capability, including:
GitLab reserves the right to pause or deactivate a partner’s e-Marketplace offering if issues arise. For more information about Distributor e-Marketplaces, partners should contact their distributor, or their GitLab Channel Manager.
Partners and GitLab Sellers frequently ask questions on how to collaborate with one another throughout the GitLab sales process. Refer to the following resources which document these FAQs and answers from both a Partner and GitLab Seller perspective:
The process to request the legal team’s involvement in partner contracts can be found on the legal team’s handbook page. Please note that the process for getting partner contracts signed is different from the process for any other legal request.
Partner Sourced Deal Reg = True and no opportunity exists, then Initial Source = PQL and SQS = Partner GeneratedInitial Source = PQL then
SQS = Partner GeneratedInitial Source = PQL.Initial Source = Partner Qualified Lead or Sales Qualified Source = Partner Generated, then the deal is Partner Sourced.
*Please visit the Marketing Handbook Page for Intial Source definition and context.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.
All Channel deals are considered Partner Co-Sell opportunities unless there is an approved Partner Sourced Deal Registration or the Opportunities Sales Qualified Source = Partner Generated. These opportunities are not sourced solely by a partner, but highlight the relationship between GitLab and partners in the selling process. Partner Co-Sell deals do not require the partner to submit a deal registration, and should be processed according to standard Partner Co-Sell discounts as identified in the GitLab Partner Program.
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.
All submissions will be recorded and tracked for audit purposes. The chosen preferred partner should match the Resale Partner on the quote with the Partner Co-Sell discount.
Any other partner receiving a quote for the same opportunity will be provided MSRP.
Further enablement for GitLab Team Members is available. For further information, contact the #partner-programs-ops slack channel.
The following are explicit guidelines for approved US Public Sector Partners to receive preferred pricing on Gitlab-sourced opportunities.
Partner Requirements:
The Partner Sourced Deal Registration program rewards partners for bringing net-new business to GitLab. There are three types of Partner Sourced Deal Registrations within the GitLab Partner Program:
Refer to the following sections for step-by-step instructions on how to process each registration type: Resale, MSP, and Referral.
GitLab’s Partner Managers, Sales Reps, and Area Sales Managers collaborate to review and action Partner Sourced Deal Registration submissions. Refer to the Partner Sourced Deal Registration: How it Works section for details on the review and approval process.
The SLA for GitLab to communicate with partners on a Partner Sourced Deal Registration is two business days. There must be contact with the registering partner within two business days, whether it be initial outreach to discuss the registration, a request for more information, approval, or rejection.
There can only be one Partner Sourced Deal Registration approved for an opportunity, as only one partner can source a deal. As a reminder, Partner Sourced Deal Registrations are opportunity-based and partners cannot register an account.
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 the administrative process for Deal Registration.
Partner**
The partner submits a Partner Sourced Deal Registration and then the following occurs:
Managed Services Team
The Managed Services team reviews the registration after it is submitted by the partner (DR-Status = “Submitted”). If there is:
The Partner Manager on the registration is automatically assigned as the Account Owner of the Partner Account in SFDC. GitLab’s Managed Services team will reassign the registration to the correct Partner Manager as part of their review in cases where adjustment is required to align the appropriate Partner Manager based on customer account territory or ownership. The Managed Services team has a 2 hour SLA to action registrations within their working hours of 8am to 6pm ET, Monday through Friday.
GitLab Partner Manager
The Partner Manager receives an email notification to review the Partner Sourced Deal Registration once the Managed Services Team has actioned the registration and submitted it for approval (DR-Status = “Pending Sales Review”). Partner Managers can also view registrations in their list view within the SFDC Registration tab. The Partner Manager is responsible for reviewing the registration and communicating with the applicable GitLab Sales Rep during this process. The Partner Manager must either approve, reject, or return the registration for additional information after completing their review. If they approve, it will automatically be sent to the appropriate ASM for final review.
GitLab Area Sales Manager (ASM)
The GitLab ASM for the opportunity is responsible for final review of any Partner Sourced Deal Registration approved by a Partner Manager, and must either approve, reject, or return the registration for additional information. The ASM receives an email notification to review the registration only if/when the Partner Manager approves (DR-Status = “Pending ASM Review”). ASMs can also view registrations in their list view within the SFDC Registration tab.
**Alliance and GSI Partners
Alliance marketplace and OEM partners, and GSI partners do source opportunities for GitLab; however, they do not submit their own Partner Sourced Deal Registrations for these opportunities. The Registration process for these partners is instead initiated by the GitLab Partner Manager on behalf of the partner.
The steps below outline how a Partner Sourced Deal Registration is submitted on behalf of an alliance or GSI partner to initiate the Deal Registration process:
Note, Partner Sourced Deal Registration incentives do not apply to alliance partners, as our alliance partner agreements supersede these programmatic incentives.
Extend DR 30 Days button on the Registration. For non-standard extensions beyond 30 days, please chatter @Partner Operations on the registration record and provide the new date that the registration should expire.DR - Deal ID) can be used to track all Deal Registrations in the system.Partner Sourced Deal Registrations for resale opportunities reward partners for bringing net-new business to GitLab. An approved Partner Sourced Deal Registration generally provides the partner a deeper discount than the Co-Sell rate, as outlined in the GitLab Partner Program.
Follow the steps below to process a Partner Sourced Deal Registration for a resale opportunity:
Deal Registration Type is ”Resale” and that the partner provided sufficient detail to proceed with the registration. If registration details are:
@Partner Operationswith the information request and we will return the registration to the partner for review and update.Link/Create Opportunity.
Link & Make Primary next to the opportunity name. You will then be brought back to the deal registration record.Link next to the opportunity name. You will then be brought back to the deal registration record.Create New, then choose “Standard” as the Opportunity Record Type. Click “Save” on the opportunity and you will be brought back to the “Link/Create Opportunity” page. Click Link & Make Primary and you will be brought back to the deal registration record.
Approve / Reject. Note, if you are rejecting but want to add a rejection reason and/or comment for the partner prior to doing so, please chatter @Partner Operationswith this information. We will make the necessary updates to the registration and then reject it on your behalf.
Approve or Reject.
Opportunity Owner to the Sales Rep who owns the customer account using the Change Opportunity Owner button on the opportunity.
Approve / Reject.
Approve or Reject.
The deal registration form is not a quoting tool and will not have all the information needed to create a quote. The GitLab Sales Rep must connect with the partner to request any necessary information prior to creating a quote.
Partner Sourced Deal Registrations for MSP opportunities reward partners for managing products and services for their end customers. An approved Partner Sourced Deal Registration generally provides the partner a deeper discount than the Co-Sell rate, as outlined in the GitLab Partner Program.
A Managed Service Provider (MSP) purchases licenses on behalf of an end user. The MSP will be the owner and manager of the licenses but their customer, the end user, is the one using the licenses. This creates specific needs in GitLab Salesforce opportunities to ensure proper reporting and compensation. Please note that the steps for an MSP opportunity differ from the steps for a resale opportunity.
Follow the steps below to process a Partner Sourced Deal Registration for an MSP opportunity:
Deal Registration Type is "MSP" and that the partner provided sufficient detail to proceed with the registration. If registration details are:
@Partner Operationswith the information request and we will return the registration to the partner for review and update.Link/Create Opportunity.
Link & Make Primary next to the opportunity name. You will then be brought back to the deal registration record.Link next to the opportunity name. You will then be brought back to the deal registration record.Create New, then choose “Standard” as the Opportunity Record Type. Click “Save” on the opportunity and you will be brought back to the “Link/Create Opportunity” page. Click Link & Make Primary and you will be brought back to the deal registration record.
Approve / Reject. Note, if you are rejecting but want to add a rejection reason and/or comment for the partner prior to doing so, please chatter @Partner Operationswith this information. We will make the necessary updates to the registration and then reject it on your behalf.
Approve or Reject.
Account Name field on the opportunity to the partner account. This should not be the MSP End User (i.e., customer) account.Opportunity Owner on the opportunity to the Sales Rep who owns the MSP End User (i.e., customer) account using the Change Opportunity Owner button.
Approve / Reject.
Approve or Reject.
The deal registration form is not a quoting tool and will not have all the information needed to create a quote. The GitLab Sales Rep must connect with the partner to request any necessary information prior to creating a quote.
Partner Sourced Deal Registrations for referral opportunities reward partners for bringing net-new business to GitLab, even if that partner does not transact the deal. An approved Partner Sourced Deal Registration for a referral opportunity provides the partner a back-end rebate upon GitLab successfully closing the deal as won (processed quarterly), as outlined in the GitLab Partner Program.
Follow the steps below to process a Partner Sourced Deal Registration for a Referral opportunity:
Deal Registration Type is ”Referral” and that the partner provided sufficient detail to proceed with the registration. If registration details are:
@Partner Operationswith the information request and we will return the registration to the partner for review and update.Link/Create Opportunity.
Link & Make Primary next to the opportunity name. You will then be brought back to the deal registration record.Link next to the opportunity name. You will then be brought back to the deal registration record.Create New, then choose “Standard” as the Opportunity Record Type. Click “Save” on the opportunity and you will be brought back to the “Link/Create Opportunity” page. Click Link & Make Primary and you will be brought back to the deal registration record.
Approve / Reject. Note, if you are rejecting but want to add a rejection reason and/or comment for the partner prior to doing so, please chatter @Partner Operationswith this information. We will make the necessary updates to the registration and then reject it on your behalf.
Approve or Reject.
Opportunity Owner to the Sales Rep who owns the customer account using the Change Opportunity Owner button on the opportunity.
Approve / Reject.
Approve or Reject.
The deal registration form is not a quoting tool and will not have all the information needed to create a quote. The GitLab Sales Rep must connect with the partner to request any necessary information prior to creating a quote.
GitLab incentivizes partners that sell their own professional services into a customer environment at the time of a GitLab product sale. An approved Service Attached Registration makes the partner eligible for a back-end rebate (processed quarterly) once (i) GitLab successfully closes the related software deal as won and (ii) the partner completes their services and provides Proof of Execution, as outlined in the GitLab Partner Program. This is separate from the Partner Sourced Deal Registration for the license sale.
To track the Partner Services, the partner must register the deal on the Partner Portal.
Follow the steps below to process a Service Attached Registration for an applicable GitLab software sale opportunity:
Program Name is “Service Attached Registration”, Services Attach Type is populated with the relevant service, and that the partner provided sufficient detail to proceed with the registration. If registration details are accurate and complete, proceed to the next step. If registration details are inaccurate and/or incomplete, chatter @Partner Operationswith the information request and we will return the registration to the partner for review and update. Important to note:
Link/Create Opportunity.
Link next to the opportunity name. You will then be brought back to the deal registration record.Back button and refer to Step 2 above for next steps.Back button and proceed to the next step.
Approve / Reject. Note, if you are rejecting but want to add a rejection reason and/or comment for the partner prior to doing so, please chatter @Partner Operationswith this information. We will make the necessary updates to the registration and then reject it on your behalf.
Approve or Reject.
Approve / Reject.
Approve or Reject.
partnersupport@gitlab.com which can include customer signed statement of work (SOW) or other customer-verified POE.DR - Deal ID is listed on the POE, upload it to the opportunity, and chatter the Partner Manager. The Partner Operations team will then update the Service Attached Registration Status to Closed-Won.Rebate payouts will be reported and paid after each GitLab quarter close.
For more information on quoting or the Partner Program, please visit:
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.
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. Upon submitting, the letter of authorization will be automatically sent to the legal team who will approve and initial the letter before sending it to GitLab's PAO for signature. Once signed, the letter of authorization will be sent directly to the partner via email. The letter is good for one calendar year from the date on the letter.
Please see the Partner Support page.
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.
Here is a general list of items you can chatter @Partner Operations for assistance with in Salesforce. Please continue to refer to our respective handbooks for in-depth information before tagging.
Most internal Salesforce (SFDC) and Vartopia system questions and changes, including:
Most partner-facing questions and changes to the Impartner (Partner Portal) system, including:
The following price files are provided by Partner Ops in Google Sheet, Excel, and PDF format:
Distributor and Reseller partners can access the Partner Portal for the current GitLab Price File. If you have any issues accessing the Partner Portal, please contact the Partner Operations team at partnersupport@gmail.com.
Price Files can be found in this folder.
Only Channel Managers should be sharing Channel Price Files.
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 download a copy and email to a partner. No partners should be given access to this folder.
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 #partner-programs-ops Slack channel.
At the beginning of the second month of every quarter, Partner Operations will create an issue and reach out to product and professional services (PS) departments to collect information on any new changes, additions, or discontinuations of part numbers. It is the responsibility of the product/PS departments to provide any and all information about SKUs that will be active on the first date of the next quarter.
Once the price book is updated, Partner Operations will tag the product and professional services team to check to make sure the information is up-to-date before publishing. The due date for this approval is five (5) business days before the end of the second month of a given quarter.*
The following departments/people will be tagged for gathering this information:
The following departments/people will be tagged for FYI/Additional Input:
After all product approvals are complete, Partner Operations will request approval in the same issue from the following Channel Teams/Individuals:
Please reach out to the #partner-programs-ops Slack channel for assistance.
*Exceptions can be made for updates to core GitLab products (Ultimate and Premium)
Partner Operations will post a message on the slack channel #partner-fyi to share the updated Price Files and call out any major changes.
Updated Price Files will be uploaded to the Partner Portal approximately 30 days before the upcoming fiscal quarter.
Partner Operations will share a copy of the pricelists to the main contacts of each distributor and work with the distributor to ensure any applicable contract vehicles are updated (e.g., Public Sector contracts).
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.
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:
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
Feedback: You can submit your feedback on the second tab of the Business Plan Sheet
The following partner forecast dashboards have been published for FY24. Please use the dashboard relevant to your partner type and region or segment. You will only have access to view data from your region based on salesforce permissions.
Here is a guide on how to log in and navigate the module.
Below are descritpions of the different columns in the Channel Forecasting module in Clari. You will also find an equivalent Salesforce filter provided.
| Column | Description | SFDC Filters |
|---|---|---|
| Partner Sourced Plan | Your Partner Sourced target | |
| Partner Sourced Net Won | Closed Won and Closed Lost Renewal opps (Churn included) | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND (Stage = Closed Won OR (Stage = 8-Closed Lost AND Type = Renewal)) |
| Partner Sourced Actual Churn | Closed Lost Renewals opps | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND Forecast Category <> Decommission, Decommissioned AND ((Stage = 8-Closed Lost AND Type = Renewal) OR (Stage = Closed Won AND Net ARR < 0)) |
| Partner Sourced Net Commit | Rep’s call, based on Commit SFDC Opps | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND (Forecast Category = Commit, Closed OR (Stage = 8-Closed Lost AND Type = Renewal)) |
| Partner Sourced Net Most Likely | Rep’s call, based on Net Most Likely SFDC Opps | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND ((Stamped Opp Owner User Segment = Mid-Market,SMB AND Forecast Category = Commit, Best Case, Closed) OR (Stamped Opp Owner User Segment = Large, PubSec AND Net Most Likely = TRUE) OR (Stage = 8-Closed Lost AND Type = Renewal)) |
| Partner Sourced Net Best Case | Rep’s call, based on Best Case SFDC Opps | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND (Forecast Category = Commit, Best Case, Closed OR ((Stage = 8-Closed Lost) AND (Type = Renewal)) |
| Partner Sourced Forecasted Churn | Rep’s call, based on SFDC Renewal Forecast Health | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND Type = Renewal AND Forecast Category <> Decommission, Decommissioned AND Renewal Forecast Category = Red |
| Partner Sourced Pipeline | Open Partner Sourced Opps | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND Stage <> 0-Pending Acceptance, Closed Won, 8-Closed Lost, 9-Unqualified, 10-Duplicate |
| Partner Sourced New Logo Plan | Your Partner Sourced New Logo target count | |
| Partner Sourced New Logo Net Won | Closed Won New Logo opp count | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND Order Type = 1. New - First Order AND (Stage = Closed Won OR (Stage = 8-Closed Lost AND Type = Renewal)) |
| Partner Sourced New Logo Forecast | Rep’s call, based on Sourced New Logo | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND Order Type = 1. New - First Order AND Stage <> 0-Pending Acceptance, Closed Won, 8-Closed Lost, 9-Unqualified, 10-Duplicate |
| Partner Sourced New Logo Net ARR Forecast | forecasted Net ARR of Sourced New Logo Opps to close in Q | Deal Path = Partner AND Sales Qualified Source = Partner Generated AND Order Type = 1. New - First Order AND Stage <> 0-Pending Acceptance, Closed Won, 8-Closed Lost, 9-Unqualified, 10-Duplicate |
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.
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:
Carahsoft’s DSOR (Distributor Seller of Record) Program is a partner program designed to provide ISV clients a 2-Tier channel enablement in expanding their business growth through the AWS Marketplace. Under the program, Carahsoft would list GitLab's products on AWS Marketplace and drive the private offer selling motion. Carahsoft develops the selling opportunity and authorizes the Consulting Partner within the AWS Marketplace to release a private offer to the customer.
For deals transacting through the Carahsoft DSOR program, the quote should reflect a normal two-tier channel transaction where the Distributor = "Carahsoft Technology Corporation" and Resale Partner = the reseller working the opportunity. For more information/instructions on quoting two-tier distribution deals, please refer to this Deal Desk handbook section.
To recognize and properly compensate these transactions, please ensure the CPPO or DSOR Partner field = "Amazon Web Services" on the opportunity record. Please chatter Chris Novello or Pilar Meija on your DSOR opportunity so they can review the opportunity and update the CPPO or DSOR Partner field.
Deals booked through the Amazon and Google markeplaces use the fee schedules as shown in the Deal Approval Matrix.
Required fields when requesting Google Cloud Credits on an Opportunity
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
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:
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.
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.