GitLab Support - Escalations

1. You are here:
2. Handbook
3. Support Team Handbook
4. Working With GitLab Support
5. GitLab Support - Escalations

• Overview
• What is an escalation?
• Scope
• Out of Scope
• About Escalations
  • Ticket De-escalation
• Definition of Urgency
• Requesting an Escalation
• Redirecting Escalations (Support Use Only)

Overview

This document outlines the process for managing existing support tickets or internal requests, which, due to business-critical situations, require a resolution faster than what is defined by our normal Support response times.

What is an escalation?

There are two types of escalations:

1. A functional escalation is when the progress of a ticket has stalled, and the ticket needs to be elevated to a more experienced engineer (based on their skill set) so that GitLab can resolve the ticket more quickly.
2. A hierarchal escalation is when management oversight is required to bring structure and focus to a ticket and ensure the necessary resources are allocated to it. This type of escalation typically encompasses the following situations:
   • The SLA of the ticket has been breached by an hour or more.
   • It is a business-critical situation where existing or future business is at risk.
   • The ticket requires immediate intervention to address a high level of customer dissatisfaction.

NOTES:

• For L&R (subscription, plan, renewal, licensing) escalations, please see our Plan/License Escalations Workflow and its decision flowchart.
• Our SLA will cover first responses to tickets.

Scope

The following two types of tickets can be escalated using this process.

1. Zendesk Support tickets from a customer with a license or subscription.
2. Issues in the internal-requests tracker.

Either of these can be escalated if the current course of action is unlikely to provide a positive outcome and meet critical business objectives.

Out of Scope

1. Topics that fall into our general out-of-scope definition
2. Escalating tickets for which there is no acceptable business case provided, requiring the acceleration of a resolution.
3. Add email to org or tickets that are not getting the correct SLA.

About Escalations

GitLab Support targets a 95% SLA achievement KPI. This means that some tickets breaching is expected. Our SLA is for a First Reply but we also internally track the next reply.

Requesting eyes on, asking for an immediate opinion on, or requesting the escalation of a ticket in any Support related Slack channel creates unnecessary stress on Support Engineers who may be in the midst of working on other priority tickets.

Depending on whether you want to draw attention to either a Zendesk ticket or an issue created in internal-requests, follow the steps below.

Zendesk Tickets

1. Review the SLA associated with the account and the amount of time left until a breach by logging into Zendesk using Okta. It's not typically necessary to escalate an issue that is hours away from a breach. If the ticket has had the first reply, then you are looking at an "internal (next reply) breach".
2. Ensure the latest response is from the customer. If the latest response is from us, we're waiting on the customer to reply.

Note: If you do not have Zendesk access, please request a Light Agent account to obtain it.

Ticket De-escalation

Depending on the request the Support Manager on-call will decide that an escalation request is without merit. In these cases, it's important to set expectations with the requester by documenting the following in the escalation issue.

1. Reasons why the ticket doesn't qualify for an escalation.
2. Agreement with requester on an acceptable alternative path.

Every escalation that is de-escalated must include the De-Escalation label.

Definition of Urgency

Urgency Level	Definition
Not Urgent	We need increased visibility on the ticket/issue and a response from Support within the next 2 hours. This escalation is not urgent, and the overall impact is low.
Timely	We need to address potential or existing customer dissatisfaction on the ticket/issue with a response from Support within the next 1 hour. This escalation has a certain level of urgency, and the overall impact is medium.
Urgent	The ticket/issue may become an emergency if no follow-up is provided within the next 30 minutes and may lead to customer dissatisfaction. This escalation is urgent, and the overall impact is high.

Requesting an Escalation

Important The support escalations form will be available during our support hours, outside of these hours the form will be disabled.

The following instructions apply to escalating both Zendesk tickets and issues within the internal-requests issue tracker.

WARNING: When escalating a US Federal case, do not fill in the customer's name, instead populate the Customer field with a link to the organization in SFDC.

1. Go to the Support Escalation Form.
2. Fill out each field. All of them are required.
3. Click Submit Escalation Request.

Once submitted, an issue is created in the Escalations issue tracker. The issue is automatically assigned to the Support Manager on-call and will be used to keep a log of the escalation. Additionally, a thread will be created in the #support_escalations Slack channel.

Please be aware that we take into consideration the current state of the entirety of the ticket queue and already existing escalations when determining the appropriate prioritization for your escalation.

Redirecting Escalations (Support Use Only)

If a request for an escalation is posted in the wrong channel, simply add the :escalate: emoji as a reaction to the post, and the user will be advised of the proper way to request an escalation via a Slack Workflow.