GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsGitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsThis 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 Helpdesk 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.
Step 1: Introduce your partners to the GitLab Certified 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: Include GitLab Certified Service Partner certifications in their business plan using slide 19 in the business planning template. Slide 19 is required to be filled out for all partners who are invited to become GitLab Certified Training Partners, and we suggest it for all other partners.
GitLab Certified Training Partner program is invite only until 31 January 2021.
After a partner accepts an invitiation, the CAM:
The issue is designed to:
When all sections of the issue are completed, the GitLab Education Services Delivery team member will close the issue and proceed with awarding the certification per the GitLab Service Partner Certifications Award Process.
Channel partners who are compliant with the Channel program are eligible to achieve Certified Service Partner Certifications. We have two Channel Service Partner Certifications:
The requirements for each GitLab Certified Service Partner certification can be found on the Channel Services Handbook Page.
GitLab Field Enablement Channel Program Management is responsible for granting the practitioner level badges per the Practitioner Badging Process. Badges will be issued as each practitioner completes the required training and certification exam associated with the GitLab Certified Professional Services Engineer certifications.
When a partner reaches the required number of trained practitioners, the GitLab Field Enablement Channel Program Manager 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 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 (PHD) each have tasks to complete in the issue. Instructions and templates are linked in the issue fto make it easy for each team member to carry out the tasks.
Within 7 calendar days of assignment the CAM will:
The table below describes how the GitLab Channel team will work with the GitLab Professional Services team when Channel Partners are used to deliver service engagements that were sold on GitLab paper.
RACI= Accountable, Responsible, Consult, Inform
Deliverable \ Ownership | Channel Team | Professional Services |
Onboarding process creation including how to engage with GL (contracts, accounting, collaboration/communication) | A,R | C,I |
Partner onboarding | A, R | C |
Rate cards | C | A, R |
Billing and invoice management for a specific project | I | A,R |
Coordinate delivery with a partner for a specific customer | R,A,C,I | |
MSA terms for subcontracting arrangement | R,I | A,C |
Partner SOW for project engagement | A,R | |
Subcontracting process (SOW, invoicing, etc.) | C,I | A,R |
“Bench” Relationship Management (FY22) | C,I | A,R |
Vetting process for partners | R
(prelim vetting) |
A, R |
The table below describes how the GitLab Channel team will work with the GitLab Education Services Delivery team when Channel Partners are used to deliver service engagements that were sold on GitLab paper.
RACI= Accountable, Responsible, Consult, Inform
Deliverable \ Ownership | Channel Team | Education Services |
Onboarding process creation including how to engage with GL (contracts, accounting, collaboration/communication) | R, A | C, I |
Partner onboarding: GitLab Partner Program | R, A | C |
Learning partner and/or trainer onboarding: CTP/subcontract list | I | R, A |
Rate cards (PS/EdS offerings) | C | R, A |
Course Content Price | C | R, A |
Billing and invoice management for a specific project | I | R, A |
Coordinate delivery with a partner for a specific customer | R, A, C, I | |
MSA terms for subcontracting arrangement | C, I | R, A |
Partner SOW for project engagement | A, R | |
Subcontracting process definition (SOW, invoicing, etc.) | C, I | A, R |
“Bench” Relationship Management (FY22) | C, I | R, A |
Vetting process for partners | R (prelim vetting) | A, R |
Managing monthly reporting for Channel Excellence:
Certified Subcontractor Performance ratings |
A, C | R |
Collecting Monthly Metrics | A, R | |
Managing monthly billing | I | A, R |
General NFR Request Process
Requestor (CAM/partner) fills out the NFR License Request form.
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.
Kind regards,
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
Create a Single Access Request copying the text and updating with your own information using this issue as an example.
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:
Click Save.
PHD Specialists are responsible for following the onboarding and enablement of new partners and the activities of our current Open and Select partners.
Regions assignment per PHD Specialist: AMER: Evon Collett EMEA: Camille Dios APAC: Reena Yap
Global PHD email address: partnersupport@gitlab.com
Weekly:
→ Once review is finished, update the Last PHD Review and Account Notes fields on the Partner Account in SFDC.
Monthly (Middle of the Month Friday):
Quarterly - ⅓ of Selects per month, prioritize Open with Bastian/Jordan/Reporting:
→ Once review is finished, update the Last PHD Review and Account Notes fields on the Partner Account in SFDC.
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 and Open 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.
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 or you can self serve by going to this link.
The newsletter will…
Uphold our **values of transparency**
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. **
Based on the requirements above, this is the first iteration of the newsletter format:
The newsletter is sent out on the first Thursday of each month after our Partner Webcast series has concluded. We can adjust delivery based on feedback from the field, holidays or timing of a Partner focused update (pricing).
We build the newsletter in an issue in the Partner Communication project.The process for the issue includes:
To be added to the newsletter distribution list, use this signup form. Measurement
Quantitative Success Metrics
Qualitative Success Metrics
05/07/2020 - We're Live! Our First Edition of Partner Flash.
06/04/2020 - Partner Flash Top Partner Highlights for June
07/06/2020 - GitLab Partner Flash: July Edition
08/12/2020- GitLab Partner Flash: August Edition
Additional newsletters can be found here.
Additional newsletters can be found http://eepurl.com/g8hRIT
Groups Use the GitLab.com group for epics that may include issues within and outside the Channels Team group.
Projects
Epics
Labels
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
Milestones
Due Dates What is the expected due date of completion or NBA (next best action - next key iteration and should be mentioned in the issue)?