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

Customer Programs

  1. You are here:
  2. Handbook
  3. Sales
  4. Field Operations
  5. Customer Success Operations
  6. Customer Programs

What we do

Customer Programs creates communication paths using Gainsight to inform, educate, and learn from our customers.

You can see more information about what we do and our strategy in the following decks:

Program Content

The Customer Programs team creates content for the wider GitLab community.

Who we support

We support all customers with our digital motions but primarily serve our tech touch and scaled segments with time-based and/or data driven email programs to further enable them in their journey with GitLab.

Programs lifecycle

Programs follow the lifecycle of the customer, from onboarding to enablement to retention.

Customer Lifecycle

Programs overview

Programs can be any of the following:

Deadlines and time expectations

Each program we send is created by the CS Programs team in Gainsight. Once a program is created and designed, we can make changes to the content. Creating a new program can be a time-intensive task, especially if the send rules and other parameters are specialized.

Program and copywriting timelines

New program timeline

For a new program, the workflow is as follows:

  1. The requester submits an issue using the correct template, filling out as much information as possible. If the form is not complete, this may delay completion. Please include the desired date the program will go to customers.
  2. The CS Programs team verifies that the information needed is present and will provide additional information or clarify.
  3. The requester provides initial content for the program. This may be copy content, such as the contents of the email requested, branding requirements, and any token information needed to create the program.
  4. The CS Programs team provides a timeline for completion once all the information is available.
  5. The CS Programs team requests SME review from Product and/or Support as needed.

In general, at least 5 business days are required for a new program, and in most cases it may be closer to 10-15 business days, depending on the complexity of the request.

Program update timeline

For program update requests, the workflow is as follows:

  1. The requester submits an issue) using the correct template, filling out as much information as possible. This should include the name of the program to change, and the date the requester wants the change to be completed.
  2. The CS Programs team verifies that all information needed is present and will provide additional information or clarify.
  3. The CS Programs team makes the requested changes to the program copy document, then requests SME review by Product and/or Support as needed.
  4. When SME review is complete, the CS Programs team adds the changes to Gainsight.

In general, at least 5 business days are required to update a program. Depending on the size of the change, it may take longer. For example, adding a paragraph or removing a bulleted list from an email is simple, but adding an entirely new email to a series requires a new program to be created due to Gainsight limitations.

Copywriting and technical writing

The CS Programs team can provide copywriting and proofreading assistance.

To request assistance with existing copy, please allow 2-5 business days.

To request copywriting, please provide as much content as possible to begin. This may take between 3 and 10 business days, depending on the complexity of the request and the amount of additional research or SME review required to approve the content.


Available program metrics and data and timelines

When an email program is sent, Gainsight collects data about the following points:

New programs typically take 30 to 60 days to show meaningful data.

If the information requested is already available in Gainsight, please expect 1-3 business days beyond 30 days to respond to the request.

If a new dashboard or report must be created, CS Ops will provide more accurate time expectations.

Program recipients

Customer programs are sent to our tech touch and scaled CSM customer segments where there is a GitLab Admin contact. If there is no GitLab Admin on the account the program will send to the sold to contact.

For these CSM segments we require a GitLab Admin contact to be added to the following deals at the time of the opportunity approval submission:

Learn more about the GitLab Admin contact role requirement on the Gainsight Go-To-Market Technical Documentation page.

GitLab Admin contacts

You may add a GitLab Admin contact at any point in the customer lifecycle.

To add a contact using Gainsight:

  1. Navigate to the Gainsight Customer360 page.
  2. Under Contacts, find the contact name to enroll.
  3. Click the ... icon.
  4. Click View Details.
  5. Edit the GitLab Role field.
  6. Select GitLab Admin from the picklist.
  7. Click Save.

To add a contact using Salesforce:

  1. Find the contact in Salesforce.
  2. Edit the Role field.
  3. Select GitLab Admin from the picklist.
  4. Click Save.

See our GitLab Admin contact required page for more information.

Available programs

Programs are available to specific customer types.

Digital customer programs

The programs below are available to our Tech Touch and Scale CSM customer segments. These are sent to our GitLab Admin contacts and sold to contacts when GitLab Admin = Null.

