Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Working on Tickets

  1. You are here:
  2. Support Team Handbook
  3. Support Workflows
  4. Working on Tickets

What is the "Working on Tickets" workflow?

The core responsibility of GitLab Support Engineers is to resolve customer problems by solving support tickets on a daily basis. You accomplish this using the "Working on Tickets" workflow. The focus is being responsible for the continuous progress toward resolution of a specific set of tickets. What does this look like?

It starts with assigning a ticket to yourself at the moment when you make the first public comment on it. From that point forward you should be thinking about how you can keep that ticket moving toward a resolution that's acceptable to the customer. Don't worry - you're not responsible for creating the solution, only for making the solution happen. You're the leader, not the sole contributor. If you can resolve the ticket independently, great! If not, ask others to help by working with you (e.g., create a thread in Slack, arrange a pairing session). If you're not able to find someone to work with you, please let your manager know so that they can help with next steps.

Benefits of working on tickets assigned to yourself:

  1. You won't have to read through a series of updates from multiple support engineers, and the customer, to understand the ticket history, current status, or plan of action. In fact, we encourage you to include a brief description of those items - history (what's happened so far), current status, next steps - in most of your updates to the customer so that your last update always tells you what you need to know.
  2. With one person in charge of each ticket, you can take a consistent approach to resolving the problem, you can explain why and what you're doing, and you won't repeat or contradict an action taken by somebody else on the ticket. This is a much better experience for the customer.
  3. Knowing that you're in charge of a ticket gives you freedom to set and manage customer expectations at each step along the way, so the customer will know what's going on and who's working on their behalf. Again, this is a customer experience enhancement.

When you're "Working on Tickets", you're driving achievement of our KPI of Support Satisfaction by helping to resolve tickets as quickly and effectively as possible.

The Process in Action

Here's what to do when you're actively working on tickets in Zendesk. Divide your efforts between:

The basic workflow looks like this:

  1. Start your work at the top of your own queue
  2. Determine whether you can identify any next steps to make progress
    1. If you can, then take those steps, including updating the customer
    2. If not, then link the ticket in Slack and ask for help from your teammates
  3. If it's been an hour or more since you checked the main queue (or your own queue is up-to-date or empty), and you have the capacity to take on another ticket, then:
    1. If the ticket at the top of the main queue has an SLA that will expire in an hour or less, assign that ticket to yourself
  4. If you've asked in Slack for help on a ticket, and nobody has stepped up to help, and you feel you can't wait any longer for help, then:
    1. @mention your manager in Slack in the thread where you requested help, and ask them what the next steps should be
  5. If there are tickets left in your queue to work on, then go back to step 1
  6. Go back to Finding a New Ticket

See the Working on Tickets Flowchart for a visual representation.

