I have customers who have a habit of replying to an old email related to a previously closed ticket as a means to initiate a new ticket. As you can imagine this automatically reopens the old ticket and appends the details of a completely unrelated issue to the end of ticket that was previously closed.
There is currently no way in hubspot to avoid this or prevent this from happening today. Regardless of how long a ticket is closed it will always reopen when an email is received that is related to that ticket. To say this is unfortunate is an understatement.
Zendesk has the concept of an archived ticket. Once a ticket is in a closed state for a configurable period of time, the ticket is archived. This archived state does not remove the ticket from the system, it puts it into a sort of read only state that;
Will not reopen with an email response
Cannot be reopened manually
Cannot be edited.
Zendesk provides the option to create a follow up ticket that references the archived ticket. This new ticket will have a link to the old ticket and does have a true link at a reporting level to the old ticket.
So what is the suggestion I am making?
Add a reopened state for tickets that were previously closed and reopened as a result of some action.
Add a reporting field that has the following attributes, reopened source (manual, email response, workflow action)
Add a property to indicate the reopen time.
Add a status that is systemically assigned based on the ticket being in a closed state for some configurable period of time. example 5 days.
For 5 days after a ticket is closed, the ticket can be manually reopened or be reopened due to a workflow action (receipt of an email or call associated with that ticket)
Tickets that are reopened should be in a reopened state or have some attribute data to indicate that the ticket was closed and was reopened during the 5 day interval.
Tickets that are not reopened within the 5 days will enter an archived state. These tickets are closed, can be reported on, can be referenced, and be the basis of follow up tickets. But they cannot be reopened and they cannot be edited.
I am certain that there are other customers who would benefit from this type of option.
Sí, definitivamente es una necesidad el poder archivar o bloquear los Ticket cerrados. Al poder reabrirlos en cualquier momento, hace que mis indicadores se ensucien y no sean realistas.
This is a must-have and such a pity Hubspot hasn't released such a feature since 2020. We can't even update Conversation status in workflows (as we do in Tickets).
I am amazed that this feature has not been implemented despite having high demand for it since 2020 and the feature being seemingly very basic. Please consider escalating the priority of this feature request as allowing previously closed tickets to be re-opened not only ruins time-to-close SLA tracking, but also allows our customers to bypass our support agreements by simply using an old email thread from a ticket raised during their trial period.
I created some addition steps to my Waiting on Us and Waiting on Customer phases of our workflow about 6 months ago and it has worked great for our operation. It has some short falls (if a closed ticket needs to be reopened it's a difficult manual process but in our business, we haven't needed to do this very often).
We refer to tickets that are self-reopened as Zombie Tickets (back from the dead. Here are the steps, you can modify for your needs:
Hi everyone! Sophie from the Service Hub product team here. There is currently a private beta available to Enterprise customers that allows users to manage ticket re-opening behavior via workflows. The beta adds a new workflow action that can "copy" the new message and properties from the re-opened ticket into a new ticket. This action can also close the original ticket again and set the close date property back to what it was originally to maintain SLA and reporting consistency.
There is also a template for this workflow so folks don't need to build it from scratch. To use the template, navigate to workflows > create workflow > "from template." The name of the template is "Control if closed tickets open based on new replies" (find it more easily by clicking the "Service Hub" tab on the left hand side of the page. Quick note here: the enrollment criteria "last closed date" should be customized depending on your process, e.g. "last closed date is more than 5 days ago" if you want to allow closed tickets to re-open within 5 days of being closed, 3 days, etc. If you never want closed tickets to re-open and instead have new replies on closed tickets always create a new ticket, you do not need this property in the enrollment criteria.
By using workflows for this beta we hope to give folks as much flexibility as possible to tailor these ticket re-opening rules to their team's process. That said, we plan to iterate on this functionality and improve it based on your feedback! Any feedback and insights that folks can share here is much appreciated and will help us to improve how this feature works.
@smerrow can you please post a link to that beta, or give the name of it? I've searched and can't find it. We already solved this with custom ticket statuses and a workflow, and I'm hoping we can layer this new update into what we've already built.
@VCunningham of course- the name of the beta is "Ticket Re-Opening Management in Help Desk." Please let me know if it doesn't appear in the Product Updates section of your portal when you search this!
Hi @smerrow thank you for posting this update, this is a much-needed feature! However, I couldn't find the template you mentioned anywhere in the Product Udates section.
I noticed you said this is for Enterprise customers. Does this mean that our paid Sales Hub Professional plan still can't handle re-opened tickets? If so, I hope this is an error or oversight. Gating this remedial function behind a plan upgrade would feel pretty outrageous. I hope I'm just missing it?
Could you please let me know where to find it on our Professional plan, or any workaround for the same functionality? Thank you!
@rdavid4can confirm that as of now the Beta seems ot be limited to SERVICE Enterprise. Luckily we already have that hub level, but I agree it seems like a steep paywall for this specific functionality... Perhaps this will change with the full feature release🤞.
@smerrow I could be getting this wrong, but it seems that the current enroll trigger is conflicting with the uneroll one? Both are set to "Ticket reopen date is known". I expect the uneroll trigger will then take priority and prevent the trigger + actions?
Not sure how feasible it is to scale this concept, but ideally this would be turned into a simple switch setting that can be applied per channel in the Help Desk! Being able to decide at that level what mix of source + SLA should or should not lead to reopened tickets would be the ideal scenario for our use case. I do see how by tweaking the workflow it can be made to be pipeline relative, but it will surely take more work & maintenance that way. Just an idea 😁!
We solved this issue almost a year ago by just adding a couple steps to your Waiting on Us and Waiting on Customer workflows. The one downside is that you can't reopen a ticket once it's closed.
I was so hopeful when I saw the update from @smerrow. I am added to the beta and I added the worflow from your template, but cannot get this working. I even worked with HS support team to try and it still does not work for us.
Hi @lsamuelson8 ! I have a hunch that the reason this isn't working for you is what @ABeian mentioned above. There was an error where the unenrollment criteria was conflicting with the enrollment criteria, which would certainly cause hiccups. We have removed this from the template, but for workflows that have already been created I would recommend removing the un-enrollment criteria.
Thanks so much to the folks who have shared feedback, flagged issues, and provided their thoughts- we really appreciate it and it's been incredibly valuable as we look to evolve this feature. The goal with this first iteration was to provide a configurable option using an already-familiar tool (workflows) to our beta cohort, and have that serve as the foundation for a simpler experience that suits a wider audience and range of use cases. While we don't currently have a timeline to share, that's the direction we're headed. Thanks again!
