Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Support Team Handbook

Welcome to the GitLab Support Team Handbook

The GitLab Support Team provides technical support to and Self-Managed GitLab customers. The GitLab Support Team Handbook is the central repository for why and how we work the way we do.

If you are a customer or advocating for a customer who needs technical assistance, please take a look at the dedicated Support Page which describes the best way to get the help you need and lists GitLab's paid service offerings.

If you are a GitLab team-member looking for some help, please see the Internal Support for GitLab Team Members page.

If you are a new Support Team member looking to get started, please take a look at the onboarding section.

Know someone who might be a great fit for our team? Please refer them to the job descriptions below.

On this page

What does the Support Team do?

We care for our customers

How we measure this

We use the below Key Performance Indicators (KPIs) to keep track of how well the Support team is doing as a whole.

The KPI measurements can be found under the Reporting tab in Zendesk. Progress on meeting these KPIs is also tracked in the Zendesk Support Dashboard in Periscope.

We review these KPIs weekly in the Support Week-in-Review.

Service Level Agreement (SLA)

GitLab Support commits to an initial substantive response in a specified amount of time from the time the customer submits a ticket. The SLA for this first reply is based on each customer's support plan.

The target is that we meet the Priority Support SLA for the first reply 95% of the time. The definition of the KPI is:

Number of Times SLA met / Total Tickets where the SLA was applicable

