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:
If you haven't already, you should familiarize yourself with the Zendesk Support agent interface.
Ticket status basics
There are five standard statuses you can apply to a ticket:
- 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 as Open. 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 is Closed. However, you can't manually change a ticket to Closed; it is set to that status using a predefined business rule called an automation (see Support default automations). An administrator creates automations and determines how long tickets remain in the solved state before they are closed. The default automation setting is that a ticket is closed automatically four days after it has been solved. If an administrator deactivates the automations that close tickets, the tickets is closed automatically 28 days after they're solved.
To manually change tickets 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:
Closed tickets are saved indefinitely. You can view the tickets by searching for them or by creating views of closed tickets. See Using views to manage ticket workflow.
You can delete closed tickets if you have permissions to delete tickets. Open each ticket and select the Ticket options arrow in the upper right, then select Delete.
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.
39 Comments
Is there a way to submit a ticket without modifying its status?
We have some cases in which we don't want to change the status that a macro applies to a ticket after submitting it.
Thanks!
@Aarón, is there a way - yes. Is there an easy way? No.
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
Is there a way to not have replies reopen the ticket after its status is marked as Solved?
@Adrian, you could create a trigger that detected the change from Solved and change it back again perhaps notifying the current assignee at the same time
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.
Good Day!
Is there a placeholder for attachment?
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.
Thanks!
Hi Barbie!
There are a couple different placeholders you could work with for attachments. You can see them here: Zendesk Placeholder Reference - Comment Data.
Hope that helps!
Hi Jessie,
Placeholder for attachment is now applied and it's now working.
Thanks for the suggestion.
-----
For other concern, could you also help me on how can I export Closed/Solved/Pending tickets ONLY (Export as SCV)?
Because currently, exporting file in Zendesk is applicable in all tickets status.
Hi Barbie!
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.
Jessie:
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?
Hey Darron! Sorry for the delayed response here!
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.
Hey Asad - I see you also posted this question in the Community forum and did get an answer over there.
Hi guys,
Hey Andrew!
You should be able to set up an Automation to do this for you! You can find that documentation here.
Hi guys, if a new ticket created by an agent is immediately submitted as solved, will the end user still receive this?
Hey Hannah,
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.
I hope that helps! Thanks again for your question
Hi guys and gals!
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.
Thanks.
@ Stephen Fusco
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?
Or have I misunderstood?
Thanks.
Hello,
I just had a couple of quick questions about moving tickets to 'Solve' and follow-up tickets to "Closed"
(1) By default, does Zendesk send an email notification to the requester when a ticket is set to 'Solve' or moved to 'Closed'?
(2) Is a follow-up ticket created when the requester replies to the email chain from the 'Closed' ticket? That what the FAQs seem to suggest but I wanted to confirm since it's never expanded upon.
Thank you.
Hi Andy -
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.
You can read more about the default triggers in this article: About the Support default triggers
With regard to your second question, yes, a follow-up ticket would be created when the requester replies to the chain from a closed ticket.
Hi,
I would like o ask if there is an effect on the report statistics or the ticket information if I submit a ticket as "Pending" or "Open" twice in a row let's say few minutes or hours in between?
Sometimes, I have to update the Ticket Field for reporting purpose of a Pending ticket and submit it again as Pending. Also, will that give alerts to the requester/those in CC? The same questions goes for the Open and Solved Tickets.
Thank you!
Hi Kim,
I will address the second question first. This would very much depend on how your triggers are setup. Most triggers for things like Comment Update for example require in addition to the ticket being updated that there be a public comment, so if you move it from Open to Open but do not add a comment it would not send another update.
Your first question would depend on the scope of the report, you can report on ticket status, and you can show how many times a ticket was put into the status, so hypothetically if that is what you are looking for that would count even if the status stayed the same after the ticket updated. Other than that it should not have any affect on reporting.
We have a globally acting team of support agents. If an agent needs help for himself by the top level agents at the headquarter, he raises a ticket which is assigned to the top expert group then. This means that the agent asking for help is the requester in this case.
Everything works fine and like expected as long as the ticket is not set to status "Solved" by our expert team. If the requester (= agent of the other team) replies to the solved ticket by mail, the status does not go to "Open" anymore like in case of a ticket by an requester (who is just an end-user).
Please let me describe a workflow which might make more clear what happens:
-> The ticket goes into status "Open" again (like expected).
but the ticket's status does not(!) change to "Open" again (what would be expected).
The ticket stays in the status "Solved", i.e. it is not visible by the "All unsolved ticket" view anymore.
What is going wrong here?
I would expect that in case of a reply to a ticket mail, the ticket status should be always changed to "Open" again independent if the ticket's requester was an end-user or an agent.
Hi Juergen,
I can confirm that this is actually expected behavior since the system is designed to only set the ticket status back to open after an end-user replies to the ticket. You'll find more information in our Why does a ticket not get reopened when the requester (who is an agent) makes a reply to a Solved ticket? article which I've attached.
However, you can create a trigger that will automatically re-open the ticket if an agent is the requester of that ticket. See sample trigger below:
Could you test the above out to see if you get the results you're looking for?
Dear Brett
Thanks for the quick reply, the link to the other article, and the possible workaround by a trigger. This is actually how I think that an efficient support should work ;-). Thanks.
P.S.:
I am wondering about the inborn rule that a ticket is not reopened in case of the current user is an agent. Based on your linked article it seems to be that I am not the only one fighting with this ;-).
Anyway thanks for the concrete hint about the workaround by a trigger. I expect that this solves the problem. Otherwise I will leave a comment again.
Kind regards
Juergen
Please sign in to leave a comment.