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.
GitLab Support commits to an initial substantive response in a specified amount of time from the time the customer submits a ticket. SLA for this first reply is based on a customer's Support plan as outlined above. Meeting the SLA is currently measured on tickets submitted by customers with our top Support plans (Premium for Self-managed and Gold for Gitlab.com). The formula is Number of Times SLA met / Total Tickets where the SLA was applicable and is usually calculated by month. The target number is that we meet the Priority Support SLA for the first reply 95% of the time. Progress on meeting the Priority Support SLA is tracked in the Zendesk Support Dashboard.
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:
In the past 3 years we expanded the support team significantly, and this trend will continue in 2019. As GitLab – the product – continues to expand, so will the skill and knowledge of all Support Engineers to be able to continue providing an excellent customer support experience.
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. |
| Intra-team trust suffers | Discussion on-going in support-team-meta#1447 |
| 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. |
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:
Know someone who might be a great fit for our team? Please refer them to the job descriptions below.
Increase Documentation Contributions and Usage in Support Cases
Support engineers should always reply to customer issues with a link, whether to GitLab's existing documentation or to an MR that the support engineer creates with new or updated content needed in the docs to address the issue. This Docs-First methodology is essential for ensuring that the documentation remains a highly useful single source of truth. It is not possible or practical to find content across multiple sources including the Forum, public answers, internal guides, etc., while keeping such disparate sources up to date.
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.
Improving the docs enables more users to help themselves, reducing unnecessary support cases.
Actionable Analytics
Better reporting on ticket metrics (topic, response times, product it relates to, etc.) will help guide the Support Team's priorities in terms of adding to the greatest documentation needs, bug fixes, and support processes.
The long term profitability target for support is 90% gross margin.
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.
| Weekday | Region | Meeting Name | Purpose |
|---|---|---|---|
| Tuesday | APAC | Support Call | Discuss metrics, demos, upcoming events, and ask questions |
| Tuesday | AMER | Casual Catch up | Agendaless, a space for the team to banter and chat. If you have work to talk about, feel free. |
| Wednesday | AMER,EMEA | Dotcom Support Call | GitLab.com support team meeting to discuss metrics, demos, upcoming events, and ask questions |
| Thursday | EMEA | Support Call | Discuss metrics, demos, upcoming events, and ask questions |
The regions listed above are the regions for which each call may be the most convenient, but all are welcome on any call. Every call is recorded and notes are taken on the agenda for each one. If you miss a meeting or otherwise can't make it, you can always get caught up.
All Zoom and agenda links can be found on the relevant calendar entry in the Support Calendar.
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. You can add topics any time to the support week in review google document.
We want to think "issue first" so the majority of the doc should be issues, but also consider links to cool articles you've found, or awesome pics from recent trips. It should be something like a 60% work/40% cool stuff blend. We define our culture and this doc is no exception.
On Fridays at 3pm EST, slackbot will remind the team with a link to the week in review and we can use a thread there for banter. Bear in mind that chat older than 90 days will no longer be retained.
You can read about how we got this started in this issue.
The links to the relevant Zendesk views are in the agenda template, but can also be found under the Reporting tab in Zendesk. Two areas to cover:
Answers to questions, deeper insight, and analysis is not expected of the chair. Support Managers will cover metrics in more depth as needed.
If you're presenting metrics for the first time and want to see how it is done, please see past recordings of our meetings.
As a result of our direct interactions with customers, the Support Team occupies a unique position in GitLab. As such we have standing meetings across functions to help surface issues and smooth the interface between 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.
| Function | Party | Support Rep | Frequency |
|---|---|---|---|
| Production | Dave Smith | Lyle Kozloff | every 2 weeks |
| Product | Jeremy Watson | Lyle Kozloff | every 2 weeks |
| UX | Taurie Davis | Cynthia Ng | every 1 week |
| PeopleOps | Jessica Mitchell | Lee Matos | every 2 weeks |
| Finance | Chase Wright | Tom Cooney | 1x Qtr on budget + once per month |
| PeopleOps | Jessica Mitchell | Tom Cooney | every 2 weeks |
| Recruiting | Nadia Vatalidis | Tom Cooney | weekly |
| Docs | Docs Team | Tom Atkins | every 2 weeks join docs meeting |
| Sales + CS | EMEA Sales/CS | Tom Atkins | weekly on Fri join EMEA scrum |
The Support Team follows GitLab's paid time off policy. However, do note that if a large number of people are taking the same days off, you may be asked to reschedule. If a holiday is important to you, please schedule it early.
In addition to the tips in Communicating Your Time Off please also:
If you do not have access to the Support Time-off team calendar, please raise it in the #support-team-chat channel on Slack and someone will share it with you.
You do not need to add time-off events to the shared calendar if you'll be gone less than half a day. Do consider blocking off your own calendar so that customer calls or other meetings won't be scheduled during your time away.
If you need to go for a run, grab a coffee or take a brain break please do so without hesitation.
Just as Support Team are expected to adhere to the Code of Conduct, we also expect customers to treat the Support Team with the same level of respect.
If you receive threatening or hostile emails from a user, please create a confidential issue in the GitLab Support Issue Tracker and include:
Include your Manager, Director of Support, Abuse Team and Chief Culture Officer in this issue. Together we will evaluate on a case-by-case basis whether to take action (e.g. ban the user from the forums for violating the Code of Conduct).
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.