This calculation currently includes only tickets submitted by customers with our top support plans (Premium/Ultimate for Self-Managed and Silver/Gold for and is usually calculated by calendar month.

Support Satisfaction (SSAT)

SSAT is a measure of how satisfied our customers' are with their interaction with the GitLab Support team. This is based on survey responses from customers after each ticket is solved by the Support team using a Good or Bad rating.

The target is 95% satisfaction with their support experience, as measured through Zendesk surveys. The definition of the KPI is:

Satisfied [total good scores]  / Total Survey Responses [good scores + bad scores]

This calculation excludes cases where a survey was not offered or where it was offered but no score was provided.

SSAT can be found on the Engineering KPIs Dashboard in Periscope.

Support Team Business Drivers

GitLab uses business drivers to forecast long-term financial goals by function. Forecasting is an iterative process and we will continue to introduce complexities and variables over time.

Within Customer Support specifically, we look forward to building out a regional gearing process, as well as addressing US Federal and language staffing needs.

Ticket information comes from Zendesk, which headcount information comes from Bamboo HR. The support team includes everyone in the Customer Support department in BambooHR, including Managers and Directors.

Customer Support Gearing Ratios

Customer Support Margin

We target our headcount and non-headcount expenses to be 10% of ARR:

Total Customer Support Team Expenses / Monthly Exit ARR

Customer Support Operating Expenses

Customer Support Team Expenses are all expenses from Netsuite where the department name is Customer Support.

Support Team members can contribute towards this in the form of efficiency gains. For example:

Average monthly tickets per Support Team member

The Gitlab support team aims to staff the team based on weighted average of both self-managed and tickets closed in a given month by an individual support team member involved in customer tickets:

Total number of tickets closed / Total number of support staff

We target to have an average of 65 tickets closed per support staff per month.

Individual contributor to manager ratio

The Manager to IC Ratio is the ratio of individual contributors to one manager. The long term target for this metric is 10:1. This data comes from Bamboo HR.

The first iteration of gearing ratios can be found in the Support Group Gearing Ratio model on the Ticket Gearing Model tab.


The overall direction for Support in 2019 is set by our overall strategic objectives, with a particular emphasis on

As can also be inferred from our publicly visible OKR page, we anticipate 2019 will focus on the following elements:

Ticket deflection through documentation

  1. By building up a corpus of documentation informed by real-world problems we can ensure that customers can get the answers they need before they come into the queues.

    • When learning, use the docs.
    • When troubleshooting, use the docs.
    • If something is missing, update the docs.
  2. By developing a docs-first approach to answering, we can ensure that the documentation remains a highly useful single source of truth, and that customers are more aware of where to find content on their own.

    • Always respond with a link to the docs.
    • If docs content is missing, create it and link the customer to the MR.

Beyond this work during specific support cases, the team is also asked to contribute their expertise to GitLab's documentation by producing new guides and videos that would be useful to our users — especially on emerging DevOps trends and use cases.

Increase capacity & develop experts

In the past 3 years we expanded the support team significantly, and this trend will continue in 2019. As GitLab – the product – continues to expand, so will the skill and knowledge of all Support Engineers to be able to continue providing an excellent customer support experience.

  1. Develop "Deep Dives", Bootcamps and other professional training programs to decrease the time it takes for a new team member to be effective.
  2. Make sure that professional training sessions result in the production of publicly consumable resources: docs fixes, tutorials and improvements to any related material.

Experiment with support model

In late 2018 we moved from a "product-first" model to a "region-first" model. While this has affected the reporting structure, the lines of work from the perspective of an individual Support team member continue to be aligned to product. In 2019 we want to experiment with a "concept-first" model of support that will align individual strengths with customers needs regardless of which queue they come into.

Other areas we'd like to explore:

  1. 24x7 capability beyond uptime support (i.e. weekend staffing)
  2. Language support
  3. US-only Federal Support

Hazards & Challenges

Team morale suffers

Hazard Commitment
Ticket volume is too high Build (and adjust) hiring model based on the best data available, hire as quickly as possible while keeping quality up.
Team knowledge doesn't match ticket difficulty Develop training materials, provide time for professional development, encourage specializations.
We aren't hitting our SLOs Hire and train as per above. Add regularity to scheduling and encourage efficient work patterns.
Leadership breaks trust Communicate in public channels, alert early and often of potential discussions, engender the GitLab value of Transparency.
Fear of conflict results in poor decisions Provide focus on meta-issues by triaging issues in the Active Now board. Encourage buy-in and bravery. Truly listen and respond. Explicitly overrule: state reasoning and thank everyone for voicing opinions.
Team lacks commitment to results or implementing decisions Ensure voices are heard. Re-enforce "disagree and commit". Build accountability.
There's no accountability in poor results or not meeting commitments Reinforce GitLab value of Results by paying attention and following up.
Lack of trust as the team grows Make an intentional effort to frequently do pairing sessions between regions.


As we continue to increase in size, there's a number of challenges that we need to address and/or questions we need to answer:

As we grow:

  1. What process inefficiencies do we need to address? (e.g. Do all engineers need to know about every component/configuration/deployment strategy of GitLab, or are there ways we can specialize?)
  2. Which process inefficiencies do we need to intentionally keep because of a positive externality? (e.g. Do we keep around a synchronous meeting because it helps build relationships?)
  3. What have we lost in scaling? How can we build it back in in a way that scales? (e.g. Smaller groups lead to more ideation sessions, how can we make sure we're creating spaces for ideas to build off of each other?)
  4. How can we make sure we're broadcasting things appropriately so no one misses out on an important piece of information?


The GitLab Support Team is part of the wider Engineering function. Be sure to check the communications section in the Engineering handbook for tips on how to keep yourself informed about engineering announcements and initiatives.

Here are our most important modes of communication:


We use the following groups to notify or add support team members to issues and merge requests on

Group Who
@gl-support All support team members
@gitlab-com/support/managers All support managers


Our team projects and issue trackers can be found in the Support parent group. Here are some selected projects which are relevant to team communications.

Project Purpose
support-team-meta General conversations around support at GitLab
support-training Pairing sessions, onboardings, and anything the support team uses to level up
feedback Collects SSAT survey responses from Zendesk in the form of issues
support-operations Support Operations team project
Support team meta issue tracker

We use the Support meta issue tracker for tracking issues and creating issues that may require feedback around support.

If you're interested in working on a project or task related to support feel free to create an issue and link to any external issues or projects so that we can:

Issues regarding documentation or features for GitLab CE, EE or any of the GitLab components should not go in this issue tracker, but in their appropriate issue tracker.

If you have a proposed solution that is actionable, it's best to start a merge request, tag the team for feedback and link in the Support Week in Review.


We follow GitLab's general guidelines for using Slack for team communications. As only 90 days of activity will be retained, make sure to move important information into the team handbook, product documentation, issue trackers or customer tickets.


Channel Purpose
#support-team-chat Support team lounge for banter, chat and status updates
#support_gitlab-com Discuss tickets and customer issues
#support_self-managed Discuss self-managed tickets and customer issues
#support-managers Discuss matters which require support managers' attention
#spt-hiring Discuss support team hiring-related matters

User Groups

Group Who
@support-dotcom Support Team
@support-selfmanaged Self-managed Support Team
@support-team-apac Support Team APAC
@support-team-emea Support Team EMEA
@supportmanagers Support Managers

If you need to be added to one or more of these groups, please open an issue in the access requests project.

Google Calendar

We use the following team calendars to coordinate events and meetings:

If you need access to these calendars, ask a support team member for help.

Weekly Meetings

The Support Team has several meetings each week. These allow us to coordinate and help us all grow together. Each meeting has its own agenda and is led by a different member of the team each week.

Discussion are encouraged to be kept in issues or merge requests so the entire team can collaborate, regardless of time zone.

Any demos or announcements that need to be shared with the entire team should be shared in the Support Week in Review.

Weekday Region Meeting Name Purpose
Tuesday APAC Support Call Discuss metrics, demos, upcoming events, and ask questions
Tuesday AMER Casual Catch up Agendaless, a space for the team to banter and chat. If you have work to talk about, feel free.
Wednesday AMER,EMEA Dotcom Support Call support team meeting to discuss metrics, demos, upcoming events, and ask questions
Thursday EMEA Support Call Discuss metrics, demos, upcoming events, and ask questions

The regions listed above are the regions for which each call may be the most convenient, but all are welcome on any call. Every call is recorded and notes are taken on the agenda for each one. If you miss a meeting or otherwise can't make it, you can always get caught up.

All Zoom and agenda links can be found on the relevant calendar entry in the Support Calendar.

Past recordings of our meetings are available on Google Drive.

Role of the Chair

The main role of the chair is to start the meeting, keep the meeting moving along, and end the meeting when appropriate. There is generally little preparation required, but depending on the meeting, the chair will include choosing a "feature of the week" or similar. Please check the agenda template for parts marked as "filled in by chair."

During the meeting, the chair:

If a chair is not available, it is their responsibility to find a substitute.

Role of the Notetaker

The notetaker should take notes during the meeting and if action is required, creates a comment and assigns it to the appropriate person.

If the notetaker is not available when it is their turn, they should find a substitute.

Support Week in Review

Every Friday, we do a week in review, inspired by the greater Engineering organization week in review. You can add topics any time to the support week in review google document.

Any workflow changes or announcements should be shared in the SWIR and we recommend you check at least once a week to stay up to date on recent changes. Ideally, the information shared here should have a permanent location such as an issue or merge request.

We encourage anyone in the team to share. We currently have the following topics:

On Fridays at 3pm EST, slackbot will remind the team with a link to the week in review and we can use a thread there for banter. Bear in mind that chat older than 90 days will no longer be retained.

You can read about how we got this started in this issue.

Support Stable Counterparts

As a result of our direct interactions with customers, the Support Team occupies a unique position in GitLab where we can connect project managers with the feedback they need to prioritize. Each of the DevOps Stages should have an IC counterpart, and each section should have a manager counterpart.

Support Stable Counterparts, briefly, will:

Managers will:

If you're interested in becoming a stable counterpart for a group, please create an MR on data/stages.yml and source/inclues/product/_categories.erb and assign to your manager.

At writing (Q2-FY20) ICs align to Stage/Product Manager rather than group to keep things easier for PMs. Put another way: if the same product manager is in charge of multiple groups in a Stage we will not consider assigning an additional stable counterpart.

Cross Functional Meetings

Some functions don't fit as cleanly into the Support Stable Counterparts model. As such we have standing meetings across functions to help surface issues and smooth the interface between such groups.

If you're missing from this list (and want to be on it) please let the Support Managers know in #support-managers

If you're on the Support Team and have something you'd like to surface, or would like to attend one of these meetings, feel free to post in #support-managers.

Section Group Group Contact Support Manager Support Counterpart Frequency
UX UX Christie Lenneville Lyle Kozloff Cynthia Ng weekly team meeting
UX Docs/Tech Writing Mike Lewis Tom Atkins Cynthia Ng & Drew Blessing N/A
Production .com Infrastructure Dave Smith Lyle Kozloff Vlad Stoianovici every 2 weeks
Security Abuse Roger Ostrander Lyle Kozloff TBD N/A
Security Security Operations Jan Urbanc Lyle Kozloff TBD N/A
Performance Performance Stan Hu Lee Matos Cindy Pallares N/A
Legal Legal Jaimie Hurewitz Lyle Kozloff N/A N/A
Finance Budget Chase Wright Tom Cooney N/A 1x Qtr on budget + once per month
Finance Accounts Cristine Tomago TDB N/A N/A
PeopleOps Recruiting Cyndi Walsh Tom Cooney N/A weekly
PeopleOps After-hire care Jessica Mitchell Tom Cooney N/A every 2 weeks
Sales Sales TBD Tom Atkins N/A weekly on Fri join EMEA scrum
Sales Customer Success Kristen Lawrence Tom Atkins N/A weekly on Fri join EMEA scrum
Sales Community Relations David Planella Tom Atkins N/A N/A
Meltano Meltano Danielle Morrill Jason Colyer TBD N/A


Support Workflows

Zendesk Instances

At GitLab, the Support Team currently manages 2 different Zendesk Instances:

All our Support Agents and Engineers have access to the GitLab Support Instance, whereas only Support Engineers who are US Citizens have access to the GitLab US Federal Support Instance.

Time Off

The Support Team follows GitLab's paid time off policy. However, do note that if a large number of people are taking the same days off, you may be asked to reschedule. If a holiday is important to you, please schedule it early.

In addition to the tips in Communicating Your Time Off please also:

If you do not have access to the Support - Time Off team calendar, please raise it in the #support-team-chat channel on Slack and someone will share it with you.

You do not need to add time-off events to the shared calendar if you'll be gone less than half a day. Do consider blocking off your own calendar so that customer calls or other meetings won't be scheduled during your time away.

If you need to go for a run, grab a coffee or take a brain break please do so without hesitation.

Linking PTO Ninja to your personal and team calendar

  1. In Slack, click the + sign next to 'Apps' at the bottom of the left sidebar
  2. Search for 'PTO Ninja' and click 'View'
  3. Type 'help' and press enter
  4. PTO Ninja will reply with some options. Click 'Settings'
  5. In the dropdown next to 'Here are your profile settings:' choose 'Calendar'
  6. Under 'Your synced calendar' click the button to sync your personal calendar
  7. After your personal calendar is linked, click 'Add calendar' under 'Additional calendars to include?'. The 'Support - Time Off' calendar ID is


What if I Feel Threatened or Harassed While Handling a Support Request?

Just as Support Team are expected to adhere to the Code of Conduct, we also expect customers to treat the Support Team with the same level of respect.

If you receive threatening or hostile emails from a user, please create a confidential issue in the GitLab Support Issue Tracker and include:

  1. A history of the user's communication
  2. Relevant links
  3. Summary of the high-level issues
  4. Any other supporting information

Include your Manager, Director of Support, Abuse Team and Chief People Officer in this issue. Together we will evaluate on a case-by-case basis whether to take action (e.g. ban the user from the forums for violating the Code of Conduct).

Improving our processes - 'Active Now' issue board

The Support team use 'support-team-meta' project issues to track ideas and initiatives to improve our processes. The 'Active Now' issue board shows what we're currently working on. It uses three labels:

  1. Blocked - waiting for another team or external resource before we can move ahead
  2. Discussing this week - under active discussion to arrive at a decision
  3. In Progress - actively being worked on

Some principles guide how these labels are used:

  1. A maximum of six issues at any time for each label (18 total issues)
  2. All issues with one of the above labels must be assigned to one or more support team members
  3. All issues with one of the above labels must have a due date no longer than a week ahead
  4. If an issue is too big to complete in a week it should be split into smaller parts that can be completed in a week (a larger 'parent' issue is OK to keep in the project, but it shouldn't make it onto the 'In Progress' column)

Each week we look at the board and discuss the issues to keep things moving forward.

By keeping a maximum of six issues for each label, we limit work in progress and make sure things are completed before starting new tasks.

Adding and managing items on the board:

Support managers will regularly review the board to keep items moving forward.

  1. The team can vote on issues not on the board by giving a 'thumbs up' emoji so we can see popular issues.
  2. Support managers will look at popular issues and add them to the board when there is room.
  3. Support managers will curate issues to prevent a large backlog. Unpopular or old issues can be closed / merged to keep the backlog manageable.

Support Resources


Internal tools

External tools