Open vs. pending and on-hold tickets and why you should care Follow

One of the major benefits to using an online customer support software to handle your customer interactions is that unlike an email inbox, the interactions in a ticketing system have a defined end-point: you mark a ticket solved.  This closed loop process is important for both your company and your customers; it puts you both on the same page - an agreement that the issue or question has been resolved and ultimately closed.

But of course, there are a few steps between a customer sending a ticket and you marking it solved.  To handle these various stages, all tickets can be in one of five states (or, as you'll see on all tickets, five statuses ): New , Open , Pending , On-hold , or Solved . New and Solved might be self-explanatory -- they mark the beginning of the interaction and the end -- but what about Open, Pending, and On-Hold? By understanding and making use of these statuses, you can stay on top of your support workload and bring any outstanding tickets to solved in an efficient manner.

Ticket Status can be manually set within each ticket via the Status Dropdown, located at the bottom of the ticket.

An Open ticket is defined as a ticket assigned to an agent. Open tickets are the heart of your support workload -- they indicate those issues that you're working on. Once a ticket's status has been changed from New, it can never be set back to New.

Where this begins to be important is when you set up Views , Triggers , and Automations based on a ticket's status.  It is probably useful, for instance, to see a grouping of all your Open tickets; all your tickets that need to be solved.

But, of course, oftentimes to solve a ticket, you need to collect more information from the requesting customer, e.g. you need the specific text of the error that they are seeing, or you need their account number, etc.  So you write them back.  In those cases, you want to be able to move the ticket off the list of things that need your attention but at the same time not forget about it. This is why the Pending status is so useful; it's like saying: "This ticket is not yet solved but I'm waiting on information from the requester before I can work on it further."

The On-hold status is similar to Pending, and used to indicate that you are waiting for information or action from someone other than the requester, for instance one of your supervisors or an internal developer. On-hold is an optional, internal status. It can be enabled by an administrator, and if it isn't enabled, you will not see it in your status options. Ticket requesters do not see this status -- On-hold tickets appear as Open to your customers.

To see how these states might be useful, let's take a look at how you could set up a View that shows you all your unsolved tickets but groups them according to whether they are Open or Pending.  (Views are collections of tickets that you can customize according to your support workflow.)

To set up a new View , go to Manage > Views on your Zendesk Support admin page. Click on "add view" in the upper right. We'll keep this simple and just collect all our tickets that are not solved, or in this case "Less than Solved":

Next, we'll set the Format Options to display by Table , and then choose to Group the tickets by Status:



Now, when we update and return to this view, we'll see our tickets grouped according to whether they are New, Open, Pending, or On-hold.  This way, we can see those tickets where we've written back to the customer or internal expert for more information but they are separate from those that require our active attention.



When our customer or internal expert replies to us with the information we requested -- the error message or account info -- Zendesk Support will automatically change the status from Pending or On-hold to Open.  So the next time we look at our "All Unsolved Tickets" view, then, that ticket will appear in our Open list, and hopefully closer on its way to Solved!

Have more questions? Submit a request

Comments

  • 0

    Hey Owen: 

    Thanks for the follow-up. There's no way to customize that JavaScript based on the tags, to my knowledge. If you absolutely need the due date, you'll have to continue with your current workflow. As an alternative, you can create a custom field as a secondary type field and work off of that. You won't get the due date function with it, but you could build out some automations to remind your agents to work on those tickets. For example, if the ticket has a tag called revisit, you could create an automation that looks for that tag, and after a certain amount of time, will reopen the ticket and send a message to the assignee or third-party target as a follow-up reminder. 

  • 0

    Thanks, guys... I was a day too impatient to realize that.  It was great help to be able to find where to change that setting though.

     

    Great videos, Matthew... keep them coming :)

  • 0
  • 0

    Hmmm... Dan, that's an interesting point.  There is nothing you can do as a customer to change the status of a ticket - only agents can do that.    It is a workflow question on their part.  Best you can do at this point is add a comment letting them know the ticket says "Awaiting your response".  The status they would set it at is "Open" - which is what it should be in the most rigorous of work flow cases.  An open case is something that still requires work from the company in order to solve.

    The real question is whether a "Pending" status in Zendesk should be connected to one use-case: i.e. awaiting a response from a customer; or if it should be open to workflow interpretation and there is some other more explicit way for an agent to say "I need a response from this person".   I'd love to get thoughts on that question.

  • 0

    My support staff move all "Open" tickets to "Pending" when we send them to our ticket system for our programmers.  That seems to work nice, but when the programmers reply with a "Private" message the ticket status does not automatically change back to "Open".  So my support staff have no idea when something is resolved by a programmer.  Do "Private" messages not trigger the ticket to switch to the "Open" status like when an end user replies?

    Thanks!

  • 0

    Hey Matt, thanks for that. IMO (and I've seen this used somehow by the SurveyGizmo folks), there should be two pending statuses: Pending customer response, and Pending agent response.

  • 0

    Hi Chris, 

    The system will automatically change the ticket's status from Pending to Open if an end-user updates the ticket. Since Pending is a status given to indicate an agent has made a comment and is awaiting an end-user's response, a light agent's comment will be treated like a regular agent's comment and will not change the status back to Open.

    If an agent clicks the 'Open Tickets' box from within their agent dashboard, they will be taken to a list of their assigned tickets, grouped by status. There, they can see Pending tickets. They could also make use of the On Hold status. Though it will also not change back to Open with the addition of a light agent's private comment, it will be excluded from requester wait time and not penalize the agent when they're waiting on a third party's ticket update.

     

  • 0

    @Dan - Totally, I'll pass along your feedback.  In the meantime, here is another way of thinking about in our Feature Request forums: https://support.zendesk.com/entries/20968787-ability-to-tailor-the-pending-message-displayed-to-customers

  • 0

    For end users the 'Pending' status shows as 'Awaiting your response'. This is fine in the case of the 'Requester' but for CC's it's incorrect?

    CC's technically are part of the workflow by copy, so 'Awaiting your response' is misleading in this scenario. Especially if we've CC'd an End User from our team for assistance. 

    Is this a bug or intentional?

  • 0

    Is there a status to indicate that the customer support agent needs to do something, NOT the customer?

    I'm a customer and I often report bugs. Support agents acknowledge them, but it takes them a while to fix them, while the ticket is listed as "Pending" and I see " Awaiting your response »" on my dashboard, which is incorrect. The ticket is await THEIR response.

    What do I need to ask the support agent to set the status to, so that the ticket isn't "solved", but it's not waiting for my response?

  • 0

    Hi Mark, 

    This is intentional in the sense that we use the same label whether you're a requester or a CC and have done so as long as I can remember in Help Center. Web Portal also uses the same wording for both CCs and requesters on pending tickets.

    You do bring up a good point though, that the current wording might not apply in every situation, I'll forward your description to the Product team. Thanks for the feedback!

  • 0

    One thing I have noticed with pending tickets is that the user often does not respond, I'm wondering what the best practice to deal with these tickets are since I don't like seeing a 4-digit ticket backlog!

    I wanted to create an automation to change the status of these pending tickets but it didn't seem to let me? I was thinking either set them to Solved, under the assumption the user the user managed to solve their problem, or to Open so that it goes back on an agents radar and they can make the call on wether to follow up or close it.

  • 0

    Hey there @Gaim78.  The only thing that stops the clock is when a ticket flips from Solved to Closed (when it can no longer be reopened.  It's a tricky call to make on our end when to hit stop.  So "Total Resolution Time" as I said above is simply the total amount of time from when a ticket is created to when it is finally resolved.  There are other metrics that measure how long a Requester is waiting.  But for Total resolution time, it is entirely possible that a support agent does not fully answer a customer's question and so the customer re-opens it.  In this case the ticket wasn't fully resolved so the clock keeps ticking.  

    Does that make sense?

  • 0

    Hi Jason,

    When you activate the Satisfaction Ratings in your Zendesk, an Automation is automatically added to your Zendesk that sends the request for a rating out to the customer via email, and the customer can respond from the email. This should still be happening unless you deactivated or otherwise altered the Automation (or don't have Ratings enabled).

    The rating request goes out at some point after the Agent sets the ticket to Solved (24 hours by default, but you can change this if you wish). When the customer rates the ticket, the ticket remains in Solved status. The workflow I suggested doesn't have the customer actually setting/changing any statuses; it's simply using the Good satisfaction rating as the "Solved Approval" you mentioned, as well as using it as the condition to set those tickets to Closed right away which is the ultimate goal, based on my understanding of your use case.

    The other automations you have in place are perfect, because they'll catch the tickets that the customer never rated or otherwise responded to ensure that they're Solved and Closed in a timely manner.

    I would hesitate to use the Pending status in lieu of Solved when the agent initially resolves an issue...this is going to skew your Time to First Resolution metrics pretty significantly, and not really give you a clear picture of how long it's taking your agents to actually Solve tickets. But, of course, it's up to you!

    Does this help to clear things up a bit?

  • 0

    Hi there Chris - 

    Often, I find best practice in that case is to alert the person that you are closing the ticket, and remind them that they can reply and re-open it if they still have questions.

    You should be able to set an automation to do that. What sort of error/notification are you getting when you try and create it.  Here is a sample one that should work:

    Screen_shot_2010-06-17_at_1.59.38_PM.png

    Let me know if that is still not working for you.

  • 0

    Hey Guys, as per previous comments the time will stop counting when the tickets status is changed to Solved !! Right ?

    In case the end-user replies after 60+ hours , the ticket is received as an open ticket .. my question is will the timer start to count again ( as a new ticket ) or it will reconsider the original solution time of the ticket !!

     

    This will help me in in generating the tickets resolution time ( to count how many tickets been solved within 48 - 60 hours & 60 + hours )

     

    Thanks

  • 0

    Hi all, can any1 tell me why my tickets are coming in as open instead of new? i use a forwarded email in zendesk and the tickets what's coming in to that email comes in to my zendesk as open... 

  • 0

    What about the closed status - was that not available when this was written? Do you recommend still setting to pending when you need more info or to set to solved?

  • 0

    Matthew that trigger worked great but it also moved the ticket into pending when a private comment was made and I can not think of a use case why you would want to do that.  I was able to resolve by adding the comment is... Public condition and it worked.

  • 0

    I am trying to define a good workflow with the available ticket states and could use your suggestions.

     

    If "Closed" were a selectable state, My ideal workflow would look like this:

    1. Ticket is created and state is set to "Open"

    2. Assignee responds to requester asking for more information and state is set to "Pending"

    3. Requester responds with additional information and ticket is set to "Open"

    4. Assignee completes ticket and sets state to "Solved"

    5. Requester verifies ticket was resolved correctly and sets state to "Closed"

    a. If a ticket's state is set to "Pending" for a set time, an automation changes its state to "Solved" and notifies the requester

    b. If a ticket's state is set to "Solved" for a set time, an automation changes its state to "Closed" and notifies the requester

    c. The "On Hold" state is used for tickets that contain requests that cannot be completed now but should not be closed

     

    Since "Closed" is not available for selection by a requester, we have to change the state to "Pending" for both requesting additional information and ticket completion. Then the requester verifies the completion and changes the state to "Solved".

    Ideally, I would like to not have to use a single ticket state for two different purposes. The only solution I see is redefining "On Hold" to be used for requesting additional information and leaving "Pending" for ticket completion.

    What are your thoughts?

  • 0

    Dear Matthew,
    I would like to know if when the SLA stops counting when I change a ticket status to Pending.

    Thank you.
    Railer

  • 0

    If someone puts a ticket into pending status I really, really, really want to know why. Especially if it's been escalated to a 3rd party (for reporting puposes and SLAs with external suppliers you can see it's necessary for me to pull pending stats out). Short of manually going through all the tickets in pending status that don't have a pending reason set  I can't see any way round this. It would make sense, to me anyway, to have another "Required" checkbox in the Ticket Fields edit box so I can force a customised pending reason to be set, just as I can force a customised "Solved" field to be filled in.

     

    Maybe someone has a cunning way of doing this.

  • 0

    Hi Jason,

    Perhaps you could incorporate the Satisfaction Survey response into this workflow? The "Closed" option isn't available for end-users, but you can use Triggers  and Automations to set the status to Closed once the customer has rated their ticket.

    I did some testing on this and if you set up a trigger to close the ticket as soon as the rating is made, it'll close the ticket but the satisfaction rating won't actually register.

    So what I might suggest is setting up an automation to set a ticket to closed after a Satisfaction Rating has been made by the requester; since automations run every hour, your rated tickets won't be hanging around in Solved status for very long after the rating has been received. You could set it up to close the ticket regardless of whether the rating was bad or good, but then you wouldn't be able to follow-up on the bad ratings to try and turn that frown upside down so you might only want to run it on the good ratings.

    That's the best workaround I can think of to "allow" your end-users to set a ticket to Closed. And you're already using automations to take care of tickets that are lacking an end-user response after X amount of time, so that'll prevent tickets from otherwise hanging out in Pending or Solved status for an inordinate amount of time if your end-users don't respond to your agents or rate their solved tickets.

    Hopefully that helps! :)

     

     

  • 0

    One way to work around this until then is to utilize a custom boolean field, a checkbox, and label it On Hold.

    http://www.labortimetracker.com/features.cfm

  • 0

    @Ian, I am not sure I follow your use case, but let me see if I can clarify: do you want your agents or your customers/end-users to provide the reason a ticket is going into pending?

    By default, only agents can manually change a ticket status, so assuming you are talking about your agents adding a reason for putting something into pending (waiting on customer reply, for instance) - you could add a **Multi-line ticket field **called Why Pending?, but there is currently no way to make a field required based on the ticket status (i.e. "make this field required if this field says pending").

    But explain a little more your use-case - what's an example scenario? 

  • 0

    Hey Jessie, Thanks for the reply.

    I do like your idea but I have had a difficult time getting people to use the satisfaction rating. They are typically communicating through email only and rarely set status, or anything manually.

     

    So, what I am testing now:

    1. Ticket is created and state is auto-set to "Open" 2. Assignee responds to requester asking for more information and state is set to "On Hold" 3. Requester responds with additional information and ticket is auto-set back to "Open" 4. Assignee completes ticket and sets state to "Pending" 5. Requester verifies ticket was resolved correctly and sets state to "Solved" Automations 1. If a ticket's state is set to "Pending" for 10 days, an automation changes its state to "Solved" and notifies the requester. 2. If a ticket's state is set to "Solved" for 4 days, an automation changes its state to "Closed" and notifies the requester. (The only way to set the “Closed” state is through an automation)

    What this does is notify the requester that a ticket was set to solved and if they think it should remain open, they simply reply to the ticket, which changes its status back to ‘Open’

     

  • 0

    HI there @Railer, sorry for the delayed reply - SLA counting does not currently stop when a ticket is marked pending.

  • 0

    Hi Matthew,

    It's the agents I want to force to put in a pending type.

     I already have a custom field for 'Pending Reason' but it's all too easy to forget to fill that in. Then I have to go and pull out all the tickets with status as pending but pending reason not set and go through them manually to make sure they are classified. And then the pending reason needs to be set again when the ticket is put back into 'Open' status. Very time consuming and prone to mistakes.

    Basically the same functionality as the "Required" checkbox in the Ticket Field edit page gives me for solving issues, i.e. I cannot pend a ticket unless that particular field is not null.

    We are maybe a bit rare in that we have hundreds of pending tickets. Most of these don't have a pending reason set on them because I only took over the helpdesk a few weeks ago and there wasn't any pending reason field. There's nothing much I can do about that except go through them manually, one by one. I'd like to avoid getting into that situation again.

     

     I suppose the only thing I can do is to make a view tp ick up any recent pending tickets that don't have a pending reason set. The words horse, stable door and bolt spring to mind there though.

     

     

     

     

     

     

     

     

     

     

  • 0

    Hi Jay!

    If you have a trigger set up that automatically assigns the ticket to a group or agent when it's created, the ticket will be created in Open status, rather than New. If the ticket comes into your Zendesk and remains unassigned, it will be in New status.

    I hope that clears things up!

  • 0

    I can't think of a situation where I want the status of a ticket to remain open - instead of pending - after I've responded. Is there a way to have the status set to pending by default? Now I have to change the status manually from open to pending for each ticket I handle, and that gets a bit annoying.

Powered by Zendesk