Support Team Handbook

The GitLab Support Team Handbook is the central repository for why and how we work the way we do.

Welcome to the GitLab Support Team Handbook

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.

What does the Support Team do?

We care for our customers

  • Always assume you are the person responsible for ensuring success for the customer.
  • When supporting a customer, any issue, incident or loss is GitLab’s loss.
    • When a customer experiences trouble or downtime, take action with the same urgency you’d have if GitLab were experiencing downtime.
    • When a customer is losing productivity, take action with the same urgency you’d have if GitLab were losing productivity.
    • A customer with 2,500 users whose instance is down, gets the same urgency as if GitLab were losing $1,000,000 per day. This treatment is equal regardless of how much they are paying us.
  • Escalate early. Visibility across GitLab, up to and including the CEO, is always better earlier rather than later. Ensure all resources needed are on the case for customers early.

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:

  • Always be friendly and respectful.
  • Be open to new ideas and points of view.
  • Be OK if you don’t know something. You can always ask someone else.
  • Be comfortable saying no to a customer (but try to suggest a workaround and escalate to a Senior if necessary).

We are not commissioned or bonused

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 commissioned 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.

Our role within GitLab

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.

Building customer empathy

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:

Support Shadow Program

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.

Join Support Calls

Support calls are published on the GitLab Support Calendar. There are:

  • Customer calls between customers and engineers. The description will include a ticket ID. Go to https://gitlab.zendesk.com/agent/tickets/<id> to view the ticket.
  • Pairing sessions between two or more engineers working on one or more tickets.
  • Office hours / Help sessions where more experienced Support engineers share their knowledge.
  • Training sessions where a member of the support team is presenting on a specific topic
Join an Emergency Call

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.

How our team helps fellow team members at all levels – Helping Hierarchy

If you go through the responsibilities 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:

  • Support Engineers help solve customer problems via tickets, merge requests, and other customer facing activities.
  • Managers help solve Support Engineer problems by removing obstacles, joining in on customer facing activities, and working with support engineers to build systems that work to reduce friction and enable results and efficiency.
  • Senior Managers help resolve and avoid scaling problems by addressing team performance to KPIs, prioritizing initiatives and being responsible for the achievement of global results.
  • VP of Support helps resolve and avoid company wide problems, by identifying growth and team design challenges, and reporting on progress to the Executives and Board.

This simple list helps to give an easy way to set expectations and align problem solving in different roles.

How we measure our performance

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.

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

Our Success Pillars

In service of achieving our KPIs and OKRs, there are three key pillars that we must balance to achieve success:

  • People: Continue to hire excellent engineers and managers, at the right time, and the right places. Support our existing engineers and work with each team member towards realizing their full potential through professional development and smart tooling.
  • Process: Iterate on existing processes and develop new, simplified processes that enable global scaling
  • Performance: People understand how their contributions help the global team attain our results, with guidance on what these contributions look like in practice.

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 avoiding short-sighted decision making.

About the Support Team

The Single Source of Truth for information about Support Team Members - everything from email address and personal interests to product skills and group memberships - is the support-team.yaml file. The Support Team Home Page is built from the information in that file. Many other Support tools and automations make use of it also. See the Support team entry page of the Support Team wiki for details of the structure of the file.

Information for and about the different parts of the Support Team can be found in the following sections of the Support Handbook:

  • /support/engineering is content that is for Support Engineers. Think: Zendesk workflows and technical resources.
  • /support/license-and-renewals is content for the Licensing and Renewals Support Engineers and Managers. Think: customers.gitlab.com and working with the Fulfillment Product Team.
  • /support/managers is content that is for Support Managers. Think: how to manage issues, run 1:1s and leadership sync information.
  • /support/readiness is the landing page for Support Readiness. Think: how is the support team preparing for X?
    • /support/support-ops is content that is for Support Operations. Think: how to change Zendesk forms and fields, and other ops details.

Below we also have some commonly referenced pages:


FY25 Direction

GitLab Support’s vision is to deliver a consistent, “delightful” experience to our customers. Our team members will collaborate across all timezones to seamlessly deliver the results our customers care about while continuing to strengthen and scale the team.

The overall direction for Support in FY25 will continue to build from the foundations laid in FY24. We will continue to focus on KPI achievement and evolve and iterate our approach to support, keeping the customer centered in our outcomes. 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 FY25.

Improving our ability to achieve results for our customers

FY24 was a challenging year in many aspects. As the workload and customer expectations grew, we needed to look at how we could improve efficiency and create a differentiated Support experience. FY25 is a year to focus and align on our customer needs and put our customers at the center of our understanding of their situations, perceptions, and expectations. To that end, we will:

  • Iterate our support model, keeping our customer experience and business vision at the forefront of our decision making.
  • Adopt a prioritization strategy incorporating our customers’ business impact and GitLab business need, while building an understanding within the Support team for the why behind it.
  • Examine and shape the macro and micro trends in group performance and individual efficiency.
  • Build a compelling customer digital support experience that will improve the customer journey and reduce toil for our team.

Team structure and how it supports our ability to achieve results

