The Retention Team at GitLab focuses on uncovering and addressing the leading reasons for subscription cancellation through hypothesis based testing and iteration. We will analyze churn from both a revenue and net customer perspective and will use that information to inform prioritization.
We will gain a deep understanding of the top reasons for churn by leveraging qualitative data from our customers and by partnering with Customer Success and Customer Support. In addition to the qualitative data we will analyze quantitative data to understand the key signals that indicate an account is at-risk or successful.
Our testing will likely focus on identifying at-risk customers and guiding them back to successful.
Our goal is to keep teams happy and engaged with GitLab so they can continue to realze and benefit from the value that GitLab provides.
Retention Team Mission
Encourage customers to keep using GitLab by:
Measured by gross retention. Gross retention is defined as: Gross Retention (%) = (min(B, A) / A) * 100%
A. MRR 12 months ago from currently active customers
B. Current MRR from the same set of customers as A.
Supporting performance indicators:
Do you have challenges? We’d love to hear about them, how can we help GitLab contributors stay happy and engaged with GitLab?
Retention runs a standard growth process. We gather feedback, analyze the information, ideate, then create experiments and test. As you can imagine the amount of ideas we can come up with is enormous so we use the ICE framework (impact, confidence, effort) to ensure we are focusing on the experiments that will provide the most value.
The growth team at GitLab is new and we are iterating along the way. As of August 2019 we have just formed the Retention group and are planning to become a more mature, organized, and well oiled machine by January 2020.
|Paid account signup||How our users purchase GitLab Plans and add-ons when initialy creating their GitLab account.|
|9.0||Disable ability to turn Auto-Renew off for .com and provide a cancel option||.com customers are not aware that disabling auto-renew is essentially the same thing as canceling. If we allow users to cancel (e.g. turn auto-renew off) and explain what they'll lose, we'll see a higher % of subscriptions renew. By collecting feedback during the cancellation process we will also learn of additional opportunities to increase retention.|
|8.3||Manual true-up cycle for GitLab.com group accounts||After a GitLab.com group has upgraded to a paid tier, the group is charged once for the year based on their current membership count. If that group continues to add members after this initial charge, we do not true-up these users and charge for them. As a result, the number of undersubscribed groups is high and represents ~$4M in unclaimed ACV (without pro-rating the seat overage and assuming all groups choose to pay for their additional users).|
|8.0||Charge for `seats currently in use` on GitLab.com when Auto Renew is enabled||When a customer's subscription has the Auto Renew setting toggled to ON, the system will create a new subscription at the renewal date identical to the existing subscription. The problem is, we are losing license money where there are more seats active on GitLab.com than what was in the subscription.|
|7.3||Link to customers portal in renewal banner||We need to link to the customers portal in the license/subscription expiration warning banner because users generally only go to the portal once a year and often forget where to go and sometimes go to gitlab.com instead. Several customers have mentioned they share this confusion.|
Reports & Dashboards