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

Customer Reference Program

Customer reference program at GitLab

The goal of the Customer Reference Program is to provide opportunities for customers to share their story on how GitLab has helped them overcome the challenges, blockers and pain points within their organizations. The Reference Program Managers work as a conduit to help connect customers with opportunities by balancing customer requests with company demands. By providing a single point for outreach to customers, the CRP team prevents customer burnout, sales team burnout, and ensures a diversity of customer stories are shared publicly.

##Who we are Team of Experienced Customer Reference Professionals who are focused on building relationships within GitLab and with customers.
The team gathers and builds information and relationships with the purpose of distilling these impactful insights into action.

#Strategic driver of the Customer Reference Program To manage our customer reference relationships like the precious resources they are to the maximum, quantified & qualified benefit for both customers and GitLab.

##Goals of the Gitlab Customer Reference Program

Customer Reference Types

Some examples of the types of assets we'd use as customer references once we have approval from the customer:

Creating new issue for Customer Reference Program

To create a new issue around the Customer Reference Program, open an issue on the Customer Reference Program Board. Make sure it has the label Customer Reference Program. Feel free to add any applicable labels around the request. Assign to Reference Program Manager as needed.

Customer Case Studies

The most recent customer case studies are found on the GitLab customer's page. When we build case studies, we need to have quantifiable metrics and business value to help describe how GitLab helped a customer achieve a significant business result. Below are a sample of KPIs / dimensions we need to find in a good case study.



Business Value

Better / Quality

If a proposed customer case study doesn't have at least one metric to include, then we consider working with the account team to help identify a solid metric before building the case study.

Common Interview questions

Interview Questions: (Select the questions we should ask)

Why GitLab

What if

Feedback on GitLab

Impact of GitLab

Metrics of GitLab

Publishing to the website

  1. Start by opening a public issue and an Merge Request in the www-gitlab-com project.
  2. Create a .yml file in /data/case_studies directory under Marketing site repo (www-gitlab-com project). This can be accomplished in the Web IDE.
  3. Keep the name of file same as company name (this is not mandatory but it is easier to manage), for eg; if company name is "Foobar", create a file as /data/case_studies/foobar.yml.
  4. Once created, add contents of the file using the sample Case Study template, or by scraping the content from an existing case study, and then update the values of each property based on case study details, remember, do NOT change property names.
  5. Add images to the same MR. This ensures they show up in the preview app. To accomplish this, stay in your MR and on the left rail open the selected file. Upload the file to the specific directory by hovering over the file and selecting upload file. The Cover image needs to be a .jpg and put in 'source/image/blogimage' directory. The company logo needs to be a color .SVG image and is placed in the 'source/image/case_study_logos' directory.
  6. In the Web IDE, you can view generated Case Study page in the generated App under the URL, for eg; http://localhost:4567/customers/foobar.
  7. Once the case study is ready to publish, remove the WIP label from your MR and ask an approved publisher to post.

Customer references collection

Our written customer case studies are found on the /customers page Our video customer case studies are found on the YouTube site on this playlist

To initiate a formal case study process, follow the process listed here

Reference Program Process

Adding a new reference customer (Note the process is currently different for SALs) ** Commercial and SMB process** 1. AE nominates customer for the program to Customer Reference Manager by adding an issue to the Customer Reference Program Board 2. CRM - AE briefing
Key info needed: - Industry / Vertical - Region/Geo - Tier (core, starter, premium, ultimate) - GitLab Use Case - Customer Segment (strategic, large, smb) - Deployment size (licenses) - Customer Story (why GitLab, key metrics, etc) - Who did we beat?
3. AE Introduces CRM to customer - Describe the Customer Reference program - Describe the types of reference activities and gauge their interest - Gauge their interest participation level

  1. CRM updates Referenceable customer field in SFDC with information

SAL Process

  1. SAL nominates champion from the contact record from the button at the top of SFDC
  2. SAL fills out the GitLab version customer is using, stages the customer is using and any information about the tech stack
  3. CRM team is notified of nomination in SFDC
  4. If additional information is needed, CRM team will outreach to SAL

Sample Interview Questions/topics for Customer joining the Reference Program

* What led you to GitLab, what problems were you trying to solve?
* Why did you choose GitLab and what other tools were you using or considering?
* What has been your experience with GitLab?  
* How did you make the business case for GitLab and what metrics have you seen improve?
* What have you heard from the GitLab users, what was the adoption curve like?
* What has been the most unexpected success you have experienced? Adoption rates? Improved speed?

Requesting a Reference for a sales call

Commercial and SMB process

  1. AE submits an issue on the Customer Reference Board with the label "Customer Reference Checks".
  2. CRM reaches out to AE for additional information and with recommended sales references

SAL process

  1. SAL selects "Find a reference" button from the selected opportunity
  2. Filter to find the most appropriate reference for your needs.
  3. Fill out required information and include any customer forms that may be required.
  4. Hit submit and wait for the approval for the call from the champion's account owner

GitLab Customer Advisory Board

Purpose: To help foster DevOps transformation and adoption we are establishing a Customer Advisory Board, where we focus on sharing DevOps best practices and lessons learned with each other. We believe that transparency and sharing is a key way to help encourage the success of DevOps transformations. The GitLab customer advisory board is intended to be home to learning and collaboration so we can all experience success through DevOps transformation.

Members Executives/Champions for DevOps within their organizations

Frequency: We meet virtually the first Wednesday of the month at 11 a.m. Eastern

Membership: Approximately 15 - 20 customers, GitLab

Meeting Recordings Meetings are recorded for internal and member use. Members can seek these recordings by emailing

