Looking for technical support? Please visit the Support Page instead.
The overall direction for Support in 2017 is set by our overall strategic objectives, with a particular emphasis on continued improvement of (Premium) Customer satisfaction with Support. As can also be inferred from our publicly visible OKR page, the effort focuses on the following elements.
Triaging Support Effort
By triaging support effort through internal SLAs and integration of SalesForce, Zuora, and Zendesk, the team can improve the support experience for Premium customers while still addressing the questions of all subscribers.
Increase Capacity & Develop Experts
In 2016 we expanded the support team significantly, and this trend will continue in 2017. Along the way, the Support team developed internal training tools to assist in rapid, robust, self-guided training for any team member. 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.
Know someone who might be a great fit for our team? Please refer them to the Support Engineer job description.
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.
For an overview of the support we provide to customers and GitLab.com users, please see the general support page. What follows is a more detailed description of the level of service.
The channels are sorted in order of priority, there are 4 SLA categories:
|1||Emergencies (Premium Customers only)||30 minutes|
|2||Premium Customer - Regular Tickets||4 hrs (business)|
|3||Regular Tickets and Security||1 business day|
Response time indicates the first reply time.
Preferably we like to answer tickets sooner than the SLA requires. The higher a channel is in the list the sooner it should be answered.
The above SLAs are based on ticket priority which can be set manually by support agents. See setting ticket priority
Support Engineers should work on tickets within their assigned support speciality as a first priority. Tickets should be picked up in the following order to make sure that SLAs are not breached, and customers receive the proper level of service:
After these are addressed we can work on tickets in any order. When a ticket is breaching or has breached its first reply (or next reply) SLA this ticket must be picked up by any Support Engineer independently of who is assigned to it. This also applies to tickets for Resellers (i.e. anyone picks up if close to breaching, regardless of who the Dedicated Support Engineer is).
This is a special view that is used for two purposes:
Support teams often use an "assignment" model, where an agent is assigned a ticket and sees the ticket through to completion. If they are stuck, they can re-assign this ticket to another agent to pick up and try and complete. At GitLab however, we're taking advantage of our global support team and using a system dubbed "Hot Queuing". This system means that we all work from one global queue and it's expected that multiple agents will be working together on most issues. This allows us to do the following:
There are times in the support process that an agent will want to assign the ticket to themselves:
If you see a ticket in the queue that you are not able to answer, you should:
With the hot queue, we all work together and no one should be scared to start a ticket.
SLAs are set as Business Rules within Zendesk. For more information, please refer to the specific Zendesk page.
We have a slack integration that will notify us of a Premium ticket that will breach within an hour. If you see one of these, start a thread and consider this a small emergency. If you need help, draw attention of other support engineers by tagging them, and work to move the ticket forward.
The Zendesk Insights dashboard lists the activity for all of our current channels and summarizes the last 30 days (Zendesk login required).
Support has 3 meetings a week. Tuesday APAC Support call which will cover Metrics/Demos/Open format questions. Tuesday AMER call, which is focused on Demos and solving challenging tickets as a group. Lastly, the Friday AMER call which is focused on metrics/open format questions. This is how we coordinate and help us all grow together.
Breach hawks are members of the support team who help the rest of the team keep an eye out for nearly-breaching tickets, so that they can be responded to in a timely manner. Of course, any and all members of the Support Team will have a sense of how many tickets are close to breaching and how high the load is on any given day. But it can happen that you're deep into a ticket, a customer call, etc., unaware of the impending doom. That's where breach hawks come in: they tackle their tickets, but they also keep an eye out for the team at large and can call in the Support Turbos when needed.
"fix4all" is a rotation where one developer - or anyone in GitLab - spends a week of his or her time helping the support team, as described in more detail on the "fix4all" rotation page.
Every now and then, it may occur that we come close to breaching our SLAs. To prevent an actual breach from occurring, the Support team can call on the help of several "Support Turbo" developers who are denoted on the Team Page.
Support Turbos are separate from the "fix4all" rotation, in that Turbos are on an as-needed basis while the fix4all rotation is a week-long commitment per person. Anyone within the support team can call Turbos when there is a need for it. Turbos should be called by pinging specific people via Slack. If you are in doubt who is available, you can use
@turbos, but this may lead to a bystander effect.
The support team calls for help when necessary via Slack. Support Turbos should treat requests to solve breaching tickets with high priority. If a Turbo is working on something that cannot wait (e.g. security release, critical regressions, direction issues with near deadlines), the Turbo should ensure that someone else fields the request for Turbos by checking with the development lead or VP of Engineering.
Further guidelines when rolling up your sleeves to do Turbo work:
As described in more detail in the support listings as well as the support onboarding page, we offer services beyond simply responding to tickets. More information on scheduling customer calls can be found in the support workflows.
We offer Dedicated Support Engineers (DSE) for Resellers where the relationship is deemed to be more important than the quick turnaround. This means that tickets that arrive in Zendesk from people within the reseller's organization are routed to a dedicated SE by way of a trigger in Zendesk. (Note, until February 2017 we offered this service to Premium Support Customers, but deprecated it in favor of a faster SLA).
Fellow GitLab team members can reach out for help from the Support Team in various ways:
#questionschannel in Slack, so that everyone can contribute to an answer. If you're not getting an answer, try pinging the group handle for the support team, but be aware that this pings everyone in the team.
The Support project hosts an issue tracker meant to improve our workflow by reporting any problems that may arise in our tools or processes. It's also meant to propose and discuss ideas in general.
The issue tracker is open to the community and part of the GitLab.com group. It should not contain any sensitive information. Links to Zendesk or other references are encouraged.
We use our chat internally as a realtime communication tool. The support channels are as follows: