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.
So in your work around, the reason why it does not reopen automatically is because the pipeline has only a single status, archived, which I assume is a closed status. I am curious about the workflow that facilitates the creation of the new ticket with the previous details. Is this something you can share here or with me directly?
This sounds like something that might work for my use case. If only I could get the auto association 'feature' to behave as it should, I likely wouldn't have as much grief with the current closed/reopen functionality.
I move older tickets to a new pipeline with one status 'Archived' and I run this workflow. In the email, I notify the customer, and in the create record I create a new ticket.
Thank you for the reply. In terms of the new ticket creation. "Ticket: Ticket Name" refers to the original ticket, or the new ticket? I am just wondering how this preserves a reference to the original ticket that had been archived.
Absolutely agree. The Hubspot support staff themselves have advised me they have the same issue and need to go through their stats and explain them, which seems like a huge waste of time.
MVP I'd say is;
When a ticket is closed, if a customer replies to the thread outside of the user determined ticket closure period, it creates a new ticket, referencing the first.
We really could use a feature where we have the system create a new ticket after it has been a certain period of time from the initial closed date. After a certain period of time, we find that the reply that reopens the ticket is usually no longer relevant to the previous request. This makes it hard to track our data we report on and client communications through tickets.
We have the same issue and it is getting really bad for our ticket management. The ability to "permanently" close tickets and open new ones after a set period (or something comparable) is pretty standard for most ticketing systems.
Clients replying to old tickets with new issues is a ticket managment nightmare . The tickets should closed and any replys should create a new ticket. Also if there is a reply to an agent off that day or on vacation, it causes major delays in responding the client. Our time to close, time to respond, count of tickets metrics are all being negatively affected by this issue.
We absolutely need the ability to archive a ticket (ie no properties or activities can be updated) and control over which tickets are archived and when (eg when it reaches certain stage/s in a pipeline, eg X days/weeks after being in that stage etc)
The workaround to move ticklets to a new pipeline with an archived status makes reporting a nightmare (we would have to create 2 extra properties (previous pipeline, and final status in previous pipeline) to capture this information which is critical for reporting
As the originator of this thread I agree that this is needed in a big way. I have considered at length the work around you described and have used it to a limited degree for CES surveys, if you haven't started down that road it has similar issues.
Your message actually made me think about something that I had actually previously missed which is restricting the ability to make changes. Previously I was concerned about tickets reopening when a new message arrived, which is a pain. Moving it to a different pipeline is not a desireable solution, but it works in some respects.
What your message made me realize is that, "Closed" is just an attribute of the ticket. Even if a ticket is in the "Closed" status, it can still be updated, there is nothing that prevents a ticket from being updated. In the absence of a true archive status (not closed), you would have set field level persmissions to restrict who can make changes. I do not currently have access to the enterprise subscription level where field level permissions are available, but if there is the ability to make the field level permissions specific to a pipeline and a user group, I can imagine a way to achieve more of an archive state than what closed offers today.
Thanks for the feedback - as an enterprise user I am able to control fields/ticket status's by either user or team, which mitigates the issue (restricting who can modify a ticket once resolved) but ultimately is not what is needed
To me its a no-brainer that when a ticket is marked as resolved it is not adjutable - as to how to identify a ticket a resolved, treaintg this as the final stage is a pipeline might work (albeit we have several resolved stages per pipeline so would need to add a custom poperty to reflect this, esp for reporting purposes), otherwise having a mandatory Hubspot property per ticket could be another answer
I have a challenge when creating the new tickets. When someone emails a closed ticket, there is content in their email that contains their new question. Has anyone found a way to include that content in a new ticket?
When you are on Settings > Tickets > Pipelines Tab > Automate
Hover over the individual trigger and click View Workflow
Now this workflow is uneditable, so go to the top-right and create a clone
Now you can edit the clone with new trigger conditions such as Ticket Status is None of Closed (that way if you're responding to a closed ticket it won't reopen)
You can also do this if you don't want Customer responses to Closed tickets to re-open the ticket.
Just make sure to go and uncheck the original trigger like I did above, this turns off the original uneditable workflow, but your clone will still be active and working.
Or for people who want to make it so that it creates a new ticket you could potentially create another branch where if Ticket Status has not updated in last 90 days AND Ticket Status is Closed >> Enroll in another workflow.
Then you make that new workflow which has no enrollment trigger. (This is so that it won't ever activate unless they met the previous conditions)
The new workflow would have 'Create Record: Ticket'
I'm just not sure how to populate the ticket yet, maybe someone else can experiment with this and get back to me.
@AGreen3 When you create a new ticket, you can go to the contact's email history, and associate the email from the old ticket with the new ticket. You'd also disassociate it from the old ticket. The catch: when you reply, you then need to ensure you create a new email thread, rather than replying to the previous message. Otherwise...when the customer replies again, it will reassociate the thread with the old ticket, leaving you with two tickets that have the same email.
It's genuinely a bad user experience for all of us. It's time consuming to say the least. I love the archive pipeline workaround suggestiion, but we have 3 different user types so we have three pipelines just for users, while also having a Misc/Junk pipeline. To do this workaround I think we'd need 7 total pipelines in order to continue to accurately report where tickets are coming from, creating it's own set of potential issues.
So this issue had been bugging me for about a year. I sat down a couple of weeks ago and figured out an automated way to handle reopening tickets. A bit of Saturday afternoon well spent. I wanted to share with you all to help.
First, create a new ticket property to keep the original close date of the ticket. I called mine 'Ticket status 'Closed' date'. Next this simple workflow to populate it.
Workflow 1
Enrollment criteria: -Ticket status is any of 'Closed'
Step 1 Set property value
- Set a date stamp ' Ticket Status 'Closed' date
Now for the real workflow. What we are basically doing is when a customer replies to a closed ticket, reopening it, we're triggering the creation of a new, associated ticket, complete with the details of the original. We then close the ticket again and set the original ticket close date back to what it was originally. This will keep your reporting intact, even if the customer replies to the new ticket after it closes, as the workflow will run again on the new ticket. I've set 5 days as the criteria for running the workflow, but adjust this to your own standards.
Workflow 2 Enrollment criteria:
- Ticket status is any of 'Customer replied' - Ticket status has ever been any of 'Closed' - Ticket status 'Closed' date is more than 5 days ago
- Ticket status 'Create date' is more than 5 days ago.
Step 1 Create record - Create ticket - Assign to 'Ticket's existing owner' - Give the ticket a name that indicates it's a reopened ticket. - Ticket pipeline and status - New (support) - Description: "Reopened from 'Ticket ID' 'Ticket Description'." - Associate ticket with - I ticked all the boxes and set about 90 days for history. You could go back further if you want. But you'll always have the original ticket ID to look up anyway.
Step 2 Set property value - Set ticket property 'Ticket pipeline and status' to 'Closed'
Step 3 Copy property value - Copy ticket property 'Ticket status 'closed' date' to ticket property Close date
Let me know if you have any questions about this. It's been running a week now for me and is working perfectly.
Do you all actually use this forum as a place to glean development ideas? Or is it just a place to send customers as a way to not answer their support questions with solutions? As far as I can tell it is the latter.
@JimyMason This script is great, but I'm running into an issue where the date that gets copied is always a day early. ie: Original Close date is 11/29, but it gets copied as 11/28 after the script is run, even though the date stamp still reads 11/29.
