Why do solved tickets change to a closed status?

Have more questions? Submit a request

8 Comments

  • Svend Koustrup
    Comment actions Permalink

    Hi Zendesk

    Thanks for the reply to Danielle, which ansvered my initial problem of why my tickets are closed prematurely in relation to my automation set to 1461 hours. I now see, that it cannot be longer than 28 days. Why the effing ef does it not tell me that when I create the automation? And why this limit? Thanks for an otherwise really (!) great webapp!

    Best regards, SvendK

    1
  • Nicole - Community Manager
    Comment actions Permalink

    Hey Svend - 

    All tickets are automatically changed to Closed after spending 28 days in a Solved status. This is a system rule that cannot be adjusted or altered through the use of automations and triggers. 

    A good workaround for this is to use the on-hold status, which will allow you to keep a ticket beyond 28 days without it sitting in an open or pending status. 

    Several users have requested that this be made more clear in the automations dashboard, and we've passed that feedback on to our Product Managers. 

    As for the reason for the 28 day period, most users do not need a solved ticket beyond that period of time, and there has to be some cutoff for when a ticket moves into the closed status. Once it has been in closed for 120 days, it is then archived, which allows for faster loading of Views, among other things. 

    -1
  • Sergio Anarte
    Comment actions Permalink

    Hi Nicole, quick question, because I see some discrepances between different links in your documentation: 

    Here the documentation says: "after 28 days of inactivity in solved status"

    But then your comment say: "after spending 28 days in a Solved status"

    Question a) What if after being 10 days in solved status I change the value for a field...cause in your case the count will continue but reading the article, it seems like it will start from zero because there was activity (not in the status, but the ticket has activity, a field was changed)

    Question b) What if I change the status for a second during those 28 days (i.e from solved to open, and then from open to solved again). Will the count start from zero???

    Thank you

     

     

    0
  • Graham Paddon
    Comment actions Permalink

    Hi ZD Team,

    Wondering how you know when to optimise this rule (either by dialling the period up, or down). 

    Assuming the One-touch ticket rate works off the back of this automation (which I believe it does), wouldn't having this set incorrectly directly impact your performance on this measure?  For example, if I had this set to 24hrs, tickets will move to Close quicker and One-touch tickets (and 'First Contact Resolution', if using for this measure) will shoot up.  BUT, it might be that NEW ticket rate will increase because we're closing prematurely.  Make sense?  

    Ours is currently set to 96 hours as per default but I can see lots of NEW tickets coming in off the back of OLD closed tickets which makes me want to push this period out further.  How can I measure the optimum point?  AND, if I push this period back, what is the negative impact elsewhere (satisfaction response rate perhaps?)?

    Thanks

    Graham

    1
  • Svend Koustrup
    Comment actions Permalink

    Hi Nicole

    I'd would be nice to have your say on Sergios one year old comment :-)

    In regards to Grahams comment, could you change the statistics so it looks at the "last" Solved-date (if multiple) instead of looking at Closed date? I understand that the same ticket can be in several statistics in this way, but the stat would be better if we're not waiting for the Closed state. The ticket is solved when I tap the Solve button - unless it's reopened. 

    Graham - we're not using the stats that much, so we have 24 days (or whatever is maximum value) for solve->close state, as reopenings doesn't make much sense at us.

    Best regards, SvendK

     

    0
  • Brett - Community Manager
    Comment actions Permalink

    @Sergio and Svend, apologies for the delayed response. Looks like we may have missed this one! To answer your question, when altering a field on a Solved ticket the timer will not restart. However, if you were to switch the status of the ticket from Solved to any other status, then the timer would restart. 

    @Graham, most likely you'd need to do some testing to see where that optimum point is. You may want to create a view specifically for follow-up tickets and see how long after the ticket is closed these tickets are being generated. You can use the Ticket: Channel > is > Closed Ticket condition to create this view.

    Hope this helps!

    0
  • Katie Saddlemire
    Comment actions Permalink

    Want to vote up allowing more flexibility on either lengthening the amount of time it takes for a ticket to close OR with giving us the ability to edit ticket fields on closed tickets. 

    I would also like to call shenanigans on the notion that "most users do not need a solved ticket beyond that period of time". A) I don't believe this is based on use feedback, and B) you're taking functionality away from power users who want to make sure the metadata associated with a ticket is 100% accurate and do not necessarily always have time to do so within 28 days. 

    Why does "oh hold" not work. It negatively impacts time to resolutin. 

    1
  • Devan - Community Manager
    Comment actions Permalink

    Hello Katie,

    I appreciate you taking the time to share your feedback and perspective with us on this feature of Support. I empathize with your having to deal with this pain point, especially one requested by users like yourself numerous times. Assessing the needs of our customers plays a critical role in improving our products as we strive to include your needs in updates whenever we can.

    Regarding your feedback, at this time, this is not a change we plan to implement. We seek to make improvements and add updates to our roadmap by analyzing the needs of our users. However, we are not always able to resolve these requests due to the long term goals and macro-level impacts these changes can have on numerous critical variables throughout our product. Changes that on the surface may seem rather straightforward, in actuality, can be quite complex and even detrimental upon further analysis.

    Feedback on our products, however, is something we not only welcome but work to cultivate within our Product Feedback forums. I’ll be passing on your thoughts to our dev team personally and appreciate you taking the time to bring your perspective to our attention. I do hope you’ll continue to share your honest opinions with us so we can take into account the viewpoint of users like yourself when aiming to improve our products in the future.

    Best Regards.

    0

Please sign in to leave a comment.

Powered by Zendesk