If a customer asks a question, make sure you fully understand the reason for their question and what is the end result they are looking for. There may be a different and better way to achieve their desired end result, so always feel comfortable asking 'why'.
While waiting for a resolution to this ticket, is the user's business being affected?
If you don't know the answer to this, make sure you check with the user early on in the life of the ticket to prevent the ticket becoming an escalation. Understanding the timescales the user is working to will help you set expectations and help them meet or adjust project timescales.
When you send a user an update, the normal action is to set the ticket status to
Pending, which indicates that you are waiting for a reply from them.
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.
You may also set the ticket status to On-Hold, indicating that you are taking some
action and will follow up with the user at a later time.
When putting a ticket On-Hold, you should:
On-Hold period length.When setting a ticket to Pending or On-Hold, consider using our Due Date
and Reminders
apps to help you to meet commitments you make.
During the course of your ticket work you may link back to feature requests and bugs. While an issue with an assigned milestone may ship in the release indicated, do not promise that it will be. See more in our documentation style-guide.
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.
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.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.
Sometimes, it emerges that a customer is dealing with multiple independent problems in a single ticket, or a user asks about a different problem in an existing ticket.
It's recommended to keep tickets focused on a single problem that's clearly described by the ticket Title. 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.
Please see option 3 in Requesting Support for Customers for details on how to create a new ticket.
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.
Add research notes to your tickets, as it's important that we clearly document all of our work performed throughout a ticket's lifecycle. Not only is this a good way for you to track your own progress, particularly for lengthy and challenging tickets, but it also provides your colleagues with a clear understanding of what has been tried thus far, and enables a smoother transition if a ticket needs to be reassigned.
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.
If you are the assignee of a ticket, and the customer has confirmed that the solution you provided has resolved the issue, add a closure summary to the ticket prior to changing the ticket status to solved.
The closure summary should provide a brief outline of the confirmed solution. It should be written with the goals of giving clarity to the customer with regard to the solution as well as providing your colleagues with a quick and easy way to see what solved the customer's problem.
To make it easier for yourself to create a summary, please consider using the General::Closing Summary macro, which adds a template as an internal note populated with some information. You will then need only to fill in the remaining items with relevant information before copying the completed message to a public comment for the customer.
Some caveats to bear in mind: