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:
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:
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](https://gitlab.zendesk.com/agent/admin/views/360038123559)|
|APAC||[SM Need Assignee: APAC+All Region](https://gitlab.zendesk.com/agent/admin/views/360038102880)|
|EMEA||[SM Need Assignee: EMEA+All Region](https://gitlab.zendesk.com/agent/admin/views/360038102260)|
|GitLab.com||AMER||[.com Need Assignee: AMER+All Region](https://gitlab.zendesk.com/agent/admin/views/360038122359)|
|APAC||[.com Need Assignee: APAC+All Region](https://gitlab.zendesk.com/agent/admin/views/360038122399)|
|EMEA||[.com Need Assignee: EMEA+All Region](https://gitlab.zendesk.com/agent/admin/views/360038102160)|
NOTE: For more information about views, see the Views section of our Zendesk Overview page.
@mentionyour manager in Slack in the thread where you requested help, and ask them what the next steps should be
See the Working on Tickets Flowchart for a visual representation.
.com with SLAor
SM with SLAview (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.
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.
+ Addnear the top of the Zendesk screen to create a new ticket
If another engineer is looking at a ticket that you’re interested in working on:
On-holdis useful when waiting for information from another team.
Openis 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:
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?
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:
Each ticket in Zendesk has a status that tells you what state it's currently in. They are as follows.
|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||The ticket has been replied to and is waiting on the user to provide additional information.||After 3 days in "Pending", a user 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 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 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 view, thus saving other engineers from wasting time reading the ticket.|
|Solved||The ticket has been solved||A user 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 user who replies to a Closed ticket will open a new ticket with a note that relates the new case to the closed ticket.|
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.
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:
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 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.
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.
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:
Redact Attachmentbutton and choose the attachment you would like to remove.
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 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||
|Solved||Public Comments||Internal notes|
|Totals for last week||
|Average per agent||
|Baseline (0.85 of avg)||