Customer case studies

On this page

Customer case studies program

The goal of the customer case studies program is to share and market the success of our customers. We do this by helping them craft their story in a way that makes them proud and excited to talk about their success with GitLab.


A formal case study produces a polished, finished document published on our customers page. Case studies can include multiple formats, including a web page, video, downloadable PDF, and associated blog posts.

A customer story is a blog post about how a customer solved a particular problem or received a specific benefit and are published on GitLab's blog. Customer stories can also be anonymous. e.g. "A large international financial services company used Gitlab CI/CD to reduce build times from 1 hour to 10 mins."

Customer case study process

Account Executive:

  1. Ask the customer to agree to a formal case study and commit to a format: video testimonial, written case study, or both
  2. Connect the customer with the content team to build out the story, potential deliverables, and timelines.
  3. Create & fill out a new issue in the Marketing issue tracker and use the "Customer_Story_Kickoff" template.

Content team:

  1. Schedule a discovery call with the customer & Content Marketing Manager to uncover use cases and identify metrics.
  2. Confirm deliverables and set timelines and expectations with the customer.
  3. Identify & confirm case study storyline & schedule follow-up customer interview if necessary.

Explaining the Case Study process to a Customer & Creating the Case Study:

Below is an example email that the writer may send customers to after the AE has introduced them to the customer. The email below will help the customer to get a better sense of what we are asking of them.

Hi X,

It's nice to e-meet you, we'd love to hear more about your journey to GitLab and potentially write a customer story on COMPANY NAME.

Here are the steps that we'd work with you on.

  • 20-30 minute phone call to hear more about your industry, business, and team. (In the call, we would also like to hear more about your decision making process to first choose GitLab and then eventually purchase EE.)
  • Review of the draft customer story
  • Final review of the customer story Then once the customer story is agreed upon by you or someone on your team we will publish it on GitLab's channels.

Please let me know if you're open to kicking off the customer story process on X date

Collecting Metrics:

Possible quantitative metrics that the customer can be asked to share with GitLab include:

The customer case study should then be written by the Content team, and the draft sent to the customer for their input and approval.

Other sections in the case study can be found on the customer's website or by searching the web - Sidebar summary, The Customer.

Following approval from the customer, the Design team should be sent a doc of the case study to include in the case study design template. The case study can then be published on our website.

Case Study Format:

Headline: The name of the customer and the benefit they gained from implementing our solution

Sidebar Summary: Summarize key points

The Customer: A brief introduction of the customer, not the solution.

The Challenge: What was the customer trying to change or improve. What regulations or market conditions drove the customer to search for a new solution. Share the steps the customer took to solve the problem, including other products and services they investigated.

The Solution: Detail the solution and how it aligns to the customers requirements. Also detail other solutions that GitLab interfaces with. Also include customer quote.

The Results: Detail how GitLab supported the customer to solve their problems. This is where the use of benchmarking metrics such as such as time saved, reduced costs, increased performance etc. are required.

About GitLab: Short paragraph on GitLab - about, solutions etc. Call to action of solutions offered.

Possible Additional Supporting Documents:

Case studies should put the spotlight on our customers and tell a story about the ways in which they help their own customers. In telling that story, we should detail how GitLab helps them get that job done. Case studies should include metrics, but a compelling story can be told without them if there aren't any available. If metrics are unavailable, consider including the customer's overarching results, such as increased collaboration or stronger relationships between developers and operations.


Case studies should always take high priority. Once a case study is initiated, it should take no longer than 2 weeks to turn around a draft for review. Once the case study has been reviewed and approved by the customer, it should take no longer than 5 working days to publish on the marketing site.

Case Study Process

  1. Once the customer has agreed to a case study, Content Marketing Manager will assign to a writer and label CMM - Planning. Deadline for completion is 2 weeks from the date the issue is was labeled CMM - Planning. Add the deadline to the issue.
  2. Writer will submit audio recording for transcription using Transcription Panda's standard (2-3 day turnaround) option. Use JJ's credit card (found in 1Password) and send her the final receipt.
  3. Once transcription is returned, writer will create a draft following the case study format
  4. Once the draft is completed, writer will label CMM - In review and ping the Content Marketing Manager to review and send for approval.
  5. Once the case study has been reviewed and approved by the customer, follow the publishing process below to add to the marketing site.


  1. Start by creating a .yml file in /data/case_studies directory under Marketing site repo (www-gitlab-com project).
  2. 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.
  3. Once created, add contents of the file using this sample Case Study template, and then update the values of each property based on case study details, remember, do NOT change property names.
  4. Once this file is added, you'll need to restart marketing site server by first closing it using Ctrl+C and then running bundle exec middleman again.
  5. When the server is started, you can view generated Case Study page in your local instance of marketing site under the URL, for eg; http://localhost:4567/customers/foobar.
  6. Please note that you don't need to restart server again if you make any changes to foobar.yml file, this is required only when a new file is added to the /data/case_studies directory.