Needs Collaborationview and 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 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.
The global priority order for handling tickets is:
|What||Description||Why?||What PI does this affect?|
|New Tickets||All Regions + Tickets in your Preferred Region||These tickets represent a contractual obligation. We must respond within SLA||First Reply Time SLA|
|Tickets without owners||All Regions + Preferred region tickets||These tickets represent risk. Without a DRI they are likely to languish.||SSAT, Customer Wait Time|
|Tickets you own||These tickets are the ones you're the DRI of. Keep your customers up to date and moving towards solutions.||SSAT, Customer Wait Time|
|Everything else||Collaborate with others on the tickets they own, work on learning tasks, handbook or docs updates||SSAT, Customer Wait Time, Support MR Rate, Support Handbook MR Rate|
Here's what to do when you're actively working on tickets in Zendesk. Divide your efforts between:
Needs Org / FRTand
Handover Neededviews (see Meeting FRT SLA).
needs_collaborationlabel to the ticket. This will add it to the
Needs CollaborationZenDesk view.
All Regions, and the priority is
High, follow the High Priority All-Region Tickets Workflow
Needs Collaborationview for opportunities to help Support team members who've requested help on tricky tickets.
@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.
Needs Org / FRT,
Free user ticketsviews for tickets you can work on.
Ensure that the subject of a support ticket is both descriptive and accurate. You can edit the Subject to fix typos or make the problem clearer. Some examples include:
Pending, which indicates that you are waiting for a reply from them. Even though at that point there will be no SLA clock running, you might consider setting an expectation with the customer that you'll check back with them after an appropriate amount of time to ensure continued progress. Should you choose to do that, please consider using our Due Date and Reminders apps to help you to meet that commitment.
On-hold. Either way ZenDesk still removes the SLA and assigns the ticket to you (if it's not already assigned to someone else).
+ 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.)
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:
needs_collaborationlabel to the ticket.
Needs Collaboration ZenDesk view and look for recent requests for help in the
#support_* Slack channels.
Needs Collaborationview and workflow?
Needs Collaboration ZenDesk view includes tickets on which the assignee requested help by adding the
The ZenDesk view contains tickets with the
needs_collaboration label sorted in Ascending order by "Next SLA breach".
If you find a
needs_collaboration ticket you can assist with, leave an internal note, offer to pair, or ping the ticket assignee to share any knowledge, insight, or next steps to help move the ticket toward resolution.
Ticket Assignee Workflow
needs_collaborationlabel once sufficient assistance has been obtained
Support Team Workflow
Needs Collaborationview when caught up on their assigned tickets and other work
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.
When reviewing tickets or monitoring them to prevent SLA breaches you may encounter instances where a customer has confirmed that they have been provided with a solution however the ticket has not been assigned to an individual support engineer. In this type of situation you should inform the customer that you are changing the ticket status to solved and assign the ticket to either the engineer who provided the technical solution or if this is not distinguishable then use good judgement and assign the ticket to an engineer who has significantly contributed to the ticket throughout its life cycle.
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||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
|skip_autoclose||This tells Zendesk to refrain from moving the ticket to
NOTE: If the ticket has been reopened after already auto-solving and we want to prevent autosolve from happening again, the
autosolve_message tags will be present - these do NOT need to be removed when adding the
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 if a ticket from a paying customer 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.
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.
WARNING: Any attached files in the to be merged tickets will be shared across the tickets. Everyone in cc on both of these tickets will receive the files.
If you're merging two of a user's tickets that are related or are duplicates, be sure to send a message letting them know what you've done and why. If you don't, it often causes confusion and they open follow-ups asking why it was closed without comment. Please note that your Zendesk signature will not be automatically applied to this message.
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 Attachmentbutton 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-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.
When customers are putting negative emotions into ticket communications, refer to the handbook entry on how to keep a ticket moving toward resolution when emotions are getting involved for helpful tips and guidance.
Free users receive support in a few specified cases following the free users section of the statement of support.. See the Handling Free User tickets section of the triaging workflow for more details on how to triage these tickets.
Help the team in Meeting FRT SLA) by replying and taking ownership of new tickets each day. Follow the link to see how many to reply to.
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 SM/SaaS/L&R in recognition that the volume of tickets for each focus area 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||
|Solved||Public Comments||Internal notes|
|Totals for last week||
|Average per agent||
|Baseline (0.85 of avg)||