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.
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!
@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 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.
The "where" is probably going to be the new Help Desk in the future. But that's not fixing any of this.
All of those changes have a cost. For example, if you move tickets to an archived pipeline (as we have done too), now it's more work to find tickets regarding any particular topic, because you have to search more places. And there's still unrelated junk getting associated to those archived tickets, which really impairs your ability to review what happened during a past interaction.
Ultimately, to be a usable ticketing system and not just a semi-usable hack, tickets need consistent IDs (i.e., fix the bug that changes the ID during a merge) that appear in the subject line of emails, association of incoming emails need to be one-to-one (i.e. based on those IDs) and not one-to-many (or one-to-everything-ever which is how it seems to work currently), closed tickets need to stay closed, and new incoming emails to closed tickets need to spawn new tickets. There's nothing here which is difficult from a design standpoint, Hubspot just needs to decide they are actually going to build a ticketing system and not just use their generic all-purpose template with the word "Ticket" at the top.
I don't disagree with anything you said. I agree 100% that these things should likely be resolved and addressed in order for this to be a proper ticketing system.
Also, I agree that some of my suggestions are really hacks to work around things that are fundamentally wrong. Unfortunately, this thread based on my original post started on August 19, 2020. Since then nothing about the underlying issues or concerns that I've expressed or that many many others have upvoted, have been addressed. So although the suggestions might be hacks....they are intended as pragmatic suggestions for those who opt out of the alternative....which is to get a different ticketing system.
"There's nothing here which is difficult from a design standpoint". I think that is true....if you are designing a ticketing system. The fundemental design issues here is that HubSpot is a CRM first and a Ticketing system second. The behavior of the associations of email and tickets, makes sense if you are thinking about this from a CRM point of view. I agree with the one to one service centric concept for association. Believe me, I've made my thoughts known many times to their product management teams. Unfortunately. there is some functionality in here that someone somewhere along the way, thought made sense, but for the life of me I have no idea how.
My personal favorite:
Hubspot Integration with Gmail account enabled.
Google Chrome Sales Extension installed and enabled
Default Associations enabled for "Existing Contacts" "New Contacts" "Companies" and "Tickets"
If you compose a new message to an exisiting contact that is in Hubspot and send it. The Default Associations - Ticket, automatically associates the new email with existing tickets. Which existing tickets? The first three tickets that were ever associated with that contact. No matter how old the tickets are, not matter if they are closed or not. When I brought this up as a bug and demaning it be fixed. The response I received was.....WAD. Working as designed. My feed back was....well whoever designed that should be fired. Moral of the story....don't let people use the default associations - tickets option. But I digress.
I am not familiar with a bug related to merging ticket and ids changing.
My observation and understanding has always been the following
Ticket ID : 12345
Ticket ID : 67890
If you merge ticket 12345 into ticket 67890, everything that was associated with Ticket 12345 gets merged with Ticket 67890 and Ticket 12345 no longer exists. Is this not the case?
When you're in ticket 12345 and merge 67890 into it, every blank field in 12345 should be replaced by the contents from 67890, and all the associated activity should be added into 12345. But overwriting the old ticket ID with the newer ticket ID is not correct merge behavior.
Conversely if you're in 67890 and merge 12345 into it, the remaining ticket should be 67890.
I'm writing to suggest an improvement to the Service Hub ticketing system. Currently, tickets can be reopened if a customer replies to an email associated with a closed ticket. This can be inconvenient for our Client Services team's workflow.
Here's a suggestion: A new option to permanently close tickets, even if there's further communication in the email thread, would be a valuable addition to Service Hub. This would streamline our team's processes and ensure tickets are properly managed.
I'm confident that this change would benefit many Service Hub users. Thank you for considering this suggestion.
Yes please! I would like to set per pipeline, if a customer replies to a closed ticket, it should create a new ticket with only this specific thread/conversation and contact + company associated.
With some help from a HS support person I have greatly reduced the reopening of old tickets. We call them "Zombie Tickets" as they keep coming back from the dead. The fix required that I add a little bit to my automation and I have gone from spending about 30 minutes a day of Zombie killing to virtually Zero time spend checking and killing. In the screen cap below, I added this step to my Waiting on Us phase and our Waiting on Customer phase. To get it to work quickly you have to restart the tickets that are in these queues so you can root out any zombies hiding in the ticket forest but this simple step has been like a give from God!!!
@RodChristen your screenshot didn't come through – could you try to repost? Very interested to see your "Zombie Tickets" solution. I do wish Hubspot would just fix this. It's a solved problem in every other helpdesk I've used.
The automation is fairly simple. In your workflow add a step that checks to see if the criteria "Ticket Status has been closed". This checks to see if the ticket was ever closed in the past. Then if it had a closure in the past the ticket will go to Closed again. There is a down side, if you want to force a ticket back open it gets a little tricky but this kills the Zombies really well.
See if this image works better than the last one I posted.
We call the reopened tickets, "Zombie Tickets" since they were once Closed (Dead to us) and then a stray email or other activity opens the ticket back up. The solution is pretty simple with a couple caveats. I have attached a jpg of the start of the workflow (automation). To describe the fix, I have the automation look at the ticket history and if the ticket was once closed it just closes the ticket again so the repeat/Zombies are put down for good with one "Or" gate added to the beginning of the workflow. We use New, Waiting on Us, Waiting on Customer, and Closed as our phases in the workflow. I added the steps shown to the Waiting on Us and Waiting on Customer phases.
Then the first caveat, if you truly want to have a ticket reopened it might require a little extra effort but for our operation we generally only close tickets when our customer states that the problem is finished.
Second caveat, I found that when you have completed the editing of your workflow you want all the existing tickets to run through the workflow from the start. This will also close any Zombies that you have that you haven't noticed yet.
We've been using this addition to our workflow for over a month and I have only seen a couple (2 or 3 tickets) that were able to outsmart the workflow and we were having a dozen or more each day. It really, REALLY worked for us!!!
The workflow options have improved from when I originally wrote this post. That said, I agree that the workflow you provided does the ticket has reopened and it does trigger a workflow to re-close the ticket. The problem that I see here is that when a ticket re-opens and closes again, the close date changes and that will mess up your ticket stats.
Ticket 123
Created date 2024-01-01
Close date 2024-01-07
time to close: 6 days
Customer replies to an old message associated with Ticket 123 on 2024-07-01 triggering the ticket to reopen. The workflow you outlined above....detects that the ticket was previously opened and changes the status back to closed.
Ticket 123
Create date 2024-01-01
Close date 2024-07-01
Time to close: 184 days.
So the work flow works if aren't worried about the ticket stats....but if you are concerned about ticket performance metrics.....this might create some challenges for your historic reporting.
That seems like it will prevent the ticket from reopening, great. But if the ticket was reopening because the customer responded to an old email with a new inquiry, their inquiry is lost and will now not get answered, which is not a great solution.
This functionality already exists in Deals Pipeline, it would be great to have it in tickets as well. I'm having trouble with reports analyzing how long a ticket has been open, as some people keep reopening it. Blocking would be ideal.
@RodChristen wait I'm confused. How do you respond to a customer's new inquiry when they reply back to a closed ticket? From your screenshot, it looks like you just close the request again, without actually helping them?
I can't believe this thread has been going on for over 4 years now. It reinforces that Hubspot treats Support as an afterthought. Look at how many feature improvements Sales and Marketing get in comparison.
Debe ser un usuario registrado para añadir un comentario aquí. Si ya está registrado, inicie sesión. Si todavía no está registrado, hágalo e inicie sesión.
