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:
Our goal is to provide guidance that will lead to the best results for our customers as they use GitLab. In that, we will often point to documentation, product functionality, or open bugs/feature requests. However, there are times when customers will be best served through one of our commercial offerings.
Support is part of the Engineering Department and Support Engineers are not comissioned or bonused for upsell for additional services, customer purchases, or lead generation. If you recommend Professional Services or moving to a different tier or offering you may link to this section in your recommendation to give the customer assurance you're doing so with no mixed motivations.
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.
Part of Support's role is to amplify the voice of the customer. One way of doing this is inviting other GitLab team members into experiences that will help them understand customer challenges with the product or our own obstacles in helping customers overcome those challenges.
Before you start, make sure you get light-agent access in Zendesk so that you can view Support tickets.
If you're looking to get more exposure to customers, there are a few ways to get involved with Support:
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.
If you're not part of the Support team and you'd like 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 uses Calendly to facilitate scheduling Shadow pairing sessions with participants. If you're part of the Support team and you'd like to volunteer to host Support Shadow Pairing sessions with folks outside of Support, please open a Schedule update request issue requesting that Support Ops add you to the Support Shadow Program Calendly rotation.
Support calls are published on the GitLab Support Calendar. There are:
https://gitlab.zendesk.com/agent/tickets/<id> to view the ticket.A great way to get involved is to join a customer emergency call. You can monitor #support_self-managed for PagerDuty alerts. Alternatively,
if you have access to PagerDuty you can be scheduled into a shadow rotation.
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.
In service of achieving our KPIs and OKRs, there are three key pillars that we must balance to achieve success:
At various times it's easy to over-optimize on one of the pillars to solve a problem, but considering all three is key to avoid short-sighted decision making.
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 Support's vision is to deliver a consistent, exceptional experience to all customers across the globe. Our Support Global Groups will collaborate and act as one team to deliver on that vision by continuing to strengthen and scale the team while delivering the results our customers care about the most.
The overall direction for Support in FY24 will continue building from the foundations laid in FY23. We will continue to focus on KPI achievement and evolve our approach to support. Following on to the company's overall strategic objectives, specific areas of focus are:
While our publicly visible OKR page and Key Performance Indicators reflect the focus and progress for the current quarter, the following provides more detail on the items included in the themes for the entire FY23.
The expansion of our customer base, in tandem with the expansion of our Global Support team, continually presents an opportunity to revisit many aspects of our daily work. As some customer segments grow, we have the specific opportunity in FY24 to look for tailored offerings or specialized workflows to meet the needs of those segments. In FY24 we will:
The Support Team, Product areas and requirements of our customers continued their trend of growth and complexity in FY23. To support this growth and added complexity, in FY24, there will be a focus on keeping the team oriented toward performance and efficiency. This year, we will:
The continued growth of the support team provides an opportunity to review how best to deliver results to our customers. This will include both looking towards new support offerings and ensuring our existing offerings contribute towards GitLab value-proposition. As we strengthen the team, we also need to look towards a larger scale. In FY24 we will:
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:
We sometimes get questions like "Why doesn't GitLab support use Service Desk?" citing our dogfooding operating principle.
Dogfooding is using a piece of GitLab for its intended purpose. For example, one could use GitLab issues as a newsletter (and we do! See: Support Week in Review), but creating merge requests to help Issues serve as a newsletter more effectively wouldn't be dogfooding unless that improvement also helps its core use case.
In other words: Dogfooding is using the product in the way that our customers would use it to the end of discovering and solving pain points that they have. Dogfooding supports customer results.
At GitLab Support we use Service Desk to process Personal Data Requests, but not for our global support because the customer for Service Desk is primarily small teams soliciting bug reports, feature requests, or general feedback. Through our use of Service Desk in this smaller setting we've been able to influence product direction towards adding features like internal notes.
We continually evaluate product features for use-cases within Support and provide feedback and feature requests where blockers exist. Support will always prioritize customer results over any other consideration.
These were previously populated via a tool we are no longer using. TODO: Replace with current GitLab implementation
These were previously populated via a tool we are no longer using. TODO: Replace with current GitLab implementation
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 |
| @gitlab-com/support/managers/amer | All AMER support managers |
| @gitlab-com/support/managers/apac | All APAC support managers |
| @gitlab-com/support/managers/emea | All EMEA 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 |
| support-readiness | Support Readiness 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.
The "spt_gg_" prefix is used for Support Global Groups internal channels.
The SGG Slackbot's Daily Stand-up posts at the commencement of each region's Support Hours regularly, in a number of channels to advise global groups of different information. For further details of the different variations, please refer to the SGG handbook page of the group you are curious about.
| 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_licensing-subscription | Discuss Licensing & Renewals tickets and customer issues |
| #support_escalations | Discuss escalated tickets with the Support Manager On-Call |
| #support_operations | Discuss operational items related to how Support works |
| #spt_managers | Discuss support team internal matters which require support managers' attention |
| #spt_hiring | Discuss support team hiring-related matters |
| #spt_pairing | Used when working together on tickets and issues |
| #spt_us-federal | Discussion about topics pertaining to US Fed Support |
At GitLab we are to be public by default unless there is a valid reason for it to not be public. While Slack is not public, the spirit of opening up discussions so that everyone can contribute means that private channels should be kept to a minimum.
The following private channels are permanent fixtures in support. Usage estimates are approximate based on traffic in Feb 2022.
| Channel | Who is in it | Purpose | How often is it used? |
|---|---|---|---|
#spt-senior-mgmt |
Senior Managers+ | Used for Senior leadership to discuss and coordinate on sensitive topics / budget / etc. | 3-4 threads per week |
#spt_managers-internal |
Managers+ | Used for sensitive topics that are applicable to managers that aren't appropriate for public channels | 4-5 threads per week |
#spt_managers-internal-apac |
APAC Managers+ | Used for sensitive topics that are applicable to APAC managers that aren't appropriate for public channels | 3-4 threads per week |
#spt_managers-emea |
EMEA Managers+ | Used for sensitive topics that are applicable to EMEA managers that aren't appropriate for public channels | 4-5 threads per week |
#spt_managers-amer |
AMER Managers+ | Used for sensitive topics that are applicable to AMER managers that aren't appropriate for public channels | 1-2 threads per week |
#spt_hiring-mgmt |
Managers+, Recruiting, Finance | Used for coordinating offers and discussing hiring specifics that can be shared in the public channel | 1-2 threads per week |
#fy23_support_promotions |
Managers+, People Business Parter | Used for coordinating and planning promotions in FY23 | 0 threads per week, mostly informational |
#cto_spt_directors |
CTO, Directors | Used for Directors + CTO to discuss and coordinate on sensitive topics / budget / etc. | 3-4 threads per week |
Before starting a new private channel, ask yourself Why can't everyone contribute here? Appropriate answers might be:
Private channels are not appropriate for:
Values are only values if you do them when it is hard. See more discussion on how to scale the business while preserving GitLab Values.
| 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.
Please use the following formats for your name in Zoom as described in adding your title to your name in Zoom. As a primarily customer facing team, these formats were chosen to help identify you by vendor and role in calls where customers are present.
For sub-department, use the smallest unit you belong to. Again, bias for customer understanding over technical correctness.
For example,
| Role | Title Format | Example |
|---|---|---|
| Intermediate Support Engineer | Name | Support Engineer | GitLab |
Luciana de Santos | Support Engineer | GitLab |
| Support Readiness Specialist - Ops | Name | Support Ops Specialist | GitLab |
Barka Adamec | Support Ops Specialist | GitLab |
| Senior Support Engineer | Name | Sr. Support Engineer | GitLab |
Shen Hua Li | Sr. Support Engineer | GitLab |
| Staff Support Engineer | Name | Staff Support Engineer | GitLab |
Jabulani Achebe | Staff Support Engineer | GitLab |
| Support Manager | Name | Manager, Sub-department | GitLab |
Sneha Sharma | Manager, Support Operations | GitLab |
| Senior Support Manager | Name | Sr. Manager, Sub-department | GitLab |
Joo Hee Ko | Sr. Manager, US Federal Support | GitLab |
| Director | Name | Director, Sub-department | GitLab |
Noémie Blanchet | Director, Support Engineering | GitLab |
| Vice President | Name | VP, Department | GitLab |
Kalina Nowak | VP, Customer Support | GitLab |
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.
All Zoom and agenda links can be found on the relevant calendar entry in the Support Calendar..
Support team members in some regions meet up regularly. Details of these calls are on the Weekly Support Team Call workflow page.
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 | EMEA | 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' office hour:
You may wish to host a sync call. To do so, you can create an event on the Support Calendar.. To invite team members to the event, you can use the appropriate Support email alias (internal Handbook, GitLab team members only)
Every Friday, we do a week in review, inspired by the greater Engineering organization week in review. You can add topics any time by using the SWIR topic form.
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.
SWIR::Digest label in the SWIR project.We encourage anyone in the team to share.
We currently have the following topics, each in its own section in the SWIR:
SWIR Issues can also have their own Tags or Labels in the GitLab project. These are used to highlight specific Areas of Focus (L&R, SaaS…). Labels are used on the Issues only, they do not appear in the digest Issue nor in the Google doc.
One label, Manager Attention, is used for policy changes or other topics of
which Support Managers should specifically be made aware. You can find the
Manager Attention label
here]
and subscribe to it.
You can read about the origins of the auto-generated SWIR 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
After getting promoted, make sure to update your title in:
Consider to update the title on slack and on zoom as well, following the guidelines in zoom name format.
In GitLab Support, we have two mechanisms to organize support engineers as they work:
Global groups are organized by managers. Support Pods are engineer-lead. To join or start a Support Pod you can read more below. ``` See the Working with Support Pods page and Support Pods project.
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.