View the CSM Handbook homepage for additional CSM-related handbook pages.
This page covers the factors to consider for customer health, guidelines for selecting the appropriate rating, communication guidelines, CSM responsibilities and instructions for the account triage issue creation.
Health primarily considers the business impact to GitLab by evaluating the delivery of value and outcomes to customers. The following guideline will provide Customer Success Managers (CSMs) guidance to choose the right health assessment for their customer account. The following are the categories to assess and associated risks with each.
The items below serve as guidelines for the CSM to assess and record customer health and should consider where the customer is their lifecycle journey. Account health feeds into open renewal opportunities.
Understanding how Gainsight calculates a measure score to be Red, Yellow, or Green:
Gainsight scoring framework:
Calculation: ((Score * Weight) + (Score * Weight)… / (Max Potential Score * Weight)
To view the score, hover over the colored circle. The weight is shown in the upper right corner of the metric.
Customer Health (CSM Portfolio Dashboard) report to view the health of every measure for your customers in one single view.
To view Timeline entires where the CSM Sentiment was updated:
Customer is very likely to renew and/or expand with no known or assumed risk of downsell or churn. Customer's experience: engagement, adoption and experiences are as expected or better than expected, delivering value and outcomes as appropriate the customer's stage in their journey. Examples:
Potential risk or significant lack of information leading to uncertainty. Indicates challenges to overcome, with a lower risk of churn or downsell. Customer's experience: engagement, adoption and/or experiences are lower than expected, risking GitLab's ability to deliver customer value and outcomes and/or drive future revenue growth. Examples:
There might be well understood reasons within the account team why a customer is flagged as Yellow within the current phase of the customer lifecycle. If the CSM decides that corrective actions and follow up from team members outside of the CSM group is required the CSM must follow the At-Risk Customer Process and flag the account as Yellow "Requires Triage".
Specific, known risks to account retention or upcoming opportunity, or overwhelming lack of information, such as unresponsiveness leading up to renewal. Customer's experience: engagement, adoption and/or experiences are significantly lower than expected where issues are blocking GitLab's ability to deliver expected value, outcomes, or positive experiences as defined by the customer. Examples:
Very rarely, a customer reaches a point at which it is accepted by the account team and leadership that a customer will churn. As Gainsight does not support a 'grey' color (or any color outside of the standard green to red health scoring), the
will churn lifecycle stage can be applied in 360º Attributes. Applying this stage will remove the customer from health scoring reporting, so that at-risk reviews are spent productively.
In order for a customer to move to the
will churn stage, the following must be completed:
Will Churnissue (
Will Churnissue template)
Will Churnissue and closes the triage issue
Will Churnissue provide feedback and approval
In line with GitLab's approach to blameless root cause analysis in both Professional Services and Engineering, we follow a similar methodology in the form of a retrospective in the
Will Churn issue to identify learnings from what went well and what didn't, what we could have done better to avoid this churn, and how we can change our approach in order to avoid future churn. This information is important and required to be included the issue in order to provide context to leadership prior to them approving. This retrospective and lessons learned should also be discussed in the next 1:1 between the CSM and their manager, as well as potentially lead to a handbook or process update shared with the broader team.
The following are guidelines on who to notify when an account is yellow or red. This includes the update frequency for the triage issue. Please make sure the following people are notified with the respective customer health ratings.
The CSM is responsible for coordinating with all relevant parties to develop a plan to address the risks. Typically, this will involve the account team and communication group (above), as well as other resources such as Product Managers, marketing, executive or engineering resources meeting to develop and deliver the plan to address the risks. The CSM then drives execution of the strategy and is responsible for regular updates to the triage issue. When the risks have been addressed bringing the customer to a healthy / green status, the triage issue can be closed.
CSMs update CSM Sentiment in determining overall account health. The guidelines are as follows:
The CSM Sentiment score will be updated each time you log a Timeline activity and select a value from the CSM Sentiment dropdown. Once you have logged the activity to Timeline, Gainsight will update the value of the CSM Sentiment scorecard measure and display the notes from the Timeline activity on the scorecard. The rule that sets the scorecard value runs every 2 hours.
There are a number of enablement videos you can watch to learn how to update customer health assessment and log activities that affect that assessment.
Product If usage data stops being received into Gainsight, the health measures will move to "NA" after 60 days. This is to prevent analysis and actions based on outdated data. In this case, we prefer to show nothing ("NA") over outdated data.
CSM Sentiment health scores become stale after 90 days of not being updated; this will be reflected on your health score dashboard by an exclamation point next to the score. If an account is marked as stale, but you've updated the
CSM Sentiment within 90 days, please reach out in gainsight-users. Accounts with a stale
CSM Sentiment will also be monitored via the CSM Burn-Down Dashboard in Gainsight and discussed in account planning meetings. Sentiment scores will be set to NA if they have not been updated in more than 120 days to remove outdated values.
Support Measures Support measures are considered stale if they have not been updated in more than 30 days. They will be automatically set to NA after 30 days without an update.
Health score criteria is either manually or automatically applied to determine the overall measure. If an individual measure is missing, the weighting is redistributed to the completed measures.
|Group (PROVE)||Measure||Description||Method||Calculation||Measure Weight||Group Weighting||Segmentation|
|Product||Scores the customer based on their depth and breadth of adoption, if Operational Metrics are available||Automatic||See Customer Use Case Adoption||50%|
|Risk||CSM sentiment||Qualitative measure the CSM updates to indicate their perceived sentiment of the customer||Manual/Automatic||For all
||100%||50%||N/A for Tech Touch|
|Outcomes||ROI||Does the customer have a Success Plan that has objectives and notes?||Automatic||For All
- Green: Active Success Plan with 1 or more objectives and no Strategy/Highlight information
- Yellow: Draft Success Plan OR Active Success Plan with 1 or more objectives and no Strategy/Highlight information
- Red: No Success Plan or no objectives
|100%||10%||N/A for Scale and Tech Touch|
|Voice of the customer||5%|
|Support issues||Assess the health of our support interactions. Current version is MVC with v2 coming.||Automatic||- Green: 1-5 tickets/month
- Yellow: 5-15 tickets/month
- Red: More than 15 tickets/month
|Support emergency tickets||Based on the number of open/closed tickets.
Priority: urgent tickets
|Automatic||- Yellow: 1+ closed emergency ticket in the last 7 days
- Red: 1+ open emergency ticket
|Meeting cadence||Based on recency of last call or meeting with the customer||Automatic||For
- Green: <= 35 days
- Yellow: > 35 days and <= 60 days
- Red: > 60 days
- Green: <= 65 days
- Yellow: > 65 days and <= 90 days
- Red: > 90 days
|50%||N/A for Scale and Tech Touch|
|Persona engagement||Are we meeting with the correct personas in the account?||Automatic||Persona Engagement is based on the roles of External Attendees added on timeline entries
- Green: both Dev Lead and Security Lead are listed as external attendees on a timeline entry in the past three months
- Yellow: one of the two personas attend
- Red: neither personas are listed as having attended a meeting
|50%||N/A for Growth, Scale and Tech Touch|
|2-6 Months||6-9 Months||> 9 Months|
When an account has multiple GitLab instances identified as Production (Instructions on how to Update Self-Managed Instance Type), the Product Usage health measures the most recently updated instance instead of the primary instance, causing scoring inconsistencies. Note: this is less than 5% of the time because the vast majority of accounts have a single production instance.
Video Instructions to update instance data in Gainsight to include only one instance in Product Usage health measure.
Included in Health Measuresto EXCLUDE the instance section. NOTE: Make sure you select “Opt-Out” rather than null, or the system may overwrite your update. Then click Update
Because the DevSecOps health measure looks to the account as "Ultimate", this step was added to make sure the correct production instance is scored in the case of multiple subscriptions under a given account.
If a CSM has marked a production instance under a Premium subscription, DevSecOps health will appear as be “NA”. Meaning, even if there are two subscriptions with one Premium and another Ultimate, as long as the CSM marked the Premium one for health scoring, you will no longer see a DevSecOps health score (generally red) on the account.
NEW: Admin: Update Plan Name on Product Usage Instance Metrics
Plan Namefrom the Customer Subscription object to the Product Usage Instance Metrics object
Set Score: DevSecOps Adoption Individual Measures
Plan Nameon the Product Usage Instance Metrics object instead of the
Products Purchasedon the Company object
For process overview and steps, see At Risk Process.
When an account is in triage, keep the triage issue updated as follows:
If nothing of note has occured since the last update, indicate that as well as the next steps you are taking.
When creating an issue in the Account Triage project, the default template will set up the details you should include. Follow the instructions laid out in the issue description by the template for what information should be documented in the issue.
When creating triage issues, it's important to apply the correct labels to the issue, so that we can easily track, have a holistic view of the at risk accounts, and be able to triage regionally and/or by priority. It is expected for each issue to contain one of each of the below label categories. Please refer to the issue template for more details on how to use them.
~HS::Green: Green Health Rating
~HS::Yellow: Yellow Health Rating
~HS::Red: Red Health Rating
~E&AExpected and Avoidable
~E&UExpected and Unavoidable
~U&AUnexpected and Avoidable
~U&UUnexpected and Unavoidable
~risk::lack of adoption
~risk::lack of engagement
~risk::loss of sponsor or champion
~risk::other organizational factors
~risk::lack of budget
If the account is labeled with a Customer Success Risk Reason of "product experience",
CSMs are encouraged to add a DevOps stage label (i.e.
to the triage issue, and clearly identify any related issues that are blocking adoption or required
to improve the customer's product experience within the triage issue.
Identify the Product DRI by from our product categories page and ping them in the issue. As the CSM responsible for the at-risk account, you are accountable for coordinating all resources. Engage early and often with product and any other groups required to advocate for your customer's desired outcomes.
devops:: labels are scoped; please choose the highest-impact stage label and apply it.