Option to automate resolving (and triggering an email) of tickets in a certain sub-status for x number of days

[Gareth Noon]

We have a number of tickets that are still open (on-hold) awaiting a customer response. We are looking at the possibility of using automation to send an email from tickets that have been in the “Awaiting Customer” sub-status for x number of days (e.g. 30 days) and then set the status to resolved at that point, so that the ticket is then automatically closed after 7 days.

The email could state something like "this ticket will now be resolved due to inactivity. However, you may re-open it at any time within the next 7 days if this issue is not yet resolved. Please respond to this email to re-activate this ticket.

We have a third-party provider that uses this functionality with their Zendesk system and so wondered if there is an alternative within Hornbill Service Manager.
 

 

[Berto2002]

@Gareth Noon I think the reason you're stuck is that you're using sub-status. "Waiting Customer" is for if you are asking questions etc during the lifecycle, not asking them if you can close it.

If you think you have done the work, resolve the Request and then put in a Suspend node which is waiting for status change with an expiry of 30 days.

If the customer goes to the portal and updates the Request, it gets set to Open (status change) and this is selected by the subsequent decision to come back to your team. If not, it closes.

The short answer is that you need the suspend nodes with expiry. You can use this to follow the expiry of a Waiting Customer node but why not just resolve it?

 

[Gareth Noon]

@Berto2002 Thanks for this. These are situations where we have asked the customer for more information etc though, and then they haven't come back to us.. So we wouldn't ask them a question and then resolve it at that point. I'm trying to catch and resolve the tickets (in an automated way) where we have asked for more information but the customer has then never come back to us.

[Steve Giller]

I have seen this done, I can't, unfortunately, remember who by, and it requires a highly-structured workflow with a number of potential opportunities to introduce "errors" which are actually simply the Workflow taking an unexpected route due to a scenario that is not catered for.

I suspect you're looking for something that will find any Request at any stage of its lifecycle that has been on hold for 30 consecutive days which isn't available - however you could build a workflow that simulates that behaviour with the Suspend->Await Off Hold node set to expire after 30 (working) days and taking the reminder branch if it's expired.