In FY23 / FY24 we moved towards dividing the team into globally distributed groups of engineers. In FY25 we’ll build on that foundation and extend towards differentiating support offerings to better align with customer requirements. This year, we will:

  • Progress enhanced support offerings while partnering more closely with the Customer Success Team to meet our customers’ business needs.
  • Improve how we route and address customer tickets to an appropriate expert with a mind for growing individual engineers from just starting their support journey to complete stewardship of the support journey experience.

Team culture and how it supports our ability to achieve results

As GitLab grows, Support’s influence within the company as advocates for customers must also grow. We need to continue to strengthen the Values-driven cultural attributes that promote efficient collaboration and results for customers while maintaining GitLab Support as a great place to work. In FY25 we will:

  • Build leaders and influencers within GitLab as advocates for customers.
  • Expand our enablement, training, and education to prepare the current and future generations of Support Engineers to meet the needs of our customers.

Delight our customers

FY24 was a year of better understanding the needs of our customers. In FY25 we will focus on delighting them. We will:

  • Pair with our customers and train engineers in setting and exceeding customer expectations.
  • Improve our ways to serve customers and resolve their problems before a ticket is even opened while keeping that context to enrich tickets for Support Engineers if a ticket is needed.
  • Improve our understanding of Support Delivery Quality and how we can consistently provide world class service.

We are also Product Development

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 should all feel comfortable contributing to the GitLab open source project
  • If we need something, our first instinct should be to get it into the open source project so it can be given back to the community
  • Try to get it in the open source project first, rather than later, even if it’s 2x harder
  • We should be using the whole product to do our jobs
  • We are all familiar with our Dogfooding process and follow it
  • We should not expect new team members to join the company with these instincts, so we should be willing to teach them
  • It is part of managers’ responsibility to teach these values and behaviors

Dogfooding in Support

Citing our dogfooding operating principle, people sometimes ask why GitLab Support doesn’t use Service Desk.

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.

OKRs

Current Quarter

These were previously populated via a tool we are no longer using. TODO: Replace with current GitLab implementation

Previous Quarter

These were previously populated via a tool we are no longer using. TODO: Replace with current GitLab implementation

Hazards and Challenges

See Managers/Hazards page

Communications

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:

  • Support Week in Review. Important updates for everyone in support. The SWIR is expected reading/listening for all support team members. You should try to check the SWIR at least once a week. If you have something to share with the entire team this is the best place to do it. For example, if you have an issue for a common bug, an issue that requires feedback, or an issue about an external project you’re working on.
  • Slack channels for “informal” communication. Due to our data retention policy in Slack, things shared there will eventually be deleted. If you want to share something there, please make sure it also has a more permanent place in our docs, handbook, issue tracker, etc.
  • Meta issue tracker for any issues regarding workflows, general team suggestions, tasks or projects related to support, etc.

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.

GitLab.com

Groups

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

Projects

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
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:

  • Be transparent to the entire team what we’re working on
  • Have the opportunity to collaborate on external projects or tasks with other team members who are interested
  • Avoid having team members do duplicate work

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.

Slack

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.

spt_vs. support_ prefix

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.

Daily Stand-up bot

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.

Channels

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_ticket-attention-requests Discuss escalated tickets with the Support Manager On-Call
#support_operations Discuss operational items related to how Support works
#support_leadership 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
Private Channels

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 Partner 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:

  • this channel will be used to discuss material, non-public information that may affect designated insider status.
  • this channel will be used to discuss something that would negatively affect the privacy of an individual or group of individuals, such as performance, compensation or other sensitive matters

Private channels are not appropriate for:

  • Reducing noise (create a new public channel for this)
  • Long-lasting discussions (unless included in the table above)
  • Getting materials ready for public comment

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.

User Groups

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.

Google Calendar

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

Add 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.

Zoom

Zoom name format

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 the sub-department, use the smallest unit you belong to. Again, bias for customer understanding over technical correctness.

For example,

  • Customer Support -> Support Engineering (use Support Engineering)
  • Customer Support -> Support Readiness -> Support Operations (use Support Operations)
  • Customer Support -> Support Engineering -> US Federal Support (use US Federal Support)
Examples
  • 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

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.

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 Call

Support team members in some regions meet up regularly. Details of these calls are on the Weekly Support Team Call workflow page.

Support Leadership Meetings

The Support management team meets regularly. Details of these calls are on the Support Managers page

Support Regional Team Meetings

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 Support Engineer Office Hours

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:

  • Troubleshooting a difficult ticket
  • Trying out a GitLab feature (Geo, CI, SAST, k8s, etc.) or a new workflow
  • Reproducing a particular bug
  • Fixing a bug
  • Creating or updating documentation
  • Thinking through a particular problem
  • Hosting a ticket crush session

Creating a Meeting

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)

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 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.

