Customer Success Escalations Process

1. You are here:
2. Handbook
3. Customer Success
4. Technical Account Management Handbook
5. Customer Success Escalations Process

Maintained by:

On this page

• On this page
• Objective
• Scope
• Definitions of Severity Levels
• Responsibilities
  • Critical and High Level Escalations
  • Medium and Low Level Escalations
• Escalation Tracker Template
• How to start an Escalation
• Communicating that a customer is in an escalated state
• Support Engineering's role in Escalations
• Related Links

View the TAM Handbook homepage for additional TAM-related handbook pages.

Objective

Define the process for managing account escalations and define framework for communications, activities and expectations for customer escalations.

Scope

This addresses critical and high escalations for Enterprise customers. This can also apply to Commercial or SMB customers if there is a strategic partnership or relationship. This can also be leveraged for issues that affect a broad number of customers though the customer engagement model will differ. Any GitLab team-member can escalate an account on behalf of the customer.

Definitions of Severity Levels

• Cadence refers to the cadence of internal and external meetings and communications to the customer.
• Level of involvement defines scope of internal communication and awareness. Others can be included based on the type of issues involved.

Responsibilities

Critical and High Level Escalations

• TAMs are responsible for managing the account engagement (not ticket), including:
  • Management of internal team and customer meetings for follow-up activities. Note: To ensure the TAM does not slow resolution of issues, the TAM doesn't need to be in all meetings (e.g., technical troubleshooting with customer and support/development).
  • Driving and coordinating TAM escalation process internally and with the customer, including associated communications, and executive-level meetings.
  • Developing and maintaining the escalation document and supporting account documents.
  • Acting as an escalation point for customer-related issues (e.g., delayed response, open actions, non-compliance installation or use of the product, etc.)
  • Developing the business case justification and escalation to Product for escalations related to enhancement requests
• Support Engineering is responsible for:
  • Collaborating with technical resources (e.g., Development, Quality Assurance, SREs and Support Engineering staff) to drive resolution of the technical issues
  • Managing the 24x7 incident resolution and escalation process (i.e., Support Engineering, SRE, Development)
  • Supporting executive and customer calls (as needed)

Medium and Low Level Escalations

• Support Engineering is responsible for managing Low and Medium level escalations, leveraging other teams (e.g., Technical Account Managers (TAMs), Engineering) as needed.
• If a TAM is assigned, Support Engineering should inform the TAM of the escalation.

• The TAM is responsible for managing any account-related issues (e.g., delayed response, open actions, non-compliance installation or use of the product, etc.).

• When customer escalation processes are initiated by Support (low and medium) or Customer Success (Medium and High), the escalation document should be posted into the internal-only GitLab Slack channel #escalated_customers.

Escalation Tracker Template

• Link to template (only accessible by GitLab team-members). Save the document for each individual customer and replace (CUSTOMER) with the customer name.

• Executive Summary

  • This section does not need to be updated daily but should be updated when there are changes to the status of the overall engagement (e.g., top-level issue status, milestones, etc.).
  • Milestones should include key customer and GitLab milestones.

How to start an Escalation

It's expected that most escalations stem from emergency tickets to support, but it's possible that a customer could get escalated outside of that context. When an escalation is started, a TAM or a Support Engineering Manager may take these steps to create the doc and the channel depending on whom is initiating the escalation:

• An Escalation Doc using the Escalation Tracker Template will be created if it is a Critical or High Escalation
• A temporary slack room for internal use will be created that will be used for the duration of the escalation. This should be noted in the escalation doc

Communicating that a customer is in an escalated state

• When a customer escalation is defined, the escalation document should be posted into the #escalated_customers channel by the escalation owner (i.e., Support for Low/Medium severity, TAM for high/critical severity escalations). The posting to this channel should occur:
  1. when the escalation is identified and created
  2. when incremental updates are required for executive or management visibility (e.g., daily updates for high or critical escalations)
  3. when the escalation is closed or risk reduced to standard business process to manage (i.e., issue resolved and monitoring the solution)
• The #escalated_customers channel is for awareness only and is not intended to replace account or support channels. Specifically, this channel is NOT intended for:
  • Initiation of escalations
  • The detailed tracking and interactions for the escalation
• The initiation of an escalation and detailed tracking will continue to take place in the account or support channels.

Support Engineering's role in Escalations

See the Support Engineering Guide to Escalations for more specific information on how support manages customers in an escalated state.

Related Links

• Support Engineering Page and Support Engineering Escalation Procedures
• Product Escalation Issue Template to request Product Team support for roadmap / future needs, prioritization of enhancements and/or issues and troubleshooting of customer issues.
• Customer Health Assessment and Account Triaging