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 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 Support Engineer Responsibilities page and the onboarding section.
Know someone who might be a great fit for our team? Please refer them to the job 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.
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 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:
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.
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.
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.
In the past few years we expanded the support team significantly, and this trend will continue. 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.
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:
| 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:
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 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 GitLab.com admin access |
| @gitlab-com/support/dotcom/console | Support members with GitLab.com console access |
| @gitlab-com/support/customers-console | Support members with Customers Portal 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.
| 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_managers | Discuss 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 | 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,APAC | Dotcom Support Sync | For anyone who is interested in (or has a point of interest for) those who work with GitLab.com customers and processes - rotates 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.
Past recordings of our meetings are available on Google Drive.
The Support management team meet regularly. Details of these calls are on the Support Managers page
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:
On Fridays at 3pm EST, Support 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.
As a result of our direct interactions with customers, the Support Team occupies a unique position in GitLab that gives us the opportunity to connect product managers with customer feedback. To take advantage of this opportunity, we've adopted a model that is known within GitLab as "Stable Counterparts." In brief, a "stable counterpart" is an assigned, permanent contact for a GitLab Team Member within another function in the company. See the Stable counterparts item on the Leadership page, and An ode to stable counterparts for more information.
How do we align Support Team people to the product?
Support Stable Counterparts, briefly, will:
Managers will:
If you're interested in becoming a stable counterpart for a group, please create an MR to add your name under 'Support' for the relevant team on data/stages.yml and add your name to the list on the source/includes/product/_categories-names.erb file, then assign to your manager.
There's a video on google drive (internal link) with some discussion on how to perform the role.
Tips:
Some functions don't fit as cleanly into the Support Stable Counterparts model. As such we have support counterparts for non-product areas 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 & Greg Myers | weekly team meeting |
| 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 | N/A | N/A |
| Legal | Legal | Robin Schulman | 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 | Greg Myers | weekly team meeting |
| Meltano | Meltano | Danielle Morrill | Jason Colyer | TBD | N/A |
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 by reacting to their message with a specific emoji. The source files for each workflow live in the slack-workflows project.
#support_managers
: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.When working on merge requests for code or for documentation, apply the
support-fix label so that we can track product contributions by support team
members. An issue is created in the support-team-meta issue tracker at the
end of each week with a list of support fixes merged in the past week. View the
list of summary issues here.
At GitLab, the Support Team currently manages 2 different Zendesk Instances:
The customer URL for the Federal Support Instance is federal-support.gitlab.com which is a CNAME for gitlab-federal-support.zendesk.com
All our Support 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.
A collection of best practices and suggestions for styling and responding to Zendesk tickets.
See the Support Time Off page
See the Support Onboarding page
Just as Support Team are expected to adhere to GitLab's Code of Conduct, we also expect customers to treat the Support Team with the same level of respect. The GitLab Community Code of Conduct outlines the standards to which we hold the wider GitLab Community.
If you notice a threatening or hostile ticket, please tag the Manager On-Call to respond with the following guidelines in our Statement of Support.
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 can be used to quickly view the status of our ZenDesk queues.
Below are the most common commands, the bot's repo has additional details.
sb p # All queues
sb sm # Self-Managed queues
sb s # GitLab.com queues
json_stats (analyze JSON logs), strace_parser (analyze strace output), gitlabsos (get all logs and other data from customers), etc.