This page documents the operational information and processes for managing the Channel Program Operations. This page does not include transactional processes, which are available on the Channel Operations Handbook page.
Partners register to join the GitLab Partner Program by registering at partners.gitlab.com. You can find more details about the registration process on the Channel Operations Handbook page. As part of that process, partners are able to review and approve the GitLab partner program agreement. For partners that do not agree to all the terms of the agreement, the Legal Request process is available to negotiate contact terms.
The following are the available partner agreements and addenda:
Copies of the contract templates can be found here.
Partner agreements are limited to a single region (Americas, EMEA, APAC, Public Sector), unless otherwise approved by Channel leadership.
Members of the Channel team are granted access to the Partner Portal Admin Console. This console enables team members to track partner engagement and view partner data. Partner data is synched between the Partner Portal and Salesforce, so GitLab team members that have access to Salesforce can find all the partner data there.
The Admin console capabilities include:
Where do partners and CAMs submit questions?
The Partner Help Desk team has compiled a list of issues and solutions to the most common Partner Portal, application and data questions into an FAQ doc. Please start here to address any issues. This document also includes some of the PHD current state internal processes.
Step 1: Introduce your partners to the GitLab Service Partner Program
Step 2: Set an enablement plan with the partner representative that identifies their key employees who sign up for training and become certified to meet the competency requirements for the program.
Step 3: Build a business plan to incorporate GitLab as a strategic element in their service practice using our Service Development Framework
Step 4: CAMs and the PHD award partners their certifications using GitLab Issues.
Channel partners who are compliant with the Channel program are eligible to achieve a GitLab Professional Services Partner (PSP) badge.
The requirements for the GitLab Professional Service Partner badge can be found on the Channel Services Handbook Page.
Practitioners will be granted badges per the Practitioner Badging Process. Badges will be issued as each practitioner completes the required training and certification exam associated accreditations and certifications through an automation between the GitLab Learn system and Credly that is managed by GitLab Education Services team.
When a partner reaches the required number of GitLab Professional Services Engineers, the GitLab Channel Programs Team will open an issue in the Channels project using the
Partner_Certification_Award issue template and assign the CAM responsible for the account to that issue. The CAM and the Partner Help Desk each have tasks to complete in the issue. Instructions and templates are linked in the issue to make it easy for each team member to carry out the tasks.
Within 7 calendar days of assignment the CAM will:
The GitLab Education Services Manager team will open an issue in the Channels project using the
Partner_Certification_Award issue template and assign themeselves to that issue. The Education Services Manager and the Partner Help Desk (PHD) each have tasks to complete in the issue. Instructions and templates are linked in the issue to make it easy for each team member to carry out the tasks.
Within 7 calendar days of assignment the GitLab Education Services Manager will:
General NFR Request Process
Partner fills out the NFR License Request form from the "Support" tab within the partner portal.
This creates a new line in the associated spreadsheet.
Notification is sent from the spreadsheet to anyone who has notifications set up (see Set Up Google Form Spreadsheet Notifications [insert link to heading]).
Partner Help Desk (PHD) reviews request to verify:
If the partner has no certifications yet, but meets the other two eligibility criteria above, currently we can still send the NFR license, but we should encourage the partner to complete the Solution Architect Core. See sample email to Partner contact and CAM, once the license has been sent, below:
Subject Line: NFR License Request
Hi [Partner License Contact],
_We just sent you an email with your NFR license, please let us know if you did not receive it. _
_To ensure you receive the most value from this license, we encourage you or someone in your organization to complete the available parts of the Solution Architect Core certification in the Partner Portal. _
Please let us know if you need anything else.
PHD works with partner if additional information is needed.
If verified, PHD follows the **Creating and Sending NFR Licenses [insert link to heading] **process (i.e. goes to license.gitlab.com and creates new license according to the request submitted in the form).
When submitted, an email with the license is auto-generated to the Contact Email provided and is auto-logged under the Contact Name in Salesforce.
PHD informs requestor license has been sent.
Creating and Sending NFR Licenses
Access Request to Generate NFR Licenses
In order to send NFR licenses to partners, you first need to have access to dev.gitlab.org. This access then allows you access to license.gitlab.com, where we issue NFR licenses from.
Access Request for dev.gitlab.org
Once access is granted, you will get an email from dev.gitlab.org “Account was created for you”, make sure you open the email and click the link to set your password.
Logging in to license.gitlab.com
Once your password is set at dev.gitlab.org, go to license.gitlab.com. A login screen will appear, click the green button on the left, “Login with Gitlab” and use your email and the password you just created for dev.gitlab.org.
Set Up Google Form Spreadsheet Notifications
Access the NFR License Request Form Google Sheet and set notifications following the instructions below.
You can only set up notifications for yourself. You won’t get notifications when you make changes on your spreadsheet, but you’ll get notifications when others make changes.
Open the form as a spreadsheet in Google Sheets (click the Responses tab on the form and right below that in the top right corner, click the Sheets icon “View responses in Sheets”).
At the top of the spreadsheet, click Tools and then Notification rules.
In the window that appears, select when you want to receive notifications.
Notify you when:
In the window that appears, select how often you want to receive notifications.
Notify you with:
Complete process for submitting an MDF proposal request for funds and detailed instructions regarding the approval and claim process can be found in the Channel Partner Handbook under MDF.
Select Partners are able to submit MDF requests via the Marketing Page in the Partner Portal. Partners should be reviewing plans with you prior to submitting an MDF request in the Portal to ensure you are aligned with the proposal.
Partner Logos may be accessed in GitLab Partner Portal in the Asset Library under Marketing. Logos are segmented so only authorized Select Partners have access to the Select Logo.
When initiating a project the Channel Team needs to be engaged in each part of the project from ideation to approval. The Channel Engagement process is depicted in Diagram 1 below:
Once approved we are ready to begin with engagement with Partner Marketing, Partner Enablement, and the Partner Communication process.
Table 1 outlines the DRIs responsible for each step in the Channel Program Engagement process.
|Channel Programs||Ed Cepulis|
|Channel SA||Adrian Waters|
|Channel Operations||Colleen Farris|
|Channel Marketing||Coleen Greco|
|Partner Enablement||Blair Fraser|
|Partner Communications||Kim Jaeger|
The Channel Programs and Enablement team is responsible for the maintence and management of enablement tools used to support the GitLab Partner ecosystem. The three main tools that we use are: Highspot, ImParnter(Partner Portal), and EdCast. Please reference the chart below to determine where an enablement asset should reside.
The Channel Programs and Enablement team is responsible for “To Partner” Communications.
Partners are a huge part of the GitLab go-to-market strategy. Teams managing our product, pricing, or process changes should always consider our Partners as it puts them in the best position to be successful with GitLab customers.
GitLab is contractually obligated to provide Partners with 30 days notification of any pricing, product, or program changes. Product changes to tiering, terms, or EOA must accommodate the 30-day notice before announcing to GitLab customers, so Partners are prepared for changes and to help address customer questions/concerns. The 30 day notification period allows Partners to make required changes to pricelists, company websites, and collateral. As you create GTM and communication plans, please add extra time for the request to the Channel Program team and account for the required 30-day notification.
If you have something to be communicated to our Partners, kindly submit a Channel Partner Announcement request using this template.
For all materials requiring legal review, please refer to the Materials Legal Review Process
The Channel Program team has a standard communication cadence and vehicles to deliver notifications to Partners. Please take into account the communication cadence and delivery dates below, we appreciate and encourage as much notification as possible to allow the team to prepare and schedule requests properly.
News on Demand - Channel Partner communication platform! News on Demand is an add-on product to Impartner, which hosts the Partner Portal.
NOD is used to communicate to Partners via targeted emails and the Partner Flash Newsletter. With NOD, we are able to deliver news that is relevant to the individual user. Partners can access news archives and as a contributor, you can add articles at any time. You do not have to stress about deadlines!
Partner Flash is 100% Targeted - using groups, we can target the audience of each communication or email.
Partner Flash is 100% Personalized- Partners can choose topic preferences and delivery cadence. They can opt to receive the newsletter Daily, Weekly, Bi-Weekly or Monthly. Partners can also access Partner Flash via the “My News” tab in the Partner Portal.
Everyone can Contribute! - Anyone at GitLab can create a story or article for the newsletter! If you would like to be a contributor, click here to fill out the request form. Once approved, navigate to the NOD Home Page to access training and helpful tips.
Partner communication resources and standard delivery dates.
How to get a hold of us: If you have completed the engagement process approvals or have any questions regarding if/how something should be communicated, please reach out to us via the #partner-programs-ops Slack channel.
Partner Flash access - anyone at GitLab can receive Partner Flash or contribute an article.
Partners - automatically signed up when approved and authorized via the Partner Portal. If a Partner believes they do not have access please provide the user detail: first and last name, email address, and company name in the** #partner-programs-ops** Slack channel, and we will investigate. Typically we find the Partner has inadvertently opted out of communications. \
Partner Flash is a monthly newsletter that recaps important Partner-related information from the month and highlights important upcoming information. The main goal of this communication is to help Partners ramp quickly and grow their GitLab business.
The newsletter is sent to authorized users in our Partner community, the list is gathered and updated from the Partner Portal, new users are added automaticly.
The newsletter will…
Uphold our valuesof transparency and allow anyone to contribute**
Prioritize repetition, brevity, user-friendliness and added value
Be fun to look at and read
Help the Channel operationalize key messages
Be an opportunity for the Partner Community to "learn themselves"
Highlight all aspects that make a big win possible
Keep the onus on individuals to stay informed
Be general enough to allow us to remain segment-agnostic
Uphold our value of "everyone can contribute" we will measure success and gather Partner feedback often.
Partner Flash - Sections, descriptions, and News Type
Top News - Important announcements (Program Changes) or reminders (Example: Register for Partner Summit or SKO) we should have only ONE item in this category. _News type: Programs, Product, Marketing, Certifications _
New and noteworthy resources - Secondary announcements - services program, new training, significant Partner resources
News Type: Programs, Product Updates
Did You Know? - GitLab highlights or awards (Gartner Report) Product _updates or use cases
News Type: _Corporate & Industry news
Tech Talk - Technical content
News Type: technical, product
Enablement Extras - Provides competitive info for sales or information to assist in the sales process.
_News Type: Product, Sales _
Marketing & More - Highlights from the Channel Marketing team.
News type: Marketing
What's new in GitLab? - Reviews highlights of the latest GitLab release
News Type: Product
Events & Announcements - Highlighted events or webcasts for Partners.
News Type: Events
News from our Distributors - any specific Disi notifications or events
Team Member Spotlight - Highlights a Channel Team Member
(NEW!) In Case You Missed It - Highlight an important topic from the Partner Webcast or special announcement with link to any video or recording. \ News Type: Product, Program, Technical, Sales
(NEW!) Partner Success! - Partner Services success story to include: Customer problem, Partner solution, Outcome - also to be shared in Field Flash.
News Type: Sales, technical, product
Links we love (as a footer)
GitLab Partner Handbook
The newsletter is sent out on the first Thursday of each month.
We build the newsletter using the News On Demand platform, to request to be a contributor please follow the instructions in the Partner Communications.
Quantitative Success Metrics
Qualitative Success Metrics
Groups Use the GitLab.com group for epics that may include issues within and outside the Channels Team group.
DRI To be stated in intro of issue and assigned to that person. There maybe 1 or more assignee but the DRI should be stated intro of issues