How to read/listen to the SWIR

  • You can read the Support Week in Review by viewing the more recent issue with the SWIR::Digest label in the SWIR project.
  • You can subscribe to this label to be notified when the latest SWIR has been generated.
  • For audio editions recorded after 2022/07/01, you can find a link to the audio edition of the SWIR within the respective issue (this is so we comply with the SAFE framework. An archive of all audio editions can be found in the Support Week in Review - Audio Edition folder on Google Drive (internal only).

We encourage anyone in the team to share.

SWIR Topics

We currently have the following topics, each in its own section in the SWIR:

  • Actionable. For items that require a decision to be made or action to be taken (such as, asking for feedback on an issue).
  • Things to know about. Share items that you would like to share with the team, like projects you’re working on, known bugs, new workflows, cool articles you found, etc.
  • Team Member updates. New team members, internal transfers and nother news about our team members!
  • What Did we Learn this Week. A space to share things you’ve discovered (or rediscovered!) and learnt.
  • Support Operations Corner. Announcements and information from the Support Operations team
  • Kudos. Give a special kudos to other team members or highlight something they did. -SSAT. A selection of the positive SSAT feedback received from customers during the week
  • Metrics report. Review the support metrics for the span of the week.

SWIR Labels

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.

Cross-Department Roles

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.

Support Stable Counterpart

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.

Support Liaison

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.

Processes

Updating Support Team documents using merge requests

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:

  • Getting a peer or manager to review and merge your MR
  • A peer or manager showing their approval using MR approvals
  • A peer or manager commenting “looks good to me”

Support Workflows

Slack Workflows

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.

Issue Notification

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.

Emoji Reaction

Providing information by reacting to a message with a specific emoji.

  • #support_escalations
    • Ticket Escalation - :escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.
  • #support_gitlab-com
    • Ticket Escalation - :escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.
    • Question Redirect - :leftwards_arrow_with_hook: - Directs the user to post their question in a more appropriate Slack channel.
    • Remove Link Preview - :slack: - Politely asks the user to remove any unfurled link previews in their message.
    • Welcome - This automated workflow automatically sends a direct message to new members of the channel that contains helpful information.
    • Contact Management - :admission_tickets: - Direct the user to follow the proper procedure to manage the support contacts for a Zendesk Global organization.
  • #support_self-managed
    • Ticket Escalation - :escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.
  • #support_licensing-subscription
    • Ticket Escalation - :escalate: - Directs the user to follow the proper procedure to escalate a support ticket or internal issue.

Time Off

See the Support Time Off page

Onboarding

See the Support Onboarding page

Promotion

After getting promoted, make sure to update your title in:

Consider updating the title on Slack and on Zoom, following the guidelines in Zoom name format.

Support Pods

In GitLab Support, we have two mechanisms to organize support engineers as they work:

  • Support Global Groups: A cross-region, cross-skillset group of engineers that coordinate on issues and hand off tickets"
  • Support Pods: A cross,region, single skill group of engineers that are experts or soon to be experts on that specific product area.

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.

Improving our processes - ‘Active Now’ issue board

The Support team uses ‘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 Slackbot

The Support Slackbot (archived) has been retired.

Support Resources

Documentation


Advanced Support Topics
Training modules that Support team members can complete to gain expert skills.
Customer Support Department Performance Indicators
Displays Support KPIs, pulled from full list of company performance indicators.
GitLab Support On-Call Guide
For customers that have Priority Support, the Support Engineering Team is on-call and available to assist with emergencies
Gratis Support for Prospects
Details on how to request support for prospects
Licensing & Renewals
Licensing & Renewals (L&R) comprises efforts to resolve problems customers face when they purchase or renew their GitLab subscription.
Partnerships
Support specific information on partnership's workflows, automations and processes.
Providing Excellent Customer Service
Guidance for delivering a great experience to our customers
Readiness Team
Everything you wanted to know about the Readiness sub-department
Requesting Gratis Support
Details on how to request gratis support for customers and prospects
Support Channels
Communication channels for GitLab Support
Support Engineer Career Path
The details of this page are to outline more specific guidance around promotions for Support team members. Page should not be moved without a Support Global Change Management issue.
Support Engineer Resources
If you want to learn more about what support engineers do and how they do it, this is the place.
Support Engineer Responsibilities
A detailed listing of the responsibilities of Support Engineers in GitLab. Page should not be moved without a Support Global Change Management issue.
Support Engineering Data Analysis Community
Purpose This page serves as the cornerstone for a Support Engineering data analysis community of practice. Support team members who engage in any form of data extraction and analysis, either out of interest or as part of their work, can use this page to get an overview of ongoing planning and analysis efforts in the Support team, current methods of extracting and analyzing data, and figure out who to collaborate with on specific topics of interest.
Support Global Groups
Support Global Groups main page
Support Learning & Training
Learning Pathways available to Support team members
Support Liaisons
This page describes the Support Liaison role and lists current liaisons
Support Managers
Support Managers activities and references
Support Stable Counterparts
The purpose of this page is to give an overview and outline the expectations of the Support Stable Counterparts initiative.
Support Team APAC
Support Team APAC home page
Support Team Member Time Off
Guidelines for how time off applies to Support team members and what actions need to be taken. Page should not be moved without a Support Global Change Management issue.
Support time off buddy system
Guidelines for leveraging the Support time off buddy system
Support Workflows
Working With GitLab Support
How GitLab team members can work with and best ways to contact Support.