Customer case studies

The goal of the customer case studies program is to share and market the success of our customers.

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.

Examples:

Objectives:

  • Illustrate successful and measurable improvements in the customer’s business
  • Show other users how customers are using GitLab
  • Align content so that GitLab solutions reflect the challenges our customers, prospects, and the market requirements
  • Develop and grow organizational relationships: speak at events on our behalf, promote their business

A formal case study produces a polished, finished document or video 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.”

Case study process

Internal discovery

Once you have a customer who either (1) has an excellent use case or (2) has committed to participating in a case study:

  1. AE: Create & fill out a new issue in the Marketing issue tracker and use the “Case-Study” template. Mark issue confidential and assign to @KimLock.
  2. Content: Schedule an interal discovery meeting between AE and writer to discuss the use case, angle, and identify potential metrics.
  3. Both: Set timeline for engagement and deliverables.

*If you included a case study as part of a deal, great! Set up a call with the content marketing team and the customer to go over how they plan to use GitLab and metrics the customer is willing to track. Set a follow up call in 3 months and again in 6 months.

Customer discovery

  1. AE: After you’ve met with the content team, schedule a discovery call with the customer and assigned writer for a pre-discovery call.
  2. Content: Label issue Status-Plan.
  3. Customer Reference: Affirm the customer has agreed to a case study, determine format, and metrics.
  4. Customer Reference: Schedule formal interview.
  5. AE: Update SFDC record to document the engagement.

Interview

  1. Customer Reference: Write abstract and interview questions 1 week ahead of interview.
  2. Customer Reference: Conduct 1 hour interview with case study subject(s).
  3. Customer Reference: Confirm deliverables and set timelines and expectations with the customer.
  4. Customer Reference: Confirm case study storyline, and schedule a follow-up interview if necessary.

Production

  1. Customer Reference: Submit audio recording for transcription using Rev.com standard (2-3 day turnaround) option.
  2. Customer Reference: Sends transcript to customer for approval.
  3. Customer Reference: Once transcription is returned, label issue case study - production and assign to Content Marketing.
  4. Content Marketing: Create a draft following the case study format.
  5. Once the draft is completed, writer will label Staus-WIP and ping the Content Marketing Manager to review.
  6. Customer Reference assigns to Product Marketing for review.
  7. Customer Reference sends to customer after PM reviews.
  8. Once the case study has been reviewed and approved by the customer, follow the publishing process below to add to the marketing site.

Collecting Metrics:

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

  • Reduced cycle time
  • Number of deploys in a given time frame
  • Reduced number of bugs or Reverts
  • Reduced number of admin hours
  • Cost savings % through purchasing GitLab: Reduce the cost of managing a number of different people, projects, and platforms.
  • Reduction in internal support tickets requests: Reduction in the number of support tickets team submitting to fix challenges, compared to initial SCM tool
  • Reduced number of plug-ins required by the toolchain.

The customer case study should then be written by the Customer Reference Manager or Customer Content Manager, 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

  • Customer Name and Logo
  • Customer Details: Country, Website
  • Organization Type - Public/Private & Industry
  • Annual Revenue - If publicly available
  • Employees
  • Summary of Key Benefits

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:

  • Customer Deal Summary – High Level PowerPoint summary after deal first signed.
  • Customer Success Overview
  • Infographic – Single page A4 summary with diagrams and measurable benchmarks
  • Benchmark Metrics
  • Publish on website
  • Video - Short video summary if customer is willing to participate - Perforce example
  • Blog Post - Blog post to launch customer case study
  • Keywords for SEO etc.

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.

SLA

Case studies should always take high priority. Once a case study is initiated, it should take no longer than 1 month 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.

Last modified February 23, 2024: Fix more relative URLs that throw 404 (part 2) (605d263f)
View page source - Edit this page - please contribute. Creative Commons License