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:
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:
Self-Managed MY_REGION & All Regions - Needs assigneeview).
The basic workflow looks like this:
@mentionyour manager in Slack in the thread where you requested help, and ask them what the next steps should be
Finding a New Ticket
See the Working on Tickets Flowchart for a visual representation.
Pending. We are now waiting for a reply from the customer 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 queue.
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.)
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 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.|
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.
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.
Support Engineers who are currently focused on helping GitLab.com customers should work on tickets in the GitLab.com views.
Support Engineers who are currently focused on helping self-managed customers should work on tickets in the Self-Managed views.
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.
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.
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, 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.
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.
[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)||