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

Maintained by:

Jack Brennan

@jbrennan1

On this page

• Overview
• Partner Contracts
• Partner Portal Administration
• Partner Support Questions
• Partner Services Program Management
  • Help Your Partners Become a GitLab Certified Service Partner:
  • GitLab Service Partner Certifications Award Process
    • Certification Award Process
  • RACI-Master Services Agreement (MSA)
  • RACI-CTP
  • Internal NFR Request Processes
  • Channel Marketing Processes
  • Partner Communications
  • Partner Flash Newsletter
  • Overview
  • Target Audience
  • Opportunities/Requirements
  • Format
  • Process
  • Past Newsletters
  • Channels groups, projects, and labels

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:

• Master Partner Agreement (MPA) - This includes the primary terms and conditions for all reseller, services and referral partners.
• Reseller Addendum - The Reseller addendum covers resale and renewal terms and conditions and must be signed by all partners reselling GitLab products and services.
• Referral / Services Addendum - This addendum to the MSA defines the terms and conditions for referral and services payment to partners. All partners offering services around GitLab or partners referring, but not resellering GitLab must sign this agreement
• Managed Services Provider Agreement - This is a special agreement for any partner that will be offering GitLab managed services.
• Training Partner Addendum - All partners that will be offering GitLab training services utilizing GitLab training materials and train the training programs must sign this addendum.

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:

• #channel-sales for general sales engagement questions.
• #channel-programs for questions about the overall GitLab Partner Program,rules, governance, enablement and processes.
• #channel-ops for partner transactions from deal registration through order.
• #channel-services for questions about the partner services program and partner engagement in services opportunities.

• #resellers for partners to submit questions.

  Email aliases

• partnersupport@gitlab.com for questions about the partner portal and partner related Salesforce questions.
• partners@gitllab.com for messages to the entire channel team.

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.

Partner Services Program Management

Help Your Partners Become a GitLab Certified Service Partner:

Step 1: Introduce your partners to the GitLab Certified Service Partner

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 enablement requirements.

Step 3: Build a business plan to incorporate GitLab as a strategic element in their service practice using our Service Development Framework

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 three Channel Service Partner Certifications:

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

The table below describes the requirements for each Channel Service Partner Certification on the Channel Services Handbook Page.

Certification Award Process

GitLab Field Enablement Channel Program Management is responsible for granting the practitioner level badges when Partner employees complete the required training and certification exam to achieve the practitioner 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 Channel Account Manager responsible for the account.

Within 7 calendar days of assignment of the issue to the CAM who will:

1. Send the appropriate certification award email to the main Partner contact person.
   1. Congratulations
   2. Social Media Sharing Kit
   3. Badge Graphic Download
   4. Offer your partners help to create a press release announcing their new certification.
   5. Direct your partners to our social media sharing kit to help them effectively announce their new certification per our social media kit.
   6. Invite your partner to work with you to Start building the partners’ GitLab service practice per our service development.
2. The Issue will automatically be assigned to GitLab Partner Help Desk who will:
   1. Update the partner portal account information
3. If the partner indicates they want to create a Press Release about their new Services Certification; please follow the instructions on the Channel Marketing Page to request a press release.
4. Practitioner Badging Process - link to Training & Enablement ops
5. Impartner vs. Edcast:

RACI-Master Services Agreement (MSA)

1. Channel Partner - Delivering on GitLab paper RACI
2. Accountable, Responsible, Consult, Inform :

RACI-CTP

1. Engagement Model
   1. PS and Sales
2. Reporting?
3. Badging Process - link to Training & Enablement ops

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:

• If the partner account is Authorized in Impartner
• If there are any existing NFR licenses - check license.gitlab.com with the partner account name to see if the Partner already has any existing NFR licenses.
  • Select Partners are allowed up to 25 licenses, Open Partners up to 10 licenses
  • If existing licenses, set the expiration date to the same expiration date as existing license (unless this is a renewal of course)
