Updating and solving tickets

During a ticket's lifecycle, a there is often a need for further questions and requests for clarification, by both the customer and the handling agent. As part of this process, a ticket's status can change multiple times. Knowing how to manage ticket status changes, including when to use which status label, can make the customer-agent relationship smoother.

This article describes different scenarios and how they can (and should) affect ticket status. It includes the following sections:

Ticket status basics

New indicates that no action has been taken on the ticket. Once a New ticket's status has been changed, it can never be set back to New.

Open indicates a ticket has been assigned to an agent and is in progress. It is waiting for action by the agent. You can view all open tickets using the Open tickets view.

Pending indicates the agent is waiting for more information from the requester. You can view all pending tickets using the Pending tickets view. When the requester responds and a new comment is added, the ticket status is automatically reset to Open.

On-hold indicates the agent is waiting for information or action from someone other than the requester. It 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. However, the On-hold is an internal status that the ticket requester never sees. While a ticket is set to On-hold, the requester sees the status asOpen. On-hold is an optional status, and can be enabled by an administrator as described in Adding the On-hold ticket status to your Zendesk.

Solved indicates the agent has submitted a solution.

Submitting updates and changing ticket status

The Submit button applies any updates you make to a ticket (status changes, public or internal comments, and the like), and allows you to select the ticket status.

To submit updates to a ticket without changing the ticket status

Click the Submit button.

To submit updates to a ticket and change the ticket status

Click to open the status options menu:

Click the status you want to apply upon submitting the ticket.

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, using the Submit button as described above. 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. If you would like to manually change ticket to Closed, you can create a trigger as a workaround (see How can I manually close a ticket? in our Support tech notes).

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 could perhaps add triggers to detect a macro has been used and revert the status but that would mean several triggers. Alternatively you could write an app that monitors things and effectively overrides the status

I noticed that, when the Status of a ticket is On-hold and the requester replies, the Status automatically changes back to Open (same as if it was Pending).

This runs contrary to what I understand to be the purpose of On-hold: assignee is waiting for information or action from someone other than the requester (a third-party) and, based on that, will decide what the next Status will be (and manually set it).

As it is now, if the requester replies, while the ticket is On-hold, we are automatically returned to a state were we are no longer waiting for that third-party (we don't see it in the Status, reminders set via Automations and actions set via Triggers based on that Status become useless).

Changing the way On-hold works, may break some things (like the out-of-office lab app) but consistency of terms is important.

Thanos, I totally understand what you are saying but the reality is that your customer has sent you an update, perhaps chasing you, and you need to be alerted to the fact. I would imagine that a large number of customers use the open status as a filter to show them which tickets need attention and this would be one.
Personally I use custom statuses so I do not have this problem but leaving as on hold risks the customer's comment going unnoticed.

Colin, I understand. In my opinion On-hold (or rather 'waiting for a third-party') ought not be a Status but a separate flag, independent of the Status of the ticket. This takes care of cases like this: I am waiting for customer input (Status=Pending) at the same time I am also waiting for third-party input. One could implement this with a custom ticket field (maybe a checkbox) and Triggers/Automations to match. One could also go with something like https://www.cloudset.net/hc/en-us/articles/205119608-Custom-Status-App-Widget- but it would be an overkill in my case.

Trust me, the Cloudset solution is not overkill, it is what I use :)
You are right, you really need two levels of status and this is what I have implemented but again, you are right, it takes a lot of triggers etc to maintain and also makes it harder for people to create their own views etc and macros as they do not understand the workflow. However, I prefer this to missing a customer comment.

We have set a trigger that when an agent solved a ticket, requester will received a system generated email informing them that their request is already resolved. But sometimes, our agent is not just simply encoding the step by step procedure on how they do it but also put attachment for transparency purpose.

If you want to select specific criteria for exporting tickets, you'll need to use our API. If that ends up being too advanced, you could do the full CSV export, convert it into a spreadsheet format, and then sort the data from there.

We've had the situation arise where someone that was CC'd on the ticket sent an email in response to a solved ticket, but the ticket wasn't reopened as it would have been if the requester had replied. Is there a quick way to modify or create a trigger that would reopen those tickets when someone other than the requester responds?

I haven't had a chance to test it, but I think you should be able to add a condition that tests for a public comment on those tickets to get around that issue. I'd definitely recommend testing it first, though!

Darron, I don't believe it makes any difference whether the updater is a requester or CC. Instead, by default, tickets are not reopened when a private comment is added, but any public comment will always reopen the ticket (that part is hard coded).

So as Jessie said, if you want say agent-submitted comments via email, that are private, to reopen the ticket, you should add a trigger to make that happen.

I would like for updates coming in from an external gmail account to automatically update open existing ticket rather then creating a new ticket.

For example:

User sends an email to itsd@thehub.co.uk (support Gmail address we have given out) which is automatically forwarded to zendesk to create a new ticket and an email response it sent to the user with ticket number (e.g..#2297).

Now if a user puts their ticket number (#2297) in subject line and chases for an update days later via sending another email to itsd@thehub.co.uk how can we automatically update the existing ticket?

Currently it creates a new ticket with a new reference and sends back to the user / Or we have to manually merge the tickets together.

Thanks for your question! If you're using the default triggers then the response would not be sent to the end-user. The trigger that would send an email when a ticket is created is called "Notify Requester of Received Request" which has the condition "Status is not solved"

You can see the trigger makeup here:

If it is important to you that those responses are sent even when the agent selects solves you can remove that condition to get it to send regardless of ticket status.

Is there a way for a ticket to show in the main agent window emboldened when it has been updated in any way? Similar to an unread email showing bold to alert you to the fact that there is unseen info in it.

I feel it would provide a nice visual 'look! This ticket has been updated!' for some of our users who tend to gloss over the info in the Updated column.

So does that mean every time I have followed up a call with a customer by creating a ticket for them, writing 'For your records, we discussed X issue and solved it with Y' and then marked it as Solved when sending, these emails were never received by the customer?

Triggers are what determine when a notification is sent to an end-user. The default triggers in your Zendesk Support account would not automatically send a notification when a ticket is moved into a solved or closed status unless that status change happened at the same time as a public comment.