In order to manage customers at scale we must have a consistent way of keeping track of customer details including the current “health” of the customer. The health of a customer is affected by many different factors including product usage, support interactions, internal budgets, and TAM communication.
The current health of a customer is also directly related to the customer’s journey with GitLab. Because of this, customer health and the running communication notes between a TAM and the customer should be closely linked. Since the primary location for recording customer health scores is in Salesforce, the running call notes should also be available in this location.
Meeting/call notes are the running notes for the TAM’s regular interaction with the client. The call notes should at least cover the following topics:
Updates on action items from the TAM
New updates from the customer
A review of any open support tickets in Zendesk
Current customer health from a business and operational standpoint
At the end of each customer call any changes to customer health should be reflected in the appropriate Salesforce field. If the Customer Health Score drops below Yellow an issue must be created in the Account Triage Project, see details here.
Call notes should be saved in Google Drive (here) following this format:
The rationale for saving call notes in this manner is as follows:
Call notes frequently contain sensitive information and are for the internal sales team and management to review.
Call notes are tightly linked to the Health Score and should be available in the same “pane of glass” as the Health Score.
A folder structure allows non-Customer Success executives and support staff to easily locate the notes in the case of an escalation.
The naming convention “<customer> - Meeting Notes” allows for fast searching using Google Cloud Search for Work (https://cloudsearch.google.com/)
Determining Customer Health
Refer back to the Health Scoring Criteria for details on what each health score is intended to represent. Some common things to look out for during regular meetings are:
Utilization of the product. Is it just being used for a single facet of the GitLab experience?
High number of “important” feature requests. Is the customer trying to make GitLab work just like another legacy piece of software in their environment? A review of the GitLab workflow and best practices may be in order.
High number of support requests. Is the customer struggling to keep GitLab operational or performant? An architecture review should be considered.
Missing cadence calls. Missing cadence calls could be a sign that GitLab is being deprioritized, work with your SAL to schedule a QBR or higher level discussion to evaluate the customer’s health.
Failure to upgrade. Is the customer more than a major release behind? Work with the customer to explain the new features and security updates of the current version of GitLab and address any internal technical limitations that have prevented upgrades. Develop an upgrade plan with the customer if appropriate.
Customer cadence calls should be scheduled weekly during the customer onboarding phase and at least monthly otherwise. Health scores should be updated at the end of each cadence call if there is a change.