Skip to content

Develop 'Areas of Focus' to improve ticket handling

Context

The Support Engineer Responsibilities page recently introduced the idea of 'Areas of Focus'. This issue is to explain the concept in more detail and propose a plan for developing more areas of focus and making that a core part of how the Support Team handles tickets.

Problem statement A: Inefficient ticket handling, stressful Support Engineer experience

  1. The Support team works on a wide range of problem types. Getting and maintaining expertise in all these areas is not practical for an individual. There's too much to know. As GitLab gets more features this will become more of a problem.
  2. Since it's not possible to be an expert in all problem areas, the current system - where everyone helps on all tickets - means Support Engineers are not as efficient as they could be. When working on a ticket, it's common for Support Engineers to need to learn new things specifically for that ticket.
  3. The product changes very fast. It's not possible to keep up with all new features being rolled out. This leads to inefficiency and stress for Support Engineers who have too much to learn and keep up-to-date with.
  4. Time to resolution is higher than it could be since Support Engineers are not always familiar with the problem they're working on. Reducing TTR improves customer satisfaction.

Problem statement B: Solutions / Application focus - forcing a square peg into a round hole

We recently removed the Support Agent role. All individual contributors on the Support team are now Support Engineers. As part of the same change we introduced the idea of Application and Solutions focus for Support Engineers. This distinction is reflected on the job family page but we have not yet implemented anything internally.

I have tried to think of ways to implement what is described in the above linked MR but have not been successful. Trying to divide by 'Application' / 'Solutions' support does not map well to the problem types we see.

Attempting to implement this feel like forcing a square peg into a round hole.

Solution - Introduce 'Areas of Focus'

A: Assign selected Support Engineers to focus primarily on specific areas on a rotating basis

  1. Gradually introduce this by selecting a class of tickets and giving them their own view in Zendesk.
  2. Assign selected Support Engineers to work primarily from this queue so they get familiar with that type of ticket
  3. Measure outcomes such as Time To Resolution, CSAT and Support Engineer satisfaction to decide if this is effective
  4. If successful introduce another area of focus
  5. Develop a process to enable Support Engineers to rotate between Areas of Focus to help gain new expertise and keep the job interesting. Some folks might choose to stay in an area for a long time. The option to rotate out after a defined period should be available.
  6. Experiment with learning how to allocate the correct number of people to an area based on volume and ticket complexity (suggest use intuition first and experiment since being data driven on this will be hard to start with)

Existing areas of focus:

  1. gitlab.com tickets
  2. self-managed tickets
  3. License & Renewals (see below)

Suggested additional focus areas:

  1. Account based tickets
  2. Authorization / Auth LDAP SAML SCIM etc
  3. Verify / Configure / Package / Release (CI/CD AutoDevops) [EDIT: bad example - see comments below)
  4. CI/CD Pipelines (.gitlab-ci.yml config, testing, artifacts, deployment)

B: Stop thinking and talking about Solutions / Application focus internally

As part of this initiative we would stop talking about Solutions and Applications focus internally.

I believe the distinction is useful on the job family page - these are personas (areas of experience and skills) that we wish to hire. A candidate can have experience in either or both of these areas to be successful.

Internally, everyone is a Support Engineer. During your life as a GitLab Support Engineer you will rotate through a range of 'Areas of Focus' as described above.

This helps get away from the current '.com / self-managed' split that we have on the team and allows us to be flexible with the team that we have.

Case Study - License and Renewals

We currently have around five Support Engineers who are focusing on License and Renewals tickets. These tickets have their own view and include tickets from .com and self-managed customers. Feedback from Support Engineers focused on this area has been positive:

  1. Able to resolve issues more effectively as familiar with the problem space
  2. Less stressful not having to learn everything and context switch
  3. Understanding .com and self-managed parts of the product is valuable to gain a complete understanding of the GitLab product offering
  4. Able to improve product more effectively as get familiar with Product and Engineering teams and people working on that area.

Proposed rollout / experimentation

We can introduce one area at a time and measure results. If successful we can gradually introduce more areas. There will always be an 'other' area. But each time we add a focus area, the 'other' area becomes easier to manage since there will be fewer and less diverse tickets there.

We can use data from Zendesk to help decide what areas to start with (e.g.):

image

There will need to be some refinement to ticket forms as part of the implementation of this proposal.

Most folks should have a Primary and Secondary focus

To maintain our ability to flexibly respond to tickets (e.g. prevent SLA breaches, help out when team members are out / another queue is busy), it's proposed that each person will have two areas of focus - a primary and a secondary.

  1. The Primary area will be a 'focused' area of a well defined problem type
  2. The Secondary area will be a more 'general' area - e.g. 'other Self-Managed' tickets that don't fit into an existing problem type classification.

Make it easy to see who is focusing on what

I plan to make an auto-generated web page that lists all Support Engineers that makes it easy to see and search / filter for who is currently focused on what. I'll add a proof of concept example to this issue before 2020-06-05.

Comments and feedback appreciated! 😄

Risks

  • Bystander effect increases - I believe there's been a slight trend with the rollout of assignment that gives folks an excuse to not handle a ticket or send a soft response. We'll need to make sure that folks focusing in particular areas are known to be escalation points and area experts, not sole-owners.
Edited by Tom Atkins