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

Channel Programs Operations

  1. You are here:
  2. Handbook
  3. Sales
  4. Channel
  5. Channel Programs Operations

Overview

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.

Partner Contracts

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.

Partner Portal Administration

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:

  1. Engagement metrics - Partner portal engagement metrics, such as logins, asset usage, new accounts and web analytics can be found under the Channel Intel tab.
  2. Salesforce sync - Data is synchronized between the Partner Portal and Salesforce in near real time. As data is updated in one system, it is automatically syned to the other. The Salesforce team, along with Channel Ops and Programs maintain the synchronization. The CRM sync is set up under Admin Settings, CRM.
  3. Workflows - Workflows are set up to take an action based on a new partner being added to the system or updates to a partner account or user record. Workflows are found under the Setting tab. Workflows have been set up to notify team members of a new partner sign ups, automatically provide partners with Portal login credentials, assign journeys, update data fields and other activities. The Channel Programs team maintains the workflows.
  4. Training courses and exams are available for partners in the Portal. The courses are maintained by Field Enablement and Channel Programs. Once the GitLab LXP is rolled out to partners, partners will access the LXP through the portal via single sign-on.
  5. Journeys are set up to assign a partner a set of specific tasks and activities. For example, new partner users are assigned an onboarding Journey. Journeys are set up and maintained by the Channel Programs team.

Partner Support Questions

Where do partners and CAMs submit questions?

Slack Channels

Email and Chatter Aliases

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.

Partner Services Program Management

Help Your Partners Become a GitLab Certified Service Partner:

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

Note: If partners do not complete the CTP certification within 6 months of starting it, they will not be allowed to complete it.

Step 4: CAMs are required to use GitLab project features to manage their partners through the CTP certification process.

Step 5: CAMs and the PHD award partners their certifications using GitLab Issues.

Process for Enrolling Partners into the GitLab Certified Training Partner Program

In order to collaborate with partner organizations, the Channel Solutions Architect group has created a sub-group named Partners under the channels sub-group in GitLab.com where the Channel Account Managers share projects directly with our partner contacts. In order to work with a partner directly, the CAM is required to ensure there is an open sub-group for the specific partner under the Partners sub-group.

  1. Check for the partner's sub-group:
    • Navigate to the Partners sub-group.
    • Click on the sub-group for the region where the partner is located.
    • Review the list of partners in that region.
  2. If you did not see the partner in the sub-group for their region, create a sub-group named Partner Company Name with two sub-groups (collaboration and internal) under the company sub-group.
    • Please refer to the Sub-groups documentation page to learn how to create sub-groups.
    • Please refer to an existing partner company sub-group and use it to as a model for the new one that you are creating.
  3. Whether they had to create a new collaboration sub-group for the partner or there is an existing collboration sub-group for the partner, the CAM is required to add and/or verify that the partner primary contact is a member of the collaboration sub-group with maintainer permissions.


After a partner accepts an invitiation, the CAM:

  1. Will open a project in the Channel Partner's collaboration sub-group using the GitLab_Certified_Service_Partner_Program project template.
  2. Name the project "Partner Company Name CTP Requirements Project". Note: There is a bug that may accidentally put the new project in the templates folder. CAMs are required to verify that the project was created in the correct sub-group by checking the path dropdown and make changes to the path to put the project in the correct sub-group.
  3. Open an issue using the CTP_Requirement_Tracking_Issue template in that project.
    1. The template automatically engages the GitLab Channel Services team and the GitLab Education Services Delivery team
    2. The CAM is required to assign themselves and the partner primary contact to the issue.
    3. Each assigned team member is required to complete all sections assigned to the their job title within 6 mos of creating the tracking issue.

The issue is designed to:

  1. Set certification timeline goals
  2. Track completion of all program requirements for becoming a CTP, including:
    1. Program Entry requirements
    2. Identify Certified Trainer Candidates
    3. Competency requirements
    4. Compliance requirements and setting MBO goals
    5. Legal and operational requirements
  3. Facilitate internal and partner contributions to the process

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.

Enroll Certified Trainer Candidates

  1. Ask the Certified Trainer Candidates to open an issue in the CTP_Requirements_Tracking_Project using the GitLab_Certified_Trainer_Candidate_Enrollment_Issue_for_Partners Issue Template.
  2. Follow all instructions and complete all tasks in the sections assigned to the candidate in that issue.

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:

  1. GitLab Certified Professional Services Partner (PSP)
  2. GitLab Certified Training Partner (CTP)

The requirements for each GitLab Certified Service Partner certification can be found on the Channel Services Handbook Page.

GitLab Certified Professional Services Partner Award Process

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 through an automation between the GitLab Learn system and Badgr that is managed by GitLab Education Services team.

When a partner reaches the required number of GitLab Professional Services Engineers, the GitLab Channel Account 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:

  1. Send the appropriate certification award email to the main Partner contact person. The award email contains the following elements:
    1. Congratulations
    2. Access to a Badge Graphic Download
    3. Offers partners help to create a press release announcing their new certification
    4. Directs partners to our social media sharing kit to help them effectively announce their new certification per our social media kit.
  2. The Issue will also be automatically be assigned to GitLab Partner Help Desk who will:
    1. Update the partner portal account information with the new certification and include the badge on the partner locator for the account.
    2. If this is the first GitLab Certified Service Partner certification, grant the partner admin access to the GitLab Service Partner Community after the CAM has notified the partner about their new certification. This video demonstrates how.
  3. If the partner indicates they want to create a Press Release about their new Services Certification; the CAM can follow the instructions on the Channel Marketing Page to request a press release.