• If the partner has at least one employee who has completed the Solution Architect Certification or Professional Services Engineer Certification training, lab and exam (with a passing score).
  • Check in Impartner for certifications by going to the Training tab
  • Next to the Certification: Solution Architect Core, click the number in the “Completed” column to display all certification completions and sort by account to see if a certification has been completed.
  • Next to the Certification: GitLab Trusted Professional Services Engineer (PSE) Certification, click the number in the Completed column and sort by account to see if a certification has been completed.

  • 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.

• To confirm the license has been sent, find the Contact Name in Salesforce and then view the Activity History on the contact record. The activity Subject will be Email: GitLab Ultimate Trial License Key for… with the email address and a reference number.

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-ops/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:

• Any changes are made: Send notifications when someone makes a change to a spreadsheet.
• A user submits a form: Send notifications when someone fills out a form.

In the window that appears, select how often you want to receive notifications.

Notify you with:

• Email - daily digest: Send a daily summary of all changes.
• Email - right away: Send an email for every change.

Click Save.

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

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

• The newsletter is for communication, the Handbook is for documentation. This means that the newsletter will disseminate updates but lean on the Handbook (and other relevant resources) as the main source of documentation, linking back to it wherever possible. Items will also be referenced in the GitLab Partner Portal.

Prioritize repetition, brevity, user-friendliness and added value

• The newsletter will focus on short lists and bullet points and will link out to more robust resources.
• Repetition is key to adoption. We will encourage our Channel teams to talk about Partner Flash and will remind Partners in our upcoming Partner Webcast series and on the GitLab Partner portal.
• We want Partners to value the newsletter. A key to adoption will be successfully positioning it as THE resource to learn what's new and recap important information. Everything will be tied back to the payoff to the Partner or seller when possible.
• We must reconcile the fact that this newsletter is yet another increase in communication. We will leverage it to cut down on other communications when possible.

Be fun to look at and read

• A focus on multimedia is important in order to help the newsletter break the monotony of text Partners sift through each day.
• We will use images, gifs, emojis, and video where possible. For example, instead of doing a written win-wire, we will interview the individual and embed that 30-60 second video in the newsletter.

Help the Channel operationalize key messages

• We will organize information around our 3 main value drivers when possible.
• We will frequently reiterate Sales and Channel messages through video clips and use-case examples.

Be an opportunity for the Partner Community to "learn themselves"

• A peripheral goal of the newsletter is to advertise helpful resources to the Partners. We will provide helpful information in hopes that it will encourage them to seek out the source of that information and look for additional information once there.

Highlight all aspects that make a big win possible

• There are a lot of new Partners and sales reps who are ramping up on GitLab, we want to provide easy to access to information to help them ramp quickly.
• We will include context around partners and alliances when they play a role in a deal.

Keep the onus on individuals to stay informed

• GitLab is asynchronous, this communication is in place to help provide quick access to relevant topics, the newsletter is not a substitute for the Handbook or other resources salespeople should be leveraging on the day-to-day.

Be general enough to allow us to remain segment-agnostic

• The newsletter will include general updates and resources that are applicable to most, if not all, Partners. I
• Be built out in the open
• The newsletter content will be compiled in an issue each month within the Partner Communication project. Any team member is welcome to contribute or make requests. See more information in the Process section below.

**Uphold our value of "everyone can contribute" – we will measure success and gather Partner feedback often. **

• We will measure success using a combination of quantitative and qualitative success metrics. See Measurement section below.
• Giving feedback or making requests will be easy, and all input will be considered and addressed.
• The team is committed to upholding the value of the newsletter – information should be relevant, feedback should be actioned on, and leadership should help reiterate by pointing to it as a useful resource for their teams.

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:

