- Consider the baseline metrics as minima to be achieved each week
- When you don't meet a baseline, you and your manager should discuss in your
next 1:1 meeting to determine what changes you should make, if any
- We believe in quality, not quantity. More is not necessarily better. GitLab
gives you freedom to choose and trusts you to use good judgment in
exercising that freedom as you make daily decisions about
[Prioritizing work](#prioritizing-work).
The ticket baseline helps you and your manager gauge your ticket work over time relative to the rest of the global Support team. It is made up of two primary metrics:
1.**Weekly ticket baseline**– the number of new tickets you provide a first substantive response to each week, per ticket type (Self-managed, SaaS, SaaS Accounts, L&R). The current weekly first‑response baselines are defined in the Working on tickets → How many new tickets should I pick up each week? section.
1.**Median Time to Resolve (TTR/MTTR)** – measured as MTTR excluding time with R&D, with ticket‑type specific targets defined in the Median TTR dashboard and the FY26 Support Engineer Performance Indicators:
- Median TTR – Self‑Managed: target 141 hours
- Median TTR – SaaS: target 76 hours
- Median TTR – SaaS Account: target 25 hours
- Median TTR – L&R: target 7 hours
These targets are surfaced in the [Managers Dashboard](https://gitlab.zendesk.com/explore/dashboard/3FEA996E9CA8CFAFE0031C6FF90CF0A6748043995DEB61F6C2A31A347F18AB5C/tab/44791522) and are aligned with the [Median TTR dashboard](https://gitlab.zendesk.com/explore/studio#/dashboards/5CB98A840DDD3FFF1A274944BCC070229D377C1D23901AF90988FBD0CA79C706) and the [Support Engineer Performance Indicators FY26 issue](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6635#note_2498022715).
To keep comparisons fair across the team, our dashboards use dynamic baselines equal to 85% of the team‑wide mean for each metric. In practice, you should:
- Aim at least to meet, and preferably to exceed, the weekly assigned tickets baselines for the ticket types that apply to your role.
- Aim to keep your personal median time to resolve at or below the ticket‑type specific TTR/MTTR targets above, taking into account the complexity and mix of your tickets.
Treat these baseline values as minimums to be achieved over a reasonable period (for example, several weeks), not hard quotas to be hit every single week. When you don’t meet one or more baselines, you and your manager should discuss this in your next 1:1 and decide what, if anything, needs to change—taking into account factors like escalations, project work, PTO, and the complexity of your tickets. We believe in quality, not quantity. Higher numbers are not automatically better. GitLab gives you freedom to choose and trusts you to use good judgment in
exercising that freedom as you make daily decisions about [Prioritizing work](#prioritizing-work) and balancing ticket volume, resolution time, and depth/quality of customer outcomes.
**Guidance for managers**
Managers should use the combination of weekly assigned ticket baselines and ticket‑type specific median TTR/MTTR targets as the primary quantitative inputs when discussing ticket‑related performance over time, alongside qualitative factors such as ticket complexity, collaboration, documentation work, and customer feedback. Older “baseline” dashboards that are not aligned with these definitions should not be used as the primary performance gauge.
@@ -216,7 +216,17 @@ from the following list for the number of first responses:
| SaaS Accounts | 20 tickets |
| L&R | 15 tickets |
The goal is to ensure fair distribution of tickets across the team. Intermediate and senior engineers excluding those in core L&R and Associate SE roles are expected to develop as well-rounded contributors by consistently working on a balanced mix of SM, SaaS, and Dedicated tickets. These expectations are informed by overall ticket volume, team size, and an average PTO rate of 15%. We continuously monitor ticket volume and staffing levels to ensure these guidelines remain accurate and appropriate. For further details please review the [Support Engineer Performance Indicators FY26 issue](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6635#note_2498022715).
These goals represent the average number of new tickets you should provide a first substantive response to each week for the ticket types that apply to your role. The intent is to ensure a fair distribution of tickets across the team, while still allowing for variation week‑to‑week based on workload, escalations, and project work. Intermediate and senior engineers, excluding those in core L&R and Associate SE roles, are expected to develop as well‑rounded contributors by consistently working on a balanced mix of Self‑managed, SaaS, and Dedicated tickets.
These assigned ticket baselines are one of the two primary ticket‑related baselines for Support Engineers. The second is Median Time to Resolve (TTR/MTTR) with ticket‑type specific targets:
- Median TTR – Self‑Managed: target 141 hours
- Median TTR – SaaS: target 76 hours
- Median TTR – SaaS Account: target 25 hours
- Median TTR – L&R: target 7 hours
These expectations are informed by overall ticket volume, team size, and an average PTO rate of 15%. We continuously monitor ticket volume, staffing levels, and performance indicators to ensure these guidelines remain accurate and appropriate. For further details, including how these baselines are used in performance indicators and dashboards, please review the Support Engineer Performance Indicators FY26 work item, the [Support Engineer Performance Indicators FY26 issue](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6635#note_2498022715) and the [Median TTR dashboard](https://gitlab.zendesk.com/explore/studio#/dashboards/5CB98A840DDD3FFF1A274944BCC070229D377C1D23901AF90988FBD0CA79C706).
**Please Note:** EMEA Support Engineers should follow the [Shift Chair](/handbook/support/workflows/team/shift_chair/) workflow when selecting tickets.
