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.
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.
To manage our customer reference relationships like the precious resources they are to the maximum, quantified & qualified benefit for both customers and GitLab.
Quick links grid
|Quick Reference Links|
|Adding new reference customers||Requesting a reference for a sales call|
|Customer Case Studies||Search published case studies by use case, value driver etc|
|Customer Reference Collection||Customer Case Study Slides|
|Requesting a customer to speak at an event||Peer Reviews||Customer Advisory Board|
|Offical Letter re Reference Process to share with customers|
View information around customer reference pool, keep track of the latest case studies and find out how the Customer Reference team is helping share customer success stories.
Some examples of the types of assets we'd use as customer references once we have approval from the customer:
* 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 GitLab users, what was their adoption curve like? * What has been the most unexpected success you have experienced? Adoption rates? Improved speed?
It is critical and the Customer Reference Management team’s responsibility to optimize our reference customer engagements to balance:
By default, we will request a customer support reference call (sales/analyst relations/public relations) no more than once per quarter per customer. In support of event speaking and/or other participation support (field, alliance, digital, community, etc.), we will request customer support at a maximum of once every two quarters per customer. The CRM ultimately decides if the reference request is suitable for the proposed customer based on a number of factors including but not limited to:
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.
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. Our case studies should align with our customer value drivers. Find below a sample of the customer value drivers that we need to find in a good case study.
Increase Operational Efficiency
Deliver Better Products Faster
Reduce Security and Compliance Risk
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.
/data/case_studiesdirectory under Marketing site repo (www-gitlab-com project). This can be accomplished in the Web IDE.
GitLab understands the value of our customer relationships and values customers that are willing to share their success with our team. We have a logo permission form that we require be signed before we promote the customer relationship using the customer logo. We understand and respect that corporate logos are considered intellectual property and are owned and licensed by the respective organization.
If you have any questions on customer logo usage, feel free to reach out to the Customer Reference Team slack Channel: Customer_References.
Written Case studies are vital to showcasing the success of our customers and display how they overcame the pain and challenges their organizations were facing in their software development lifecycle. This is an opportunity to describe how GitLab helps overcome these pain points and provide value to the organnization. Often these stories require time for proof points and metrics to be established within customer organization. Here are the steps to creating written case studies.
Please note that we can facilitate customer interviews in other languages (FR/DE/IT/ES/JP) if the customer prefers this option
To request a reference customer to speak and/or otherwise support an event the first step is to open the Customer Speaker Request template a minimum of 60 days before the event. This issue will be tracked on the Customer Reference Program board.
Process for fulfilling a request to support a Field Marketing, Corporate Marketing/Company, or Community Event
Note: If travel is required for a customer speaker, this will not be funded by the Customer Reference Program.
Process for fulfilling a request to support a Partner/Alliance Associated event
Note: If travel is required for a customer speaker, it is covered by different parts of the org. (Determined on a per request basis.)
Process to engage with the customer once agreement for presenting at an event is secured
Requesting a confidential request (Customer not named in report)
Purpose: To reflect our customer base we use customer logos to promote organizations that are using GitLab
Customer logos appear on our website and other marketing and promotional materials. To respect the intellectual property of companies that use our product, we request a signed permission form to use their logo. To request logo usage from a customer, please send the Logo permission form to the appropriate member of the customer organization.
Information about the GitLab Customer Advisory Boards is found on the CAB page
Learn about our Peer Review Management Program
The Customer Reference Team has created appreciation swag for customers to thank them for their support and for engaging with us in reference activities. Availability of these items is limited and managed by the Customer Reference Program team.
To check on item availability and request items to be shipped to customers, please contact the following customer reference team members based on customer location:
For customers in the Americas, please reach out to Jen
For EMEA-based customers, please reach out to Fiona
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.
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 that 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.
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."
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.
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.
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.
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.
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.
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."
Read the current GitLab customer case studies on the GitLab customer page.
Interview Questions: (Select the questions we should ask)
Value Driver 1 - Increasing Operational Efficiencies
Is your MTTR (mean time to resolution) improved?
- How long to deploy (per day/week/month). After?
- Were there issues with deployment/bugs prior to GitLab? After?
- How frequently did you deploy (per day/week/month)? After?
- Are you using many tools or integrating? Do you use GitLab as a SSOT?
- Do you notice a development team slowdown due to using different tooling?
- If you switched from multiple tools to GitLab as a SSOT, do you have specific numbers to validate the time-savings?
- How much time was your developer spending in a cycle prior to GitLab? After?
- Are you noticing that compressed cycle time-savings? How much?
- How long were you down?
- What did you do about it?
- With GitLab, have you seen an improvement in your time restored? What is it.
- User/license costs?
- Computer costs?
Value Driver 2 - Deliver Better Products Faster
How has detecting bugs earlier in the lifecycle impacted the output?
- If Yes, what were your numbers for #value prior to GitLab/After
- How long did remediation take on average?
- How often, after GitLab, do you encounter failures?
- How long do these failures take to remediate?
Value Driver 3 - Reduce Security and Compliance Risk
Are audits quicker and seamless now?
- After GitLab, did you notice an increase of security vulnerability detection prior to production, and a decrease in vulnerabilities once deployed?
- Sepecific before/after numbers?
- What percentage of critical security vulnerabilities that previously escaped development have been caught?
- What was the end result of shifting further left? Quantify fewer vulnerabilities in production? Fewer vulnerabilies for security team to manage?
- Did shifting left make security team more productive? How? How much?
- If yes, how much % (ballpark if needed)
- After GitLab, how much of your code are you scanning
- If no and have Ultimate, educate on how to use this feature
- With GitLab, how much time?
Feedback on GitLab
Impact of GitLab
Impact metrics of using GitLab
Customer Use Case Questions
Version Control & Collaboration (VC&C)/Source Code Management (SCM)
Continuous Integration (CI)
Continuous Delivery (CD)
Development, Security, and Operations (DevSecOps)
Agile Project Management (Agile)
Simplify Development Operations / End to End DevOps (DevOps)
Cloud Native Approach to Applications Development (CloudNative)
Infrastructure as Code (GitOps)
Deployment Strategy Questions
Education Program Customers
Open Source Program Customers