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?
Ideally it starts with taking responsibility for a ticket by assigning it to yourself at the moment 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 and ensuring the user is kept up to date with what's happening. 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:
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.
Here's what to do when you're actively working on tickets in Zendesk. Divide your efforts between:
If you are part of a Support Response Crew this will influence how you divide your efforts as you will have more focus on incoming tickets on your crew day.
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.
Current Focus | Region | Main View Name with Link |
---|---|---|
Self-Managed | AMER | SM Need Assignee: AMER+All Region |
APAC | SM Need Assignee: APAC+All Region | |
EMEA | SM Need Assignee: EMEA+All Region | |
SaaS | AMER | .com Need Assignee: AMER+All Region |
APAC | .com Need Assignee: APAC+All Region | |
EMEA | .com Need Assignee: EMEA+All Region |
@mention
your manager in Slack in the thread where you requested help, and ask them what the next steps should beSee the Working on Tickets Flowchart for a visual representation.
.com with SLA
, .com Accounts, Groups, Login
, 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.Pending
. We are now waiting for a reply from the user and there is no SLA clock counting.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.+ Add
near the top of the Zendesk screen to create a new ticketIf another engineer is looking at a ticket that you’re interested in working on:
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.)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:
If you choose to do this, make sure the ticket already has an assignee and send a public reply letting them know that:
'Ticket owner name' 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 the ticket owner 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 (insert Ticket Owner Name) is part way through replicating this problem and is in communication with software engineers in their region about the issue. Contact is based in AMER so is not expecting round the clock replies. Hope that's OK (insert Ticket Owner name)?
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:
At times the usual ticket workflow may be interrupted by a new customer emergency ticket or an escalated situation. There may be a need to reprioritise workload to accomodate these. If you anticipate a problem with prioritization please let your manager know so that they can help with next steps.
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 user is waiting on GitLab Support to provide the next reply. | |
Pending | Support has replied to the ticket and is waiting on the user to provide additional information. | If there are no responses after a total of 20 days, Zendesk will move the ticket 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 Zendesk will move the ticket back to open status, requiring an update to the user. On-hold is transparent to the user (they see the status as 'Open') so there is no need to inform the user that the ticket is being put on-hold. It's the engineer's responsibility to ensure timely replies or to set the ticket back to 'Open' if they are no longer working on it. Setting a ticket to 'on-hold' while working on it can be useful as it takes it out of the main view, thus saving other engineers from wasting time reading it. |
Solved | The ticket has been solved | When a user replies to a Solved ticket, Zendesk reopens it. A Solved ticket will transition to 'Closed' after 7 days. |
Closed | The ticket is archived | When a user replies to a Closed ticket, Zendesk opens a new ticket with a note that relates the new ticket to the closed ticket. |
By default, Zendesk will move a ticket from pending to solved after 20 days with no replies. It will also move a solved ticket to closed after 7 days with no replies. While this is normally the right workflow, there might be situations in which you need to prevent this from occurring. To do so, use the appropriate Zendesk labels:
Label | What it does |
---|---|
skip_autosolve | This tells Zendesk to refrain from moving the ticket to Solved automatically |
skip_autoclose | This tells Zendesk to refrain from moving the ticket to Closed automatically |
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.
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.
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.
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.
We have a Slack integration that notifies us of impending breaches:
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.
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 the engineer 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
.
Before setting any ticket to on-hold, set expectations with the user of what you are intending to do and when you will next be in contact with an update. Make sure that your timescales are acceptable for the user and take into consideration any business urgency the user has.
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 Understanding SLAs. Instead reply to the ticket while also changing the status.
If you're merging two of a user's tickets that are related, 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.
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, the information can be deleted using the Ticket Redaction
app.
To delete text or attachments from a ticket:
Redact Attachment
button and choose the attachment you would like to remove.If you don't see the Ticket Redaction App in the sidebar, it is likely that you are not assigned to one of the authorized roles (you can check your role in Zendesk profile). In this case, please reach out to @support_operations
or @support-managers
in Slack to request deletion. Zendesk roles that have access to Ticket Redaction App:
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.
Alternate your focus between working on your assigned tickets and assisting others with making progress on theirs.
[TODO: A report will be made available to Support Engineers so you can easily see how you are doing.]
Help encourage an even distribution of 'volume' of ticket work amongst the team.
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.
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 |