As an agent, your primary responsibility is to solve your customers' support requests. To do that, you work with tickets, which can arrive in your Zendesk in various ways such as via the Web portal request form, directly through email, by telephone and text chat, and from social media such as Twitter and Facebook. The options your customers have for requesting support are called channels. The channels that your Zendesk supports are determined by the account owner or administrator who set up your Zendesk.
Depending on how your Zendesk manages the ticket workflow, you may manually select and assign tickets to yourself or other agents. Tickets can also be automatically assigned to you and other agents via automations and triggers, which are referred to as business rules (you can read about these workflow management tools in Streamlining your support workflow in the Zendesk Administrator Guide).
All of the tickets in your Zendesk are listed in and are opened from views. Zendesk provides you with a standard set of views that organize tickets into lists based on a typical ticket workflow. For example, all of your new unassigned tickets are listed in the Unassigned tickets view.
An administrator can create new shared views (views that are visible to all agents) and edit the standard views provided by Zendesk. As an agent, you can create views for yourself so that you can organize your tickets according to your own criteria and preferences.
To help prevent more than one agent from working on a ticket at the same time, an alert is displayed in the ticket when you and someone else are simultaneously viewing a ticket. This feature is available in the Plus and Enterprise versions of Zendesk and is called agent collision and it looks like this in the ticket.
However, just because other agents may be viewing a ticket at the same time doesn't mean that they are assigned to the ticket or that they are making any changes to it. This alert is just to make you aware of who else is viewing the ticket. Any of the agents that have access to the ticket can make changes to it; therefore, it's good to know who has it open and avoid more than one agent working on a ticket at the same time.
You'll also see the agent collision message in the ticket summary pop-up that is displayed when you hover over a ticket in a view with your mouse.
Zendesk Classic: The ticket collision message is displayed across the top of the ticket page.
About ticket fields
Typically when an end-user submits a support request, they provide the subject and description of their question or support issue. They may also be prompted to provide additional data such as a model number or product version using custom ticket fields. All of the other data in a ticket is set by you or behind the scenes using the business rules that have been set up for your Zendesk.
Each of the standard ticket fields (referred to as system fields), those that are shown in the agent's view of the ticket page, are described below.
All tickets require a requester. The requester is the person who made the support request.
If your Zendesk has been configured to allow it, other people can be CC'ed on tickets. Both the requester agents can add CCs to a ticket. The requester does it by adding CC email addresses if they requested support via your support email address. Agents can add CCs using the CC field when updating the ticket. See Copying someone else (CC) on a ticket.
The Share field is only displayed if your Zendesk has enabled ticket sharing, which means that tickets can be shared with other Zendesk accounts. See Sharing tickets.
The Subject field is required. It's typically included in the support request submitted by the requester. For example, when someone submits a support request via email, the subject line of the email is used as the ticket's subject.
The description is required. This is the text of the support request. When an end-user submits a support request via email, the body of the email request is used as the description. The description becomes the first comment in the ticket.
There are five values for status: New, Open, Pending, On-hold, Solved, Closed. A ticket's status can be set and updated either manually by an agent or automatically via your business rules. A ticket's status cannot be changed to Closed manually however; that is handled automatically via your business rules.
New means that the request was received but that it has not been opened and has probably not been assigned to an agent. The New status can indicate that the support team is evaluating it to determine who should be assigned to resolve it.
Open means that the request has been assigned to an agent who is working to resolve it.
Pending means that the assigned agent has a follow-up question for the requester. The agent may need more information about the support issue. Requests that are set to Pending typically remain that way until the requester responds and provides the information the agent needs to continue resolving the request.
On-hold means that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. This status is optional and must be added to your Zendesk (see Adding the On-hold ticket status to your Zendesk in the Zendesk Administrator Guide)
Solved means that the agent has resolved the support issue. Solved tickets are closed, typically, a number of days after they have been set to Solved (the exact number of days depends on how an Administrator set this up for your Zendesk). Until a ticket is closed, the requester can reopen the ticket. For example, the requester may not agree with the agent that the support issue is resolved and reply back to the ticket solved email notification.
Closed means that the ticket is complete and can't be reopened. Requesters however can create follow-up requests for closed requests.
There are four values for type: Question, Incident, Problem, and Task. You can also set the type to none, if you wish; it is not a required ticket field. Setting the type helps you to categorize your tickets, which you can then use in your workflow. For example, you can create views of tickets by their type.
Question is used to indicate that the requester's issue is a question rather than a problem that needs to be solved.
Incident is used for occurrences of a problem that affect more than one person. For example, if the wireless network in an office stops working, the problem will probably generate several support requests. Instead of handling each ticket separately, create one ticket describing the problem and set the type to Problem. Next, link the incident tickets to the problem ticket. When you solve the problem ticket, all of the linked incident tickets are solved too.
Problem is used to indicate that the requester is having an issue with your product or service that needs to be resolved.
Task is used when you want to assign the ticket as a task to a specific agent. When you select Task, you also set the Task Due Date.
There are four values for priority: Low, Normal, High, and Urgent. You can also set the type to none, if you wish; it is not a required ticket field. How you weight the priority of your tickets is up to you. For example, you might assign a ticket to Urgent based on the customer who submitted the request or based on how many hours have passed since the ticket was created.
Tags are used throughout your Zendesk to add additional information to tickets, which can then be used in your ticket workflow. Tags can be added to tickets in the following ways:
You can add them manually.
Tags can be added (and removed) automatically based on your business rules.
Tags can be added to users and organizations and these tags are automatically added to tickets.
Tags are flexible and powerful tools that can be used in many ways. For more information about tags, see Using tags in the Zendesk Administrator Guide.
In addition to these system ticket fields, tickets can also contain custom fields, which are used to gather additional information from the person who is requesting support. For example, your Zendesk may add a custom field prompting them to select a product name or model number. Custom fields are added by administrators. For more information, see Adding and using custom ticket fields in the Zendesk Administrator Guide.
Adding comments to tickets
Once a ticket has been created and it's been assigned to an agent, it's the agent's job to resolve the support request. To do that, you may need to gather more information from the requester. To communicate with the requester, you add public comments to the ticket. Public comments can be read by anyone who has access to the ticket.
Each time you add a public comment, the requester is notified via an email message. If the requester responds back to the email notification, their response is added as a public comment to the ticket. All of your communication is captured in the ticket.
You can also add private comments to tickets. These comments are only visible to other agents, not to the ticket requester or any other end-users that may have been CC'd on the ticket.
Comments can also contain file attachments. To attach one or more files to a comment, click Attach file.
The maximum size of an attachment is 1 MB for Starter, 7 MB for Regular, and 20 MB for Plus and Enterprise. The files you attach to the comment are added to the email notification message.
You cannot remove an attachment from a ticket after you have submitted the ticket.
Changing a public comment to private
After you have submitted a ticket, you can change a public comment to private. Agents can change only their own comments from public to private. Admins can change any public comment to private. You cannot however change the first comment in a ticket. This is the ticket description and is always public.
To make a public comment private
Open the ticket that contains the comment you want to change.
Click the Events link in the comments section.
Zendesk Classic: Click the All events and notifications link in the comments section.
The ticket's events and notifications are displayed.
Under the comment you want to change, click Make this comment private.
Quickly assigning yourself to a ticket
When viewing a ticket, you can quickly assign the ticket to yourself by clicking the Take it link, which appears above the Assignee field when you hover your mouse over it, as shown below. This ticket will be assigned to you when you submit the ticket.
Zendesk Classic: The Take it option is not available in Zendesk Classic. It is only available in the current version of Zendesk.
If you're creating a ticket for yourself, leave the Requester field blank. The system will make you the requester when you submit the ticket. You might want to do this when you assign yourself Task-type tickets, for example.
Aside from the ticket field data described in About ticket fields above, every ticket contains comments and events and notifications. Comments are either public, meaning that the requester can see them, or private, meaning that only agents can see them.
A ticket's events and notifications capture important events in the lifecycle of the ticket and can help you more thoroughly track the updates that have occurred to the ticket and the communication that has occurred with the ticket requester.
To view a ticket's events and notifications
Select a ticket and then click the Events link in the ticket header.
The ticket's events and notifications are displayed.
Zendesk Classic: To view events and notifications, select a ticket, then click the All events and notifications link.
Asking for more information from the requester
Many support issues require that you gather more information from the requester so that you have enough information to resolve their issue. You add public comments to the ticket, which are sent to the requester as email notifications. When you're waiting for a requester to provide you with more information, you set the ticket Status to Pending. Doing this indicates that the ticket, from your agent perspective, is on hold.
Then, you and other agents can view all pending tickets using the Pending tickets view. Also, it's a typical best practice to set up an automation that sends the requester an email some days after you set the ticket to Pending to remind them that their input is needed before their support request can be solved. Your automations are set up by administrators.
To set a ticket to Pending, just open it and change the status and then update the ticket.
When the requester responds and a new comment is added, the ticket status is automatically reset to Open. A ticket can be changed from Open to Pending and vice versa many times during the course of resolving the support issue.
Asking for information from a third party
If you need to get some information from a third party before you can provide the requester with a solution, you can use the On-hold status. This is an optional status and not available in your Zendesk unless an administrator has enabled it. Adding this status is described in Adding the On-hold ticket status to your Zendesk in the Zendesk Administrator Guide.
The On-hold status is similar to the Pending status in that you as an agent can't proceed with resolving the ticket until you receive more information from someone else. The On-hold status however is an internal status that the ticket requester never sees. While a ticket is set to On-hold, the requester sees the status as Open.
Problem and incident tickets
Incident is used for occurrences of a problem that affects more than one person. For example, if the wireless network in an office stops working, the problem will probably generate several support requests. Instead of handling each ticket separately, create one ticket describing the problem and set the type to Problem. Next, link the incident tickets to the problem ticket. When you solve the problem ticket, all of the linked incident tickets are solved too.
Solving a ticket and understanding how it is closed
Once you've resolved a requester's support issue, you change the ticket status to Solved. This should mean that you're done with the ticket and that the requester is satisfied with the resolution you provided. However, a requester can reopen the ticket after it has been set to Solved just by responding back and adding a new comment. For example, perhaps the requester disagrees that their support issue was resolved or that something new occurred that invalidates the fix.
After you set a ticket to Solved, the next status change is to Closed. However, you can't manually change a ticket to Closed; it is set to that status via a predefined business rule called an automation. An administrator creates automations and determines just how long tickets remain in the solved state before they are closed. If an administrator deactivates the automations that close tickets, the tickets will be closed automatically 28 days after they're solved.
After a ticket's status has changed to Closed, the requester can no longer reopen it. They can however create a follow-up request that references the original, now closed ticket. Agents can also create a follow-up for a closed ticket. See Creating a follow-up for a closed ticket.
Tickets that are follow-up requests for a closed ticket are marked as such. For example:
You can delete closed tickets if you have permissions to delete tickets. Open each ticket and select Ticket Options > Delete from the menu on the lower-right side of the ticket page. You can't delete closed tickets in bulk in a view. However, an administrator can use the API to delete closed tickets in bulk. See Bulk deleting tickets in the REST API guide.
Managing tickets using email
In addition to using the user interface in Zendesk, you can manage tickets from your email inbox. For example, you can add a comment to a ticket by replying to a ticket email. You can also quickly triage tickets from your inbox by setting ticket properties in the emails' body.
Setting ticket properties
You can set ticket properties when replying to ticket emails or when creating new tickets through email. Set the ticket properties by including commands at the top of the email body. For example, to open and assign a ticket to yourself, add the following commands at the beginning of the email body:
Hey Benson, sorry to hear you're having trouble...
Don't remove the token when replying to notification emails. Zendesk uses the token to associate your reply with the right ticket. If the token is removed, the response is routed to the Suspended Tickets view. An admin has to manually recover it.
Notification emails sent to end-users never include these tokens.