The GitLab Support Team provides technical support to GitLab.com 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 | Your Need | Where You Should Look |
|---|---|---|
| A customer, or an advocate for a customer | Technical assistance | Public Support Page, which describes the best way to get the help you need and lists GitLab's paid service offerings |
| GitLab team member | Technical assistance | Internal Support for GitLab Team Members page |
| New Support Team member | Onboarding / Learning | Support Engineer Responsibilities page and Support Learning Pathways |
| New Support Manager | Onboarding / Learning | Support Manager Responsibilities page and Support Manager Pathways |
Know someone who might be a great fit for our team? Please refer them to the job-family descriptions below.
Remember, as members of the support team we are the first to interact with someone when they have a problem or question. As such it is up to us to represent the company and make sure we present ourselves properly. Therefore we are expected to:
GitLab Support is part of the Engineering division. While most engineering departments are part of the R&D cost center, Support is part of the Cost of Sales (or sometimes Cost of Goods Sold (COGS)) cost center.
This unique arrangement is expressed in our Key Performance Indicators, which are largely focused around pursuing customer success and satisfaction while driving efficiency by increasing output while keeping costs within a predefined range.
This is also why Support Engineer responsibilities include contributing code and documentation and working alongside Product Managers on our products: By using the knowledge gained from interacting with our customers to make our products or docs better, we solve problems before they become one. This reduces support case load while increasing efficiency for the wider GitLab organization. For example, the Sales department can rely on our docs to answer customer queries instead of leaning on Support or Customer Success for help, freeing up more time to close sales.
If you go through the responsibilties for each role in Support you can piece together how the organization works. We wanted to make a simple clear way to think about how the roles work together to solve problems:
This simple list helps to give an easy way to set expecations and align problem solving in different roles.
We use Key Performance Indicators (KPIs) to keep track of how well each Engineering Department is doing, including the Support team, as a whole.
The KPI measurements can be found under the Reporting tab in Zendesk if you have the appropriate access, but progress on meeting these KPIs is also tracked via the aforementioned KPI link and visually through reports in the Support KPIs Dashboard.
We review these KPIs weekly in the Support Week-in-Review.
The support team has a few elements and we've divided the support handbook as such:
Below we also have some commonly referenced pages:
GitLab team members interested in learning about the GitLab Support team and our responsibilities are encouraged to participate in the Support Shadow Program. The Support Shadow Program is a way that team members outside of Support can spend time shadowing, learning, collaborating, and working together with the GitLab Support team.
To participate in this program, open a Support Shadow Program issue in the support-team-meta project. This issue will be used to organize, plan, and track progress toward this program.
Gitlab Support's vision is to deliver a consistent, exceptional experience to all customers across the globe. Our regional teams will collaborate to deliver on that vision by hiring exceptional talent, developing that talent through quality training, and building standard workflows that provide a smooth experience for engineer and customer alike.
Over the course of fiscal year 2021, GitLab Support worked diligently on our direction to introduce ticket deflection, scaling the team through hiring top talent, building consistent operational excellence through automation, and continued professional development of our Support Engineers and Managers.
The overall direction for Support in Gitlab's fiscal year 2022 will be a focus on KPI achievement while evolving what and how we deliver service to Gitlab customers to support the company's overall strategic objectives, with a particular emphasis on;
As can also be inferred from our publicly visible OKR page, we anticipate FY22 will focus on the following elements:
In the past few years we expanded the support team significantly. Support will prepare for this trend to continue in FY22. 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.
Unlike typical companies, part of the mandates of our Security, Infrastructure, and Support Departments is to contribute to the development of the GitLab Product. This follows from these concepts, many of which are also behaviors attached to our core values:
As such, everyone in the department should be familiar with, and be acting upon, the following statements:
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:
Where we want to ensure that important messages are passed to the global support team, we will use this messaging template. This ensures that these messages are delivered across our communications channels in a structured and documented manner.
We use the following GitLab Groups to notify or add support team members to issues and merge requests on GitLab.com.
| Group | Who |
|---|---|
| @gitlab-com/support | All Support Team members |
| @gitlab-com/support/amer | AMER Support |
| @gitlab-com/support/apac | APAC Support |
| @gitlab-com/support/emea | EMEA Support |
| @gitlab-com/support/dotcom | Support members with primary SaaS focus and GitLab.com admin access |
| @gitlab-com/support/dotcom/console | Support members with GitLab.com console access |
| @gitlab-com/support/customers-console | Support members with CustomersDot console access |
| @gitlab-com/support/licensing-subscription | Support members focused on License and Renewals |
| @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 | Issues to discuss and improve Support processes |
| support-training | Courses and training for Support team including onboarding |
| support-pairing | Record of pairing sessions where we work together on tickets |
| feedback | Collects SSAT survey responses from Zendesk in the form of issues |
| support-operations | Support Operations team project |
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, our FOSS project 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.
When naming channels, "spt" is meant for internal channels, meaning those that will be of use to the Support Team mainly. They should be public so others may join if they choose. If a channel has a "support" prefix, it is meant as a public interface where other teams will interact with the Support Team.
| Channel | Purpose |
|---|---|
| #support_team-chat | Support team lounge for banter, chat and status updates |
| #support_gitlab-com | Discuss GitLab.com tickets and customer issues |
| #support_self-managed | Discuss self-managed tickets and customer issues |
| #support_escalations | Discuss customer/ticket matters which require support managers' attention. Allow other teams to interact with support managers. |
| #spt_managers | Discuss support team internal matters which require support managers' attention |
| #spt_hiring | Discuss support team hiring-related matters |
| Group | Who |
|---|---|
@support-dotcom |
Support Team Members with GitLab.com Admin Access |
@support-selfmanaged |
Support Team focused on Self-Managed tickets |
@support-team-apac |
Support Team APAC |
@support-team-emea |
Support Team EMEA |
@support-team-americas |
Support Team AMER |
@supportmanagers |
Support Managers |
@support-managers-apac |
Support Managers APAC |
@support-managers-emea |
Support Managers EMEA |
If you need to be added to one or more of these groups, please open an issue in the access requests project.
We use the following team calendars to coordinate events and meetings:
gitlab.com_9bs159ehrc5tqglur88djbd51k@group.calendar.google.comgitlab.com_as6a088eo3mrvbo57n5kddmgdg@group.calendar.google.comAdd these calendars to your GitLab Google calendar by clicking on the "+" sign next to "other calendars", and choose "subscribe to calendar". Enter the relevant ID mentioned above. If you need access to these calendars, ask a support team member for help.
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.
Discussions 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 | Support Call | Semi-structured agenda to welcome new members, discuss meta issues, get thoughts on tickets, socialize |
| Wednesday | AMER,EMEA,APAC | Dotcom Support Sync | For anyone interested in GitLab.com customers and processes - rotates day/time through regions |
| 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.
The Support management team meet regularly. Details of these calls are on the Support Managers page
Some regional Support teams have meetings oriented around company news, Support initiatives, training plans, and connectedness.
| Weekday | Region | Meeting Name | Purpose |
|---|---|---|---|
| Wednesday | AMER-E | Weekly News | For team members reporting to Rebecca S |
Senior and Staff Support Engineers are encouraged to host office hours. These office hours are intended to strengthen the team through mentoring. It is up to each Senior/Staff Support Engineer whether they schedule office hours, and how often. Please see the "GitLab Support" Team calendar to view office hours and invite yourself.
We encourage hosts to include what they will cover in the calendar event description and optionally a document to track.
Some ideas of what one can expect at a Senior/Staff Support Engineers'
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.
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.
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:
You can read about how we got this started in this issue.
The Support Team collaborates with many other departments throughout GitLab - Sales, Channel, Product and Legal, to name a few. And we have created two different roles to help those collaborations to be as effective and efficient as possible.
The Support Stable Counterpart role is designed to provide a strong connection between a product team and Support for the purpose of discussing product issues, sharing product knowledge and representing customer needs. If you are interested in becoming a Support Stable Counterpart, or would like to learn more about the role, read the Support Stable Counterparts page.
The Support Liaison role is designed to provide a strong relationship between a non-product team and Support for the purpose of sharing knowledge about each team's work and of developing processes and documentation to allow the two teams to work together well. If you are interested in becoming a Support Liaison, or would like to learn more about the role, read the Support Liaisons page.
The Support Team records our institutional knowledge, processes and workflows in multiple places, such as the handbook and project issues templates. When updating such documents, make sure to have visible artifacts of approval on your merge requests before merging even if you have received approval somewhere else. This avoids the impression of changes being made without any oversight or accountability.
Artifacts of approval can include:
Each Slack channel within Support has a number of Workflows attached to them that are used to provide information to users. The source files for each workflow live in the slack-workflows project.
Some workflows are meant to notify the team of new issues created in the relevant project. In these cases, a project webhook passes information to Zapier, which then sends the information to a Slack workflow.
#support_gitlab-com
#support_licensing-subscription
Providing information by reacting to a message with a specific emoji.
#support_escalations
:escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.#support_gitlab-com
:escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.:leftwards_arrow_with_hook: - Directs the user to post their question in a more appropriate Slack channel.:slack: - Politely asks the user to remove any unfurled link previews in their message.#support_self-managed
:escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.#support_licensing-subscription
:escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.See the Support Time Off page
See the Support Onboarding page
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:
Some principles guide how these labels are used:
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.
The Support Slackbot (archived) has been retired.