Recurring Content We will frequently ask for GitLab Product Managers to join to present the vision for their assigned DevOps stage. When doing so we will distribute a recorded video of their stage vision in advance.

Meeting Schedule

Kickoff Meeting-September 5, 2018

GitLab Road Map review-September 26, 2018

GitLab Plan review-October 17, 2018

GitLab Create review-November 7, 2018

GitLab Release review-December 5, 2018

GitLab Manage review - January 9, 2019

GitLab Geo review-February 6, 2019

GitLab Configure review- March 6, 2019

In-Person CAB Meeting- April 18-19, 2019

***GitLab In-Person CAB Review -May 1, 2019

GitLab Verify direction update - June 5, 2019

GitLab Product Roadmap review - July 10, 2019

* GitLab Product Roadmap Review - August 7, 2019*

GitLab Product Roadmap Review - September 4, 2019

GitLab In-Person CAB Meeting - October 15 & 16, 2019

GitLab Special Interest Group

Purpose: We are forming Special Interest Groups to foster specific and focused discussions about how to apply DevOps practices and GitLab capabilities in specific domains such as planning, development, CI/CD, security, etc. These Special Interest Groups will encourage sharing and collaboration of DevOps best practices and lessons learned between users and GitLab.

We believe that transparency and sharing is a key way to help us all learn and improve how we deliver for our customers. GitLab special interest groups are intended to be home to learning and collaboration.

Members Technical utilizers and advocates of GitLab

Frequency: We will try to meet virtually every 6 to 8 weeks

Membership: Approximately 8-15 users, GitLab Product Manager

Customer Anecdotes

Customer anecdotes are short, "snackable" customer stories. These can be used on a call or in a meeting to share a point about GitLab by validating it with the customer story. An anecdote can be a summary of a formal, attributable case study or just an anonymous story from a conversation you had with a customer. It's important to keep customers anonymous unless we have explicit approval to use their name.

Remove the complexity of multi-tool environments

A communications company recently shared how they built their technology stack. "GitLab checks so many boxes for us that we don't need other tools." The company then explained they they are operating with a team of 2 people because GitLab makes the environment so simple. They said another organization would probably have to employ 15 people to accomplish what they can.

Administrative overhead

We hosted a dinner for customers and prospects to mingle with each other and share stories. When the topic of managing the DevOps toolchain came up, the Head of Risk at a large US bank mentioned that she had a team of 20 to keep SDLC tools running in her org. A GitLab customer, the managing director of a product group for a global investment management corporation said, "this is going to break your heart, but I have 1 guy that spends 25% time to keep GitLab up and going for my team of 1500 devs."

Deliver value faster

Pinterest is not a GitLab customer, but uses Kubernetes together with Jenkins. Because there's no native kubernetes integration for Jenkins they needed to dedicate a team of 4 spending 6 months to build a custom system to control access management and allow teams to self-serve builds. This is functionality that comes out of the box on day one with GitLab.

Adoption at an incredible pace

A large enterprise in the software space is a recent GitLab Premium customer wanting to replace Perforce. They predicted that it would take them 3 years to hit 6K active users. But, the developer experience was so superior that they ended up hitting 6K active users in only 8 months.

Security is at the center

A publishing firm is utilizing GitLab best of breed CI/CD functionality and with upcoming product advancements they have informed us that GitLab is a mission critical application for them. They also chose GitLab over the competition because security is currently the biggest aspect they want to improve on internally.

Removing the wait

A financial services company recently stated that their teams went from two week releases to six times per day using GitLab. They are able to release this quickly because they do not need to wait for infrastructure.

No babysitter required

An online gaming development house has a team of 9 looking after its toolstack for SDLC. GitLab is one of the tools in the stack, but is self-sufficient enough that they only deal with it every six months.

Providing happiness everyday

A large media company recently stated that GitLab is the best architected application they have ever used. According to this company, "This product is a joy to use. We cannot believe how much incremental value you crank out with each release."

Customer Case Studies

Ticketmaster - 15x faster build time

Ticketmaster is a global event ticketing leader with one of the world's top five e-commerce sites, getting almost 27 million monthly unique visitors. Ticketmaster was using Jenkins for continuous integration. Weighed down by plug-ins and legacy development, their pipeline was taking 2 hours to complete. After getting stuck late on a friday night waiting for the build to complete, their ops team began exploring other options. They were able to run their pipeline on GitLab CI/CD in 8 minutes for a 15x increase.

Axway - 26x faster release cycles

Axway, is a global enterprise software company with over €300 million in yearly revenue. Axway wanted to adopt DevOps practices but their legacy Subversion toolchain was blocking them. By moving from Subversion to Git using GitLab as their Source Code Management (SCM) solution they were able to implement DevOps integrating GitLab into tools like JIRA, for issue management and Jenkins for continuous integration. They increased deployments from once-a-year to every two weeks.

Paessler - 120X increased QA efficiency

Paessler AG provides the award-winning PRTG Network Monitoring software used by over 150,000 IT administrators in more than 170 countries. QA engineers were manually testing software with a routine set of tasking taking an hour to complete. By implementing GitLab pipelines they were able to automate QA tasks requiring only 3 minutes of effort for a 120x efficiency increase.

Equinix - increased DevOps agility

Equinix is a leading global data center company. Their client-side development teams are responsible for building software products and business critical applications, increase development speed, self-serviceability, and ship fixes and features quickly. Equinix needed a version control and continuous integration tool for distributed workflows to support globally distributed development teams.

Other customer case studies

Which customer reference team member should I contact?