• The issue for each month's newsletter is opened at the beginning of each quarter.
• Relevant stakeholders/contributors are tagged in the issue each month to provide content or review suggested content in the outline.
• Once the outline is complete, the content is imported into the newsletter template in MailChimp.
• Partner Program Manager sends the newsletter test email to relevant leaders and stakeholders for review no more than two business days before planned send date.
• Reviewers provide feedback no later than 3 pm MT on the business day before the planned send date to allow time for revisions and scheduling.
• Partner Program Manager schedules the newsletter to send on the planned send date.
• Once the newsletter goes live, Partner Programs Manager sends a reminder to the field in the #sales, #customer-success and #sdr_global Slack channels
• On the Friday following the newsletter send, Partner Program Manager captures the newsletter performance data in the issue and then closes it.

To be added to the newsletter distribution list, use this signup form. Measurement

Quantitative Success Metrics

• Email open rate - Average open rate of 35% in first 6 months.
• Click rate - Average click rate of 5% in first 6 months.

Qualitative Success Metrics

• Increased engagement from our Partner community/leaders and stakeholders in regards to the newsletter – feedback, requests, suggestions, etc.
• Usefulness of newsletter content as shown by other stakeholders using newsletter content for their own work.
• Improve the Partner section of the Handbook and the Partner Portal as a result of work on the newsletter.

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.

• https://gitlab.com/groups/gitlab-com/-/boards/1508300?label_name[]=Channel
• Guidelines for Partner Folders:
  • The partners Group is further divided into regional sub-groups
  • Within each region sub-group Partners will get their own group
  • Partner groups contain a collaboration project and internal project
  • Partner employees should be explicitly invited to collaboration group
  • Internal group should not be visible to non-GitLab employees and may contain licensing details or other sensitive information
  • Additional projects may be created within the partner subgroup to contain code bases for prototypes or PoV
  • Please avoid creating additional subgroups within partner groups

Projects

• Create issues under the “Channels” project

Epics

• From FY21 Q3 - OKRs will be formed as EPICs and issues related to that Epic should be associated
• Broad initiatives will have EPICs with several issues to support that project

Labels

• Team labels
  • Channel- issue initially created, used in templates, the starting point for any label that involves Channels
  • Channel Ops - label for issues that directly impact the Channel Ops & team. DRI will be defined in the intro of the issue
  • Channel Program - label for issues that directly impact the Dir of Channel Programs & team. DRI will be defined in the intro of the issue
  • Channel Services- label for issues that directly impact the Channel Services Manager. DRI will be defined in the intro of the issue
  • Channel Marketing- label for issues that directly impact the Channel Marketing team. DRI will be defined in the intro of the issue
  • Channel Distribution- label for issues that directly impact the Distribution leader. DRI will be defined in the intro of the issue
  • Channel GSI - label for issues that are owned by the Dir of GSI. DRI will be defined in the intro of the issue
  • Internal Channel Enablement- label for issues that are focused on Internal Channel Enablement issues. DRI will be defined in the intro of the issue
  • Channel Handbook Needs- label for issues that are about pending or planned Channel Handbook changes. DRI will be defined in the intro of the issue
  • QBR - Requests from Sales QBRs
• Priority Weighting (using Eisenhower matrix and weighted tabs in Gitlab)
  • WEIGHT 1 ~ Channel Priority:1 - Home runs (high value to GitLab and high likelihood of success that align to Sales & Channel OKRs) and committed to completion within stated milestones. This category will be limited because not everything can be a priority. These are both URGENT & IMPORTANT
  • WEIGHT 2 ~ Channel Priority:2 - Big Bets (high value to GitLab, lower time urgency, longer dependencies or lower likelihood of success) within stated milestones. These are not urgent but IMPORTANT to our success
  • WEIGHT 3 - Channel Priority:3 - Small wins within stated milestones. These are URGENT but not strategically important. Delegate or push out
  • WEIGHT 4 - Channel Priority:4 - Small wins that are important but high value. Should be slotted in where backlog allows
  • WEIGHT 5 - Channel Priority:Backlog - Things in the queue not currently being worked LABEL

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

• Milestones are within 2 week windows
• Channel - FY2xQxM(month#)a (1st-15th) or b(16th-30th),
• Like this: Channel - FY21Q2 3a

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