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

On this page

• What is the "Working on Tickets" workflow?
  • The Process in Action
    • Brief Summary
    • Main Views
    • The Full Workflow
    • Workflow Visual
  • Keep In Mind:
  • FAQ About Working on Tickets workflow
• Working on Tickets Flowchart
• Tips for working on tickets (all roles)
  • I'm working on a ticket, how do I let the team know?
  • What if someone is working on a ticket that I’d like to work on?
  • A ticket is close to breaching SLA; I'm working on it, but I need more time for my full reply.
  • A ticket is close to breaching SLA. Should I help or defer to the assignee?
  • I need deeper technical assistance on a non-emergency case - what do I do?
  • Understanding Ticket Status
  • Handling Large Files
  • Filling Out Ticket Fields
  • Copying contents of Slack threads to internal notes
  • Understanding SLAs
  • Using On-Hold Status
  • Merging Tickets
  • Removing Information From Tickets
  • Handling emails forwarded from others at GitLab
• How to succeed at working on tickets
  • 1. Weekly ticket review
    • Aim
    • How to do it
    • Context
  • 2. Public replies on your assigned tickets
    • Aim
    • How to do it
  • 3. Meet the ticket baseline
    • Aim
    • How to do it
    • Context

What is the "Working on Tickets" workflow?

The core responsibility of GitLab Support Engineers is to resolve user 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 user. 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 (e.g. create a Slack thread) to help by pairing with you or by providing internal comments in the ticket to suggest next steps. Note that Senior and Staff Support Engineers are specifically charged with putting a large percentage of their time into helping the rest of the team, so they're a great resource when you need ticket help. 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 user, 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 user 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 user.
3. Knowing that you're in charge of a ticket gives you freedom to set and manage user expectations at each step along the way, so the user will know what's going on and who's working on their behalf. Again, this is a user 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

Brief Summary

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

1. taking next steps on tickets that are already in your My Assigned Tickets view, and
2. assigning yourself new tickets from the main view for your region and current focus (see Main Views table), and identifying and taking first steps on those tickets

Main Views

These views show all the unassigned tickets for their respective region and focus. All tickets in these views should be new, since all tickets should be assigned when the first reply is made.

NOTE: For more information about views, see the Views section of our Zendesk Overview page.

The Full Workflow

1. Start your work at the top of your own view
2. Determine whether you can identify any next steps to make progress
   1. If you can, then take those steps, including updating the user
   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 Views, or your own view is up-to-date or empty, and you have the capacity to take on another ticket, then:
   1. Assign to yourself the top ticket (new or open) in the view for your region
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 view to work on, then go back to step 1, else go back to step 3

Workflow Visual

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: watch Slack channels for requests from other SEs on their tickets, and check the .com with SLA or SM with SLA view (depending on your current focus) occasionally for tickets that need some help. To be sure that your suggestions align with the work the assignee has already done, it's best to post an internal note or to pair with them. If you decide to post a public response, be sure that your next steps align with the action plan that the assignee has described on their replies or ticket summary.
2. When you send the user an update, the normal action is to set the ticket status to Pending. We are now waiting for a reply from the user and there is no SLA clock counting.
3. Occasionally you will send a user 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 view.
4. For all tickets in which the user 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. Isn't it the FRT Hawk's responsibility to give the first response on a ticket, not mine? In the past, FRT Hawks were responsible for new tickets. We've evolved our approach so that now new tickets are everyone's responsibility, not just the FRT Hawk's. The FRT Hawk's job is not to provide the first response on every new ticket, but rather to provide that first response when nobody else has been able to take the ticket in time to meet SLA.
3. A ticket is assigned to someone else - can I work on it? Absolutely! Support Engineers should balance their day between working on their assigned tickets and helping others to make progress on their own tickets. 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.
4. If I can provide a good response on a new (unassigned) ticket, but I don't want to assign to myself, may I? Every response should be part of a ticket that is assigned to somebody. If the ticket is unassigned (new), please assign it to yourself and then send your first response to the ticket requester. And remember, you have a whole team ready to help you drive that ticket to a great resolution, so you're never alone.
5. 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 users 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 users 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 take your ticket, you can 'unassign' by assigning it to a 'group' (e.g. 'Support EMEA', 'Support APAC', 'Support AMER'). If the user has specified a preferred region, select the corresponding group. Otherwise, select any 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.
6. 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 user asks about another problem, you are encouraged to "split" the ticket by creating a new ticket on behalf of the user. The new ticket should focus 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:
   1. Click + Add near the top of the Zendesk screen to create a new ticket
   2. Set the user as the Requester (use the same email address as the original ticket)
   3. Give the new ticket a helpful 'Subject'
   4. Paste or write in the relevant text for the new ticket description
   5. Set the correct ticket form and other meta data from the sidebar
   6. Submit as 'New' if the next action is for GitLab or as 'Pending' if the next action is for the user
   7. Add a reply on the original ticket, letting the user know that you've split their ticket. (You could also add an internal note with a link to the new ticket you created if that seems helpful.)