Program Category Content Email Send Time Program Type
Onboarding Enrollment Onboarding Copy doc 0-2 days of contract date Time-based trigger
Onboarding Series Onboarding Copy doc 2-5 days Time-based trigger
CI Enablement Series Enablement Copy doc 15-20 days Time-based trigger
DevSecOps Enablement Series Enablement Copy doc 35-40 days Time-based trigger
CD Enablement Series Enablement Copy doc 55-60 days Time-based trigger
Agile Enablement Series Enablement Copy doc 65-70 days Time-based trigger
Monthly Newsletters Enablement Epic Sent Monthly on Fridays Time-based trigger
NPS Post-Onboarding Survey Onboarding Issue First Value Date, or 90 days after contract date, whichever is first Time- and usage-based trigger
NPS Pre-Renewal Survey Retention Issue ~ 120 days before Next renewal date Time-based trigger
NPS/CSAT Post-Renewal Survey Retention Issue 60 days after Next renewal date Time-based trigger
Monthly Webinar Invitations Enablement Handbook Sent monthly dependent on event date Time-based trigger
Post Churn Survey Retention Issue Opportunity marked Closed-Lost, Active Subscription = 0 Usage-based trigger
Low License Utilization (SMB Only) Retention Issue License Utilization less than 75%, customer between 90-150 days of contract Usage-based trigger
High PTC (value 1 or 2) Retention Epic 6-9 months before next renewal date, PTC Value = 1 or 2 Usage-based trigger


CSM-assigned account programs

The programs below are available to CSM-assigned accounts only and are sent to a GitLab Admin contact.

Program Category Content Email Send Time
Intro to GitLab CS + Onboarding Onboarding Copy doc When a customer is first assigned a CSM (GitLab Admin OR Sold to Contact)
AE <> CSM Introduction Onboarding Copy doc When a customer is first assigned a CSM (Sold to Contact)
Monthly Newsletters* Enablement Epic Sent monthly on Fridays to GitLab Admin contacts
NPS/CSAT Post-Onboarding Survey* Onboarding Issue Customer since = 60 days & GitLab Admin
NPS/CSAT Pre-Renewal Survey* Retention Issue ~ 120 days before Next renewal date
NPS/CSAT Post-Renewal Survey Retention Issue 60 days after Next renewal date
CSM Enrolled Onboarding Enablement Campaigns Onboarding Copy doc Issue CSM enrolled contact through multi-picklist Enablement Enrollment on the contact in Gainsight - see issue for instructions
CSM Enrolled CI Enablement Campaigns Enablement Copy doc Issue CSM enrolled contact through multi-picklist Enablement Enrollment on the contact in Gainsight - see issue for instructions
CSM Enrolled CD Enablement Campaigns Enablement Copy doc Issue CSM enrolled contact through multi-picklist Enablement Enrollment on the contact in Gainsight - see issue for instructions
CSM Enrolled DevSecOps Enablement Campaigns Enablement Copy doc Issue CSM enrolled contact through multi-picklist Enablement Enrollment on the contact in Gainsight - see issue for instructions
CSM Enrolled Agile Enablement Campaigns Enablement Copy doc Issue CSM enrolled contact through multi-picklist Enablement Enrollment on the contact in Gainsight - see issue for instructions

* Monthly newsletters and NPS/CSAT surveys require a GitLab Admin contact

Create or update a program

You may request new programs, such as an email series, contribute to existing programs, or update programs. We provide issue templates for ease of use.

To request a new program or update an existing program:

  1. Open a new issue in the CS Ops Project.

  2. Select the appropriate template from CS Programs.

  3. Fill out as much of the template as possible. Missing information may cause delays.

CS Programs will assign the request. For urgent issues, or questions about the request, make an @mention to a Gainsight administrator or ask in the #cs_ops_and_programs Slack channel.

Subject Matter Expert (SME) review guidelines

You may be asked to perform a review of current or new content. This review should not take more than an hour in most cases.

SME review guidelines


As a subject matter expert (SME) reviewer, you’ll be asked to review content for technical accuracy and completeness.

The review process

  1. A draft version of a Google Doc may be provided to you, or you may be asked to review an MR for the content.
  2. You’ll have a set amount of time to review the document and add comments to it with any suggestions, corrections, or additions. If, for any reason, you can’t complete the review, please comment in the issue.
  3. When your review is complete, comment in the issue.
  4. The content requester and technical writer will complete a final review after all other reviews are complete.

