View the CSM Handbook homepage for additional CSM-related handbook pages.
Escalations can take at least two different forms:
The purpose of this handbook entry is to describe the process for account escalations. Please see the Support Ticket Attention Requests for details on how to request a support ticket escalation.
Define the process for managing account escalations and define a framework for communications, activities, and expectations for customer escalations.
This process addresses critical and high escalations for CSM-assigned customers. This process can also apply to other segments if a strategic partnership or relationship exists. Any GitLab team member can escalate an account on behalf of the customer.
Severity Level | Description | Cadence | Levels of Involvement |
---|---|---|---|
Critical | Major issue(s) significantly impact customers' ability to deploy or use a solution, risk loss of or use of a solution, high risk loss of a customer or significant contraction, or significant risk to the relationship and brand. | Daily | VP of Sales, Product, CRO, CEO, VP of Customer Success, Global/PubSec CSM Leader |
High | Major issue(s) significantly impact a customer's ability to deploy or use a solution, risking current adoption, risk of loss of customer or contraction, future growth on the account, and damage to the relationship. | Multiple times per week | VP of Sales, Product, CRO, CEO, VP of Customer Success, Global/PubSec CSM Leader |
Medium | Issue(s) impact a customer's ability to deploy or use the product, risking current adoption and renewal. | Weekly to Bi-weekly | Global/PubSec CSM Leader |
Low | Issue(s) impacting a customer's ability to deploy or use the product, risking customer value realization, timeline, customer satisfaction, and adoption levels. | Standard Communication | Regional CSM Manager, Account Manager |
Based on the level of the escalation, the DRI for the escalation will be:
At the beginning of the escalation, the DRI must be determined - the DRI owns the following responsibilities and key steps:
The DRI is responsible for managing the account engagement (not the ticket), including:
Management of internal team and customer meetings for follow-up activities.
Support Engineering is responsible for:
Technical Support is ultimately accountable for driving resolution to the support case, including escalation to Engineering, Security, and/or Infrastructure teams. Incident escalation processes should be leveraged for a single incident / support case.
The following steps are to be taken by the escalation DRI:
Immediately
#escalated_customers
on SlackCritical and High Escalations only
Within 24 hours
Ongoing
This channel will remain open until the escalation is closed and should be listed in the escalation document. Name the channel #esc_customername (must start with #esc_ to be included in our data retention policy) and ensure it is a public channel so that relevant parties can be easily added/find the channel. Some more tips & tricks for opening and managing the temporary slack channel can be found below:
If a Critical or High-Level escalation has been created, CSMs should create an escalation document using the Escalation Tracker Template (internal GitLab access only).
Copy and save the document for the individual customer and replace (CUSTOMER) with the customer name, complete the required fields
Set up and document an internal standup cadence series while the escalation is running and put the details in the tracker doc
During the internal cadence, be sure to note any changes in exit criteria or DRI.
Make sure you write down the initial ask & needs (to initially make progress) in this escalation, as clearly as possible and add a bookmark to it. You can link to it in the initial message within the escalation slack channel channel. As mentioned, be as specific as possible, as the GitLab exec / management team needs to understand what you are looking for to solve the escalation. For example: - Required skills (Remote EMEA Timezone) - Ability to analyze production logs - Familiarity with large-scale production architecture for GitLab - Ability to understand SQL queries - Familiarity with PostgreSQL, Patroni, PGBouncer
Example message for the event when the escalation is identified and created and you have to post to #escalated_customers
:
If requested, The Section leader of Product is responsible for designating Product Leaders who will be the R&D response DRIs for the escalation. That process is expected to happen in the #a_customername_escalation channel with a ping to the relevant Product section leader. Example: - This is a newly escalated customer, and we are looking for you to assign a Product Leader to be the R&D DRI for the response.
To keep noise to a minimum, posting in #escalated_customers
should happen only at key moments:
The #escalated_customers
channel is for awareness only and is not intended to replace the dedicated slack channel created as above, the account or support channels. Leverage the specific escalation channel created for working communications, collaborations and executive updates.
Tips & Tricks:
To close an escalation, a clear alignment between GitLab stakeholders and the customer (including documentation in an issue or email) is required. Both parties need to agree the situation is resolved.
If the customer requests an RCA and the escalation was platform-related, GitLab engineering will lead the RCA and will provide it in writing to the corresponding GitLab DRI, who is managing & closing the escalation.
When the issue(s) related to the escalation are resolved or move into a non-escalated state:
The CSM Manager's responsibility is to ensure that the CSM is familiar with the above process and is actively managing the escalation, including the Slack Channel updates and the management of the escalation doc.
When a customer is in an escalated state, the path to resolution must continue to move forward, with both the internal stakeholders and the customer clear on current actions and next steps. The CSM manager is responsible for ensuring that this forward-motion and clear alignment is present and for stepping in and driving action or alignment where necessary.
See the Support Engineering Guide to Escalations for more specific information on how support manages customers in an escalated state.
Engineering support will usually come via Support Engineering, however it's worth noting that under some conditions Engineering / Product may prioritize bug fixes and feature requests related to an escalation.