7. 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 user 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 user that you’ve asked another support engineer to take over the ticket due to time constraints.

Working on Tickets Flowchart

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 user. Work with the team if needed as described above.
   3. If you're not able to get a reply out to the user even after seeking help, please speak with a manager to determine an appropriate course of action.
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 user, 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 user 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 user. 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 user 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.

A ticket is close to breaching SLA. Should I help or defer to the assignee?

When you're helping the SLA Hawk to prevent tickets from breaching you need to make a judgement call on what the best action is for the user.

Usually you will take next steps to move the ticket forward and reply with a helpful response even if the ticket is assigned to someone else and originates in another region.

Occasionally it's more helpful to let the user know that the assignee will get back to them soon. When would you do this? There are no hard rules but consider things like:

1. Are you unclear about the next step because you don't have full context and it's not a problem with which you're familiar?
2. Is the customer being severely impacted by the problem?
3. Is the customer clearly in another region? (check the 'Events' view in Zendesk and see where they're located - shown at the bottom of all their replies)
4. Is the assignee out of office today / tomorrow?

If you choose to do this, make sure the ticket already has an assignee and send a public reply letting them know that:

Bob will be back in touch with you later today with an update. Let us know if you need assistance before then.

If the ticket has no preferred region set (the field is blank due to the user submitting the ticket by email) you could also ask:

I notice you're based in the USA, is it OK if we set the preferred region for this ticket to 'AMERICAS' so you'll receive replies during US office hours?

You can now put the ticket 'on-hold'.

As a courtesy it is important to add an internal note to let Bob know your reasoning for sending the holding reply and checking they're OK with that. You can also ping them in Slack if you wish. Be mindful of how you feel if someone does this for a ticket assigned to you and explain why you thought this was the best course of action. You might write something like:

Putting on hold as Bob is part way through replicating this problem and is in communication with software engineers in his region about the issue. User is based in AMER so is not expecting round the clock replies. Hope that's OK Bob?

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

Handling Large Files

Zendesk has a fixed maximum attachment size of 20MB per file. If you need a user 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 view 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 user 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.

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 user. 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 an 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 user'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 of a user's tickets that are related and it's not 100% obvious to the user, 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. The ticket that was merged into another ticket is closed while the status of the target ticket is unaffected.

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

Removing Information From Tickets

We ask users to send us logs and other files that are crucial in helping us solve the problems they are experiencing. If a user 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.

Handling emails forwarded from others at GitLab

Every now and then, a GitLab team member will forward a support request from a customer, prospective customer, user, etc. These requests then appear as tickets from the team member, instead of from the original requestor. Always reply directly to the original requester, keeping the person who forwarded it in the cc. You will need to manually alter the "Requester" field of the ticket, by clicking on the "(change)" link next to the email address of the apparent requester in the ticket title.

Please see Requesting Support for Customers for more details.

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

Alternate your focus between working on your assigned tickets and assisting others with making progress on theirs.

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

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 user 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 user 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 user 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 on your assigned tickets and to help others to do the same on theirs.
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.