When reviewing, please keep the following in mind:

  • Typos and grammatical errors are likely to be present. We fix these documents once all revisions have been made.
  • We use the GitLab Writing Style Guidelines for emails to retain consistency with the Handbook and other GitLab communications.
  • Additions are always welcome! If there’s something that should be in a document, please add it.
  • Don’t be afraid to request a removal of information in the document. If it doesn’t belong there, let us know.
  • We try to keep our content brief. The content we create has to toe a line between persuasive, like a sales or marketing piece, and educational, which is concise.

What to look for

  • Is the What’s In It For Me (WIIFM) clearly stated? As a SME, you have a good idea of why this product or feature is important to a customer. Are we clearly communicating that? Consider why a customer may not know what this can do for them, and how you’d address that.
  • Is the information presented technically correct?
  • Is each step, if applicable, correct, in the right order, and results as expected?
  • Are any terms used incorrect or outdated?
  • Is there content that should or should not be included in this document?
    • Links
    • Blog posts
    • Videos
  • Is the order of information correct for the product or process?
  • Does anything need to be listed or explained first, before other processes or steps?

Tutorial and guide development workflow for GitLab Docs

The Product teams may wish to request new tutorials and guides to be added to the GitLab Docs pages.

What is the difference between a guide and a tutorial?

A tutorial is intended as a step-by-step instruction to perform a task or tasks. For example, we may want a tutorial for how to set up Two-Factor Authentication. A tutorial would go through the steps in order to complete the process.

A guide may link back to a tutorial, but is less instructional and works to provide guidance, recommendations, and troubleshooting help for a feature. For example, we may want to explain how to set up CI at a high level, then link to tutorials for each step of the process.

Review workflow

The Product team creates the framework of the tutorial or guide. This includes:

  1. The CS technical writer reviews and organizes the content provided.
  2. A structure is determined, including the order of the information, how much information is presented, and where and how links to existing documentation may fit.
  3. This first draft is provided to the Product team for review.
  4. The Product team reviews the draft version of the document and approves it, or makes the changes needed to approve.
  5. The CSE/CSM and SA teams review the draft and make suggestions and recommendations to fill out the content as needed.
  6. The Docs team performs the final review of the content and approves, or suggests changes for approval.
  7. The CS technical writer completes the process and finalizes the content in the Google Doc or MR.

Request customer program research with the Research Template

CSE/CSMs can use the Customer Programs Research Template to research new program oppportunities for different stages and use cases. This template provides suggestions for information we can use to create valuable programs for our customers.

To create a Program Research issue:

  1. Create a new issue using the CSM Program Research Template.
  2. Use the questions in the template to gather as much information as possible for the stage or use case.
  3. Assign the template to a CSM or CSM manager for peer review. This will be a multi-step process, as you'll need to ask questions of your customers as well as internal sources.
  4. Once CSM peer review is complete, create a new issue using the appropriate template, and relate this issue.

Create a CTA with a Digital Program playbook

Program emails intended to be sent as a sequence have been added as playbooks in Gainsight. These need to be sent manually by the CSM. They are set up to facilitate reminders and make this process easy, while we learn how customers want to engage.

See the Customer Success Playbooks page for a list of current playbooks.

To use a playbook to send emails:

  1. In Gainsight, create a new CTA in the Customer 360.
  2. For Type, choose Digital Journey.
  3. Select the appropriate playbook. For example: New Customer Digital Onboarding - Self-Managed Email Series, which will add a checklist for each email in the sequence.
  4. Save the CTA.
  5. Click the whitespace next to the name of the next email to be sent.
  6. Click Validate Email. This opens an editor where you can choose contacts and modify the email before sending it.
  7. Click Preview and Proceed to see the fully populated and formatted email before sending.
  8. Send the email, or save as a draft.

A/B testing and control groups for digital customers

We sometimes apply A/B testing to digital program where we test different subject lines, calls to actions or the efficacy of the program itself. The Customer Success Operations team created a rule that puts each customer into either A or B.

See more about how we set up A/B testing on the issue page.

Control groups are also used for digital customers in order to measure the impact and effectiveness of our programs. We use the insights to make adjustments and validate the value provided. Once validated, we remove control groups for long term programs that improve our customers' experience. This can mean that a small percentage of customers may not receive onboarding or enablement content during pilot programs.

Program update tracker

Customer email programs are updated when new content is added, existing content changes or existing content needs to be removed.

The program update tracker allows us to see what the general contents of each program contain so we can quickly determine which programs need to be updated.

Open in Web IDE View source