On-Hold Auto-Chase Mechanism

[dwalby]

Hi all,

Has anyone successfully implemented a auto-chase/auto-resolve mechanism? In scenarios where an analyst has contacted a customer via e-mail and placed a call on-hold, instead of the analyst having to manually follow up, is there a way a reminder e-mail can be sent after a set period of time? Then if no response received after X amount of attempts the request auto-resolves?

Thanks in advance

[Steven Boardman]

@dwalby thanks for the suggestion, we will look at the auto-chase and auto-resolve after x chases aspect of this and see what is possible..

 

[dwalby]

@Steven Boardman  Thanks

[dwalby]

@Steven Boardman - sorry to chase, are you able to provide any suggestions on how to achieve this? 

[Steven Boardman]

@dwalby i'm afraid not at this point.  The on-hold functionality as is, won't support this. Any suggestions i can think of are not really practical in giving you what you are looking for here i'm afraid. 

We have a story to see what we can address with this requirement but it is not currently scheduled and therefore no ETA on it.  Obviously as this changes we will post back here.

The only thing which may come close to this is would be logic built via the business process engine with auto-on-hold until, followed by a notification and place immediately back on-hold for another period (but of course this is not fluid on a request when you may need to put the request on hold at any point and possibly multiple times),  what you need is the ability to set rules around your on-hold statuses. 

 

[HHH]

+1 for this mechanism

[Martyn Houghton]

@dwalby, @Steven Boardman

We have been considering the same thought of thing.

Though I have not implemented, when a request is put on hold it does have a on hold until date and with ability to auto set the sub status on customer update and off-hold,.

By placing a Get Request Details node after the Place On Hold node, you could check whether the sub status has been set to 'Off Hold'. This would indicate that there has not been a customer update and therefore you could branch in the BPM to send an email chase, looping back to put it on hold. With the loop you could also attempt to increment a custom field to count how many times it has been chased and have a further branch to set resolve the request based on no response.

Cheers

Martyn

 

[Jeremy]

Can you have a parallel process with a wait for Request Update and an on hold?

So if the request is updated it comes off hold with a specific status or after a set time it comes off hold with a different sub-status, then you can make a decision based on this and send an email or close, to check how many times the email has been you could update a custom field with a number and then once it gets to 3, 4 etc you then auto close....

No idea if that would work but in theory...maybe

[dwalby]

@Martyn Houghton did you ever have a go at implementing something like this?

[Victor]

I know @Keith has such a mechanism implemented for some requests, maybe he can offer some assistance?  

 

P.S. Sorry to throw you in the mix but we could use your advice here  

[Keith]

Actually @Victor my process is related to after the request has been resolved whereby we want to "encourage" users to close the request (assuming the resolution is working of course). I have configured a 3 stage mailing which essentially waits for the status to change from resolved. After a period of time I send a mail, then set another wait status change and repeat. We do this 3 times, using three slightly different mail templates with increasingly stronger statements.  After the third attempt, I close the request automatically. 

This really helped in getting our request moved from Resolved.

[Michael Sharp]

Does Hornbill support escalation actions?  i.e. email to agent, then supervisor etc?  Realistically this kind of automation is badgering end users unnecessarily and doesn't portray quality service in my view.

[Keith]

On 5/21/2019 at 12:08 AM, Michael Sharp said:

Does Hornbill support escalation actions?  i.e. email to agent, then supervisor etc?  Realistically this kind of automation is badgering end users unnecessarily and doesn't portray quality service in my view.

I guess your view depends on your customer base. For me, my customers are all internal to my organisation. At the same time our auditors demand that we are not able to close a request on behalf of a user, they must do it themselves. So, without "badgering" the user the closure rate is very low. Whereas, it increases significantly if we "remind" users that they have not closed their requests. The term "Horses for courses" springs to mind.

[Michael Sharp]

On 5/22/2019 at 10:47 AM, Keith said:

I guess your view depends on your customer base. For me, my customers are all internal to my organisation. At the same time our auditors demand that we are not able to close a request on behalf of a user, they must do it themselves. So, without "badgering" the user the closure rate is very low. Whereas, it increases significantly if we "remind" users that they have not closed their requests. The term "Horses for courses" springs to mind.

Hi @Keith, appreciate the explanation thanks.  I've not come across an audited helpdesk in that fashion before so makes absolute sense in that regard.

Regards,

Mike.