View the CSM Handbook homepage for additional CSM-related handbook pages.
We are currently developing new account segmentation which will be implemented in the future. Please see the Customer Segments page for details.
There are three models currently offered for Customer Success Manager engagement. These are broken into tiers that currently use Annual Recurring Revenue as a metric for determining a manageable volume for a single Customer Success Manager and the depth of involvement during the engagement.
Customer Success Managers will typically manage customer engagements via a GitLab project in the
account-management group. This project will be based off the Enterprise or the Commercial Customer Success Plan Template and customized to match the customer's needs as outlined above. The project is pre-loaded with milestones, issues, labels, and a README template to help kick off the project and outline a proof of concept, implementation, and customer onboarding. The following is a short introduction video on GitLab's first iteration of the Customer Success Plan.
During the pre-sales process for Enterprise accounts, a Solutions Architect owns the project with assistance from the Strategic Account Leader and should include the Professional Services Engineer if there is one assigned. A Customer Success Manager is involved but only for visibility. Until the account becomes a paying customer the project remains in pre-sales. Once the customer has paid, the Strategic Account Leader will set up the "Welcome to GitLab" call along with the key GitLab employees (SAL, SA, PSE and Customer Success Manager) and the customer. There is a preloaded issue for this in the project template.
For Commercial accounts, the Account Executive owns the pre-sales process and engages a Solutions Architect as needed. Once the account becomes a paying customer, the Customer Success Manager will create a customer project if it will be useful to their relationship with the customer, and the Account Executive will schedule a "Welcome to GitLab" call with the customer and the Customer Success Manager.
The "Welcome to GitLab" call will introduce the customer to the Customer Success Manager and begin the handover process. The Customer Success Manager will then lead the rest of the call and own the customer project. If the project was created in the pre-sales project under the
pre-sales account-management group, then it is moved to a post-sales project under
Occassionally, a GitLab e-group member (VP or C-level) will be meeting with a customer, for example, as part of an executive briefing, escalation, etc. Please review the EBA handbook page on guidance on how to schedule with the E-Group, specifically the section on customer, prospect, and partner meetings with an E-Group member. There will be a prep call prior to the customer call (typically the day before), and there is an Executive Briefing Document (internal doc link) that must be prepared and shared with the EBA in advance of the prep call, in addition to any materials that will be used during the customer call. Below are some tips to ensure a positive experience:
For an example of a prep doc and additional materials that received positive feedback, please visit this internal only Google doc.
There are situations when a CSM needs to disengage with a customer. Examples include:
When this happens, it is important to manage the disengagement so that the customer understands the reason, and is clear on who they should communicate with going forward. Here are some recommendations for how to have this conversation:
Recommended options to review with the customer include:
Customer Success Managers focus on helping customers achieve business outcomes by advising and enabling customers on usage of GitLab features. We are able to do this most effectively when we are engaged with customer personas who are responsible for the capabilities that GitLab provides.
We have defined two key personas that CSMs should regularly engage with and align on outcomes and use cases:
A member of the customer's development or engineering department, in a leadership role. This person is aware of and/or responsible for delivering on customer business objectives related to the customer's software production. They are able to speak to development workflows, and SDLC and DevOps practices and challenges.
Has responsibility for the security of the software the customer develops. This person is able to speak to business requirements, objectives, compliance frameworks, etc. that the customer has related to the software they produce. They have knowledge of (and possibly own) the customer's current security scanning & management tools.
Customer personas are attributed to individual contacts in Gainsight when viewing an account. To capture a customer persona, use the following steps:
Contactslink on the left.
GitLab Rolefield and select the persona(s) that apply to them, and then save the field by clicking the check button to the right.
GitLab uses a customer prioritization model and associated metrics based on their customer segment (Strategic, Mid-Touch, Scale) to focus the CSM's efforts where they will have maximum value and impact.
On the Gainsight Attributes section, the CSM can set the priority level per customer with levels 1 or 2, with 1 being the highest. A new CSM-assigned customer coming on to GitLab will default to Pr1 until their onboarding enablement is complete. Pr3 is solely for unmanaged child accounts, and Pr4 is only for our digital customers and not for the CSM-assigned segment, with the exception of the Public Sector that is trialing a CSM-assigned digital customer. Priority definitions vary by CSM segment.
Why do we use a prioritization system?
CSM Portfolio Dashboard is used to help highlight and review each client, including their priority level.
Priority definitions are as follows:
CSM-assigned customers are segmented into two priority tiers:
Priority 1 (P1) and
Priority 2 (P2). We use a series of "yes/no" parameters to evaluate a customer's prioritization, based on the key aspects of a CSM's responsibilities and value to the customer. There may be rare use of a
Priority 3 (P3) tier, wherein an account is a child account that is not actively managed outside of its parent account but is still within the Strategic segment.
Each CSM should aim to have roughly one third (1/3) of their book of business listed as
Priority 1, and the rest as
The following parameters are considered when determining customer prioritization:
|Open tier upgrade in the next 3 months||Upgrade opportunity is open in Salesforce and actively being discussed with the customer||No open opportunity in Salesforce, and/or no active upgrade discussion with the customer|
|Contraction or Churn risk||Account in Triage process||No contraction or churn risk identified|
|Onboarding||Within first 60 days of onboarding||Not in onboarding phase|
|ARR limit||Within ARR limits for P1||Not within ARR limits for P1 phase|
Using the defined parameters and guidance on how to know whether they are applicable, we can use the following flowchart to evaluate priority:
A working spreadsheet was created to help determine customer priority.
* Please see priority exceptions for details.
When a new customer is in onboarding, they are automatically
Priority 1. This is a key lifecycle event for a customer, which warrants high engagement from the CSM. Once onboarding is complete, the customer's prioritization should be reassessed.
Since the parameters used to evaluate customer prioritization will change over time, each account's priority should be reviewed and updated quarterly, coinciding with QBRs.
There are occasions that warrant a customer to be prioritized differently than the model indicates. In cases where the CSM and/or SAL believes this is true, an exception may be made.
Examples of when an exception may be appropriate include:
In order to make an exception, the CSM or SAL should discuss the details with the members of the account team and their respective managers. Exceptions will be addressed to the regional Sales Management team and documented in Gainsight.
The Growth segment aims to have no more than 20% of a CSM's book of business to be Priority 1 at any given time.
For a customer to be Priority 1, they must meet at least one of the following parameters:
There are a few most-common types of risk we see: red DevSecOps adoption, low license utilization, low PTC score, and non-engagement.
The following two cases qualify a customer to be both red health and Priority 1 immediately:
The following two cases require further consideration and/or triage before automatically qualifying them for red health and P1:
We onboard customers that are both entirely new to GitLab, as well as customers that have been customers for a while but are new to having a CSM.
Customer growth is the pillar of what the Growth CSMs do. Much of that growth is a natural byproduct of our day-to-day engagement with customers, ensuring they are adopting and getting the resources they need. However, we do have large upsell opportunities as well that benefit from additional attention.
The CSM has the autonomy to review potential growth opportunities in their customer base and determine if the account would benefit from being classified as P1 with additional attention and sync calls.
If the growth opportunity is an uptier from Premium to Ultimate, the SAL/AE and SA should be leading this engagement, as it's a pre-sales motion, but the CSM should be involved throughout the process, keeping up to date on requirements, feedback, etc. to ensure that when a customer does upgrade, there is a seamless transition from planning to implementation.
The primary difference between Priority 1 and Priority 2 customers is the frequency of synchronous engagement:
Priority 1 customers will also have more focus on having EBRs to ensure alignment on use case adoption and future expansion.
Even with the prioritization model, all customers require attention, which can be difficult to handle with a larger book of business.
Below is some guidance to help CSMs scale their workload:
As GitLab moves into FY24, we are changing how we look at prioritization in order to be more efficient and continue to drive customer ROI. In line with the Growth team's goals of having a programmatic approach to grow a large customer base and aligning on and building success goals with each customer through usage reporting and strategic touchpoints, we will be pivoting to prioritizing customers based on use case adoption. The below information is a work in progress as we roll out this change.
For any customers that do not have usage reporting available, the CSM should regularly ask the customer discovery questions about their usage to determine how well-adopted they are and where they may be gaps, as well as request a copy of the payload in order to get a snapshot in time of their adoption. The CSM should review any customers who do not have usage reporting or provide a payload with their manager to appropriately prioritize them.
Priority 1 customers will continue to have monthly cadence calls, with the exception of newly onboarding customers, who should have weekly syncs for their first 30 days. Priority 2 customers will continue to have quarterly cadence calls.
The Scale Account prioritization model will be defined in FY23Q1.