Keep In Mind:

  1. Teamwork is really important with this workflow. Be aware of what's happening across the board and jump in! Pairing with someone is a great way to work out complex issues.
  2. When you send the customer an update, the normal action is to set the ticket status to Pending. We are now waiting for a reply from the customer and there is no SLA clock counting.
  3. Occasionally you will send a customer a reply letting them know that you're going to follow up with further information. In this case you should set the ticket status to Open or On-hold. When this happens ZenDesk still removes the SLA. To help ensure we don't forget to follow up, a trigger automatically assigns the ticket to you (if it's not already assigned to someone else) so that you can see it in your queue.
  4. For all tickets in which the customer is waiting on a response from Support, always provide an update on its status and work that has been done. Aim to do this daily, and definitely no less than every four days (the length of the On-hold period).

FAQ About Working on Tickets workflow

  1. How many tickets should I have assigned to me? There's no specific number. Aim to take as many tickets as you can while being sure that you can give good attention to each of them daily (unless they’re on hold). You might expect that to be somewhere between three and ten open, pending or on-hold tickets in your My Assigned Tickets view.
  2. A ticket is assigned to someone else - can I work on it? Absolutely! Support Engineers should balance their day between being 'proactive' (working on your assigned tickets) and 'reactive' (helping prevent tickets from breaching their SLAs). Tickets breaching soon may be assigned to a team member in a different region. When replying to these tickets, be sure that your next steps align with the action plan that the assignee has described on their replies or ticket summary.
  3. I'm going to be absent, what do I do with my assigned tickets? If you'll be absent for only a day or two, please ask your customers whether they want to wait for your return or work with others in your absence. For those who will wait, place their tickets on hold. For longer absences, please inform your customers that your tickets will be reassigned due to your upcoming absence. Then, find someone willing to take over each ticket, and review the tickets with them before reassigning. If you can't find someone to assign your ticket to, you can 'unassign' by assigning it to a 'group' (e.g. 'Support EMEA', 'Support APAC', 'Support AMER'). It doesn't matter which group - the ticket will still be visible for all Support Engineers. Be sure in this situation to create a very clear and thorough ticket summary so that the next engineer can come up to speed very quickly.
  4. A ticket has diverged into more than one problem. What do I do? It's recommended to keep tickets focused on a single problem that's clearly described by the ticket Title. If the customer asks about another problem, you are encouraged to create a new ticket on behalf the customer that focuses on a single issue and keep the original ticket on the original issue. This helps reduce time to resolution and makes it easier for us to focus on fixing the problem at hand.
  5. Can I reassign a ticket to someone else? There are some situations in which you should look to reassign a ticket:
    1. If you'll be absent, see the FAQ above about reassigning tickets when you'll be absent.
    2. If you've determined that specific expertise outside your own is required to resolve the ticket, your first choice should be to pair with an expert so that you can get the ticket resolved and learn in the process. But if pairing is not reasonable, go ahead and reassign the ticket after discussing it with the other support engineer. Be sure to send a message to the customer informing them that you’ve asked another support engineer with relevant expertise to take over the ticket, and that you’ve reviewed the ticket with that engineer.
    3. If you've become overloaded with tickets, feel free to rebalance your load by finding one or more teammates to take over some of your tickets. Be sure you discuss each ticket before reassigning it so that the other support engineers don't have to start from scratch. Then inform the customer that you’ve asked another support engineer to take over the ticket due to time constraints.

Working on Tickets Flowchart

graph TD A([My Tickets]) --> B B[Open the 'My Assigned Tickets View' in Zendesk] --> B1 B1{Are there tickets left in
your view that need work?} -->|Yes| C B1 -->|No| NT2 C[Select top ticket from queue] --> D D{Can you make progress and
take the next steps?} D -->|Yes| E[Update the customer
with the next steps] D -->|No| F[Link the ticket in
Slack and ask
teammates for help] E & F --> NT0 NT0([Finding a New Ticket]) --> NT1 NT1{Have you checked
the main queue
in the last hour?} -->|Yes| AH0 NT1 -->|No| NT2 NT2{Do you have capacity
for another ticket?} -->|No| AH0 NT2 -->|Yes| NT3 NT3{Is there a ticket in the
main queue expiring
within an hour?} -->|No| AH0 NT3 -->|Yes| NT4 NT4([Assign the ticket to yourself]) --> B1 AH0([Check on Help Requests]) --> AH1 AH1{Is there a ticket
on which you need
help but nobody's
volunteered?} -->|Yes| AH2 AH1 -->|No| B1 AH2["@"mention your manager in
Slack in the thread
where you requested help.
Ask them for next steps.] --> B1

Tips for working on tickets (all roles)

I'm working on a ticket, how do I let the team know?

  1. If the ticket is unassigned, then:
    1. Assign the ticket to yourself:
      1. This takes it out of the 'Needs assignee' view so other engineers won't waste time on it
      2. NOTE: The SLA clock continues to run!
    2. Work on the ticket and aim to get a helpful reply out to the customer. Work with the team if needed as described above.
    3. If you're not able to get a reply out to the customer even after seeking help, it's OK to unassign the ticket as described above, though this should be a last resort. Please add an Internal Note summarizing anything you discovered during your research. This helps the next person who picks up the ticket.
  2. If the ticket is already assigned to someone else and you're stepping in to help them, then:
    1. Add yourself to the CCs
    2. Enter a short internal note stating "assisting"
    3. Proceed to write and send your reply to the customer, or to pair with the assignee to work on the ticket

What if someone is working on a ticket that I’d like to work on?

If another engineer is looking at a ticket that you’re interested in working on:

  1. Contact them in Slack to confirm whether they're actively working the ticket.
  2. If they are, ask to pair on the ticket, or share with them any information and questions that you have.
  3. If they don’t respond in Slack, go ahead and work on the ticket - Bias for Action is part of GitLab's core Value, Results.

A ticket is close to breaching SLA; I'm working on it, but I need more time for my full reply.

  1. Please send the customer a short message to update them on the action plan: what you're doing, what progress you've made, and what's left to do. Let them know when you expect to have next steps for them to take. Doing this will not only prevent an SLA breach, it will very likely be well-received by the customer. Remember, you don't need to have a full answer in order for your message to be useful.
  2. When sending the short public reply, set the ticket status to On-hold or Open. On-hold is useful when waiting for information from another team. Open is useful when you want to keep the ticket visible to the rest of the Support team. (See below for more details on choosing a ticket status.)
  3. When you take the above action, keep your commitment and get back to the customer on time and with a full reply including next steps. Keep in mind that you've stopped the SLA clock, so it's up to you to respond on time. Do not take this action if you are not planning to be the one to follow up.

I need deeper technical assistance on a non-emergency case - what do I do?

Sometimes, you might require help from senior support engineers, subject matter experts or developers on your tickets. These tickets are most likely either long-running or technically challenging. We encourage collaboration and you can use the following steps as a general guideline if you are unsure of what to do next:

  1. Start by posting an internal message in the ticket clearly summarizing the problem, the steps that have been taken so far (including the reasoning behind them), the results of those steps, and the current status.
  2. Check the Support Team Knowledge Areas handbook page to see if someone would be able to assist you.
  3. Look for assistance in the internal Support Slack channels.
    1. Initiate a crush session or a pairing session in the #support_self-managed or #support_gitlab-com Slack channels.
    2. If you now have some new ideas to try, make sure you have a clear plan of action and engage with the customer.
  4. If you still require further assistance, reach out in the Slack channel of the appropriate stage/group.
    1. If the situation demands (bug, regression, feature request etc) and an issue doesn't already exist, a new issue must have been filed related to the ticket and linked in all appropriate places.
  5. If you are unable to get assistance from a developer through the previous step, a Product Manager might need to be involved - reach out to a Support Engineering Manager via the #support_managers Slack channel for assistance.

Understanding Ticket Status

Each ticket in Zendesk has a status that tells you what state it's currently in. They are as follows.

Status Meaning Notes
New The ticket has just been opened and has had no replies.  
Open The ticket has had one or more replies, and the customer is waiting on GitLab Support to provide the next reply.  
Pending The ticket has been replied to and is waiting on the customer to provide additional information. After 3 days in "Pending", a customer will receive a further response reminding them that the ticket exists. If there are no responses after a total of 7 days, the ticket will be moved to Solved.
On-Hold GitLab support is working on the ticket and may be waiting for information from another team Placing a ticket on-hold will assign it to the engineer. After four days the ticket will move back to open status, requiring an update to the customer. On-hold is transparent to the customer (they see the status as 'Open') so there is no need to inform the customer that the ticket is being put on-hold. It's the engineer's responsibility to ensure timely replies or set the ticket back to 'Open' if they are no longer working on it. Setting a ticket to 'on-hold' while working on the ticket can be useful as it takes it out of the main queue, thus saving other engineers from wasting time reading the ticket.
Solved The ticket has been solved A customer who replies to a Solved ticket will re-open it. A Solved ticket will transition to 'Closed' after 4 days.
Closed The ticket is archived A customer who replies to a Closed ticket will open a new ticket with a note that relates the new case to the closed ticket.

Handling Large Files

Zendesk has a fixed maximum attachment size of 20MB per file. If you need a customer to share a larger file than this, then see Provide Large Files to GitLab Support for information on how to do so.

Filling Out Ticket Fields

Depending on the queue you are working on and the form the ticket belongs to, you might need to fill out some ticket fields manually. Those fields help us capture important data that will help us improve the customer experience. As a high percentage of our tickets are solved/closed automatically through our workflows, it is important to make sure that before you submit your response to a ticket, you check that all required (*) fields and relevant non-required fields have been filled out.

Copying contents of Slack threads to internal notes

When using Slack to work with others or communicate internally regarding a support ticket, please bear in mind our chat retention policy and the Communication Guidelines (esp. 9.). It's best for future searches in Zendesk to copy relevant advice, notes, ideas, etc. from Slack to an internal note in Zendesk.

Understanding SLAs

Our SLA workflow relies on end-users who submit tickets belonging to an organization and that organization having a GitLab Plan. Organization information is automatically added to Zendesk via a Salesforce Integration. We sync all records with Account Type equal to Customer from Salesforce to Zendesk. The information we get from Salesforce includes but is not limited to: Account Owner, Technical Account Manager, GitLab Plan and Salesforce ID. Organizations should never be created manually in Zendesk as that can cause our sync to be ineffective. If you think an Account in Salesforce doesn't have an equivalent Organization in Zendesk, please let the Support Operations Specialist know so a manual sync can be run.

SLAs are set as Business Rules within Zendesk. For more information, please refer to the specific Zendesk page.

We have a Slack integration that notifies us of impending breaches:

  1. Self-managed - if a Starter, Premium, or Ultimate ticket will breach in less than 2 hours
  2. GitLab.com - if a Bronze, Silver, or Gold ticket will breach in less than 2 hours

If you see an SLA notification in Slack, start a thread and consider this a small emergency. If you need help, draw the attention of other support engineers by tagging them, and work to move the ticket forward.

If a customer's reply is the last one in the ticket, do not set it to any status silently (except for Solved), because the breach clock will continue to run and the ticket may breach silently. Instead, send a confirmation, greeting, or other message, while also changing the status.

GitLab.com Views

Support Engineers who are currently focused on helping GitLab.com customers should work on tickets in the GitLab.com views.

Self-Managed Views

Support Engineers who are currently focused on helping self-managed customers should work on tickets in the Self-Managed views.

Non-Support Views

  1. Security
  2. Accounts Receivables & Refunds

Using On-Hold Status

You should use the On-hold status when it is necessary to do some internal work, e.g. reproduce a complex bug, discuss something with developers or wait for a session scheduled with a customer. When setting the status to On-hold it will be automatically assigned to you by the trigger Automatically assign on-hold ticket to an agent who put it to the on-hold status.

If you think that it should be assigned to someone else (e.g. session is scheduled for another engineer), feel free to re-assign it. Tickets without assignee will be automatically reopened by the trigger Automatically reopen on-hold tickets without assignee. Tickets in on-hold status with an assignee will be automatically reopened in 4 days by the automation Reopen on-hold tickets after 4 days.

If a customer's reply is the last one in the ticket, do not set it to the On-hold status silently due to the same reasons as stated above in the Zendesk SLAs and Breach Alerts). Instead, reply to the ticket while also changing the status.

Merging Tickets

If you're merging two customer tickets that are related and it's not 100% obvious to the customer, be sure to send a message letting them know why you're merging them. If you don't, it often causes confusion and they open follow ups asking why it was closed without comment.

Additionally, when Merging Tickets, leave Requester can see this comment unchecked in the ticket that's being merged into (the second ticket from the top) in order to maintain the SLA. If the merge comment is made public, Zendesk considers it a response and removes the SLA.

NOTE: Any ticket merge is final – there is no option to undo it.

Removing Information From Tickets

We ask customers to send us logs and other files that are crucial in helping us solve the problems they are experiencing. If a customer requests deletion of information shared in a support ticket, or if we suspect sensitive information was accidentally shared, ask a Support manager to delete the files using the Ticket Redaction app. Only Zendesk administrators have access to this app.

To delete text or attachments from a ticket:

  1. Go to the ticket in question and on the right hand nav bar, scroll down until you are able to locate the Ticket Redaction app.
  2. In the text box, enter a string of text or source image URL you wish to redact.
  3. If you wish to remove an attachment, you can click on the Redact Attachment button and choose the attachment you would like to remove.

How to succeed at working on tickets

1. Weekly ticket review

Aim

  1. Make your work visible
  2. Develop consistent high quality ticket work across the team

How to do it

  1. Review at least two tickets each week in your 1:1 call with your manager
  2. Tickets can be selected by you or your manager
  3. They can be tickets with work you're proud of or where you would like feedback
  4. Your manager will give you feedback on:
    1. Technical quality
    2. Communication quality
    3. Collaboration quality (where appropriate, did you work with other Support Team members, managers, other GitLab team members or directly with the customer on a call)

Context

  1. This is currently an informal process between you and your manager.
  2. It is not part of a formal performance review.
  3. We're investigating a more comprehensive ticket retrospective process.

2. Public replies on your assigned tickets

Aim

Balance your focus between 'proactive' work to continue the progress on your assigned tickets and 'reactive' work to assist in making progress and preventing SLA breaches on other tickets.

How to do it

  1. Aim for around 50% to 60% of public replies to be on tickets that are assigned to you.

[TODO: A report will be made available to Support Engineers so you can easily see how you are doing.]

3. Meet the ticket baseline

Aim

Help encourage an even distribution of 'volume' of ticket work amongst the team.

How to do it

  1. Focus on solving customer problems via tickets as the core part of your work.

That's it! For most people that's all you need to do. Once you've completed onboarding and have been helping out with tickets for two months or more, it's useful to gauge your contribution compared to the rest of the team.

Context

Each week we publish the 'mean average per Support Engineer' for solved tickets, public replies and internal notes in the Support Week in Review.

We produce separate reports for self-managed and .com tickets in recognition that the volume of tickets for the two roles is different.

We establish a dynamic baseline that is 0.85 of the mean average* for each metric. \ (*value is chosen based on the threshold for the lower quartile).

Here's an example week for folks working on self-managed tickets:

Number of self-managed Support Engineers

50
Solved Public Comments Internal notes
Totals for last week

300

1000

500
Average per agent

6

20

10
Baseline (0.85 of avg)

5.1

17

8.5
  1. Support Engineers that have completed onboarding are expected to achieve the baseline as a minimum. Don't worry in a given week if you don't meet the numbers. The baseline is a guide to help balance team contributions - it is not a stick to penalize anyone.
  2. There are good reasons why you might not achieve the baseline on a given week (e.g. vacation, illness, working on other projects, carrying out interviews) and you should keep your manager informed when you're not able to focus on resolving customer problems by contributing to support tickets.
  3. If you don't meet the baseline you should discuss the reasons with your manager. If they're not satisfied that there are good reasons for not meeting the baseline, they will ask you to focus more on solving customer problems on Support tickets so that you meet the baseline in future weeks. This helps balance contributions across the global team.
  4. We believe in quality, not quantity - more is not automatically better.
  5. We recognize that the three metrics selected are not a complete indication of 'good work' on their own.
  6. We recognize that the metrics for 'public replies' and 'internal notes' can be 'gamed' by making small updates. We trust the team to do the right thing for the customer and GitLab. This is why the ticket baseline is the last part of 'how to succeed' in this area. It is more important to make quality updates and balance your focus between 'proactive' work on your assigned tickets and 'reactive' work to prevent SLA breaches.
  7. There is no automated process to report on people that don't meet the baseline. The baseline is there to help you gauge your contribution and as a conversation starter between you and your manager.
GIT is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
Edit this page — open Web IDE — please contribute. Creative Commons License