GitLab Certified Training Partner Award Process

The Channel Sales Manager (CSM) team will open an issue in the Channels project using the Partner_Certification_Award issue template and assign themeselves to that issue. The CSM 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 CAM will:

  1. Send the appropriate certification award email to the main partner contact person. The award email contains the following elements:
    1. Congratulations
    2. Access to a Badge Graphic Download
    3. Offers partners help to create a press release announcing their new certification
    4. Directs partners to our social media sharing kit to help them effectively announce their new certification.
  2. The Issue will also be automatically assigned to the PHD who will:
    1. Update the partner portal account information with the new certification and include the badge on the partner locator for the account.
    2. If this is the first GitLab Certified Service Partner certification, the PHD will grant the partner admin access to the GitLab Service Partner Community after the CAM has notified the partner about their new certification. This video demonstrates how.
  3. If the partner indicates they want to create a Press Release about their new Services Certification; the CAM can follow the instructions on the Channel Marketing Page to request a press release.

Channel Service Partners as Subcontractors for GitLab Professional Services

RACI-Master Services Agreement (MSA)

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

RACI-CTP

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

Internal NFR Request Processes

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:

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

  1. Once you’ve confirmed the partner is eligible to receive NFR licenses, login to license.gitlab.com
  2. Click the green button in the upper right corner “New license”
  3. Enter this info at minimum:
    • Name
    • Company
    • Email
    • Users count
    • GitLab Plan = Ultimate (default)
    • Check Trial checkbox
    • Starts at = Today’s date
    • Expires at = 1 year (unless the partner already has existing NFR licenses, then set to the expiration date of the existing license so that all licenses expire the same day and can be reviewed and renewed, if needed, at the same time)
    • Notes = [User count] [GitLab Plan] NFR Licenses for Partner: [Insert Name]
  4. Click Create License button

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.

  1. Title: First and Last Name, need access to dev.gitlab.org
  2. Type: Issue
  3. Write: (Delete everything above Person Details)
    1. Fill in _Person Details _section with your information, no SSH key needed
    2. Under Account Creation go down to the checkboxes for System name:
      1. _System name: _dev.gitlab.org
      2. _Justification for this access: _I need access to this system so that I can also login and gain access to license.gitlab.com. As a Partner Help Desk Specialist, I will be fulfilling and creating new NFR licenses for Channel Partners for their internal use/demo purposes.
    3. When is access needed? Check the box next to “Within next 72 hours” and add the corresponding label in the Labels section.
  4. Assignee: _Your Manager, _Yourself (so you can track)
  5. Labels: IT::to do, AR-Priority::3 (other labels will be auto-added)
  6. Click Submit Issue button
  7. In the Comments _section below the body of the issue, type: @gitlab-com/business-technology/team-member-enablement and then click _Comment to post.
  8. You may also want to comment to @your manager to ask them to label AR-Approval Manager Approved and ReadyForProvisioning
  9. Once approved, it should be processed by IT-OPs within the timeframe needed

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.

WW Channel Partners Maintenance Calendar for Partner Help Desk Specialists.

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.

Channel Marketing Processes

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.

Channel Program Engagement Process

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:

Diagram 1:

Channel Program Engagement Process


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.

Table 1:

Team DRI
Channel Programs Ed Cepulis
Channel SA Adrian Waters
Channel Operations Colleen Farris
Channel Marketing Coleen Greco
Partner Enablement Blair Fraser
Partner Communications Kim Jaeger

Partner Enablement Tools

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.

Partner Enablement Tools

Partner Communications

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.

Partner communication resources and standard delivery dates.

How to get a hold of us:

After you have completed the engagement process approvals, if you have any questions regarding if/how something should be communicated, please reach out to us via the #channel-programs-ops slack channel.

Partner Flash Newsletter

Overview

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.

Target Audience

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.

Opportunities/Requirements

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.

Format

Based on the requirements above, this is the first iteration of the newsletter format:

  1. Featured
    • The announcement we think is most impactful to our Partners he field. We will try to communicate this in an image with 1-2 lines of text + 1-2 links to references.
  2. Enablement Extras
    • Updates on new or updated training + opportunities to reinforce SKO learning objectives. (i.e. Did you know…?/Did you remember that…?)
    • Competitive information
    • Messages from our Leadership teams
  3. New and noteworthy resources
    • Link to that month’s Partner Webcast series
    • GitLab whitepapers, reports or studies that might help a Partner advance an opportunity through the sales cycle.
  4. Partner Deal of the month (or Deal of the Month if appropriate to share)
    • Video of sales/CS team member(s) overviewing the opportunity and/or customer and explaining how they won the deal + links to any customer-facing collateral they used (that can be publicly shared).
  5. What's new in GitLab
    • The top 3 takeaways from the latest GitLab release, mapped to one of the three value drivers and framed in the context of the customer value.

Process

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

Past Newsletters

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

Channels groups, projects, and labels

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)?

Open in Web IDE View source