Auto-Chase Requests

[dwalby]

Hi all,

Currently our analysts spend a lot of time chasing customers/users for a response for additional information or confirmation of resolution. Is it possible to build a BPM that can automatically send a chase e-mail to the customer and/or reminders for the analysts to call the user?

We generally work on a 3-strike rule, if the user hasn't responded or we've been unable to get in contact with them after 3 attempts (via phone, IM or e-mail) we then resolve/close the call.

I'd also be interested to understand how others approach handling requests which remain open due to a lack of response from customer.

Thanks in advance

[nasimg]

Hi @Dwalby

We haven't automated this (but good idea) - we have a 3 strike rule, try and contact the customer (make sure you update the ticket to say so) then resolve. In between the chases I suggest putting the ticket on hold (so you don't lose SLA).

Nasim

[Dan Munns]

@dwalby

We also use the three strikes rule. We have on hold statuses of 'Strike 1' and 'Strike 2' after that the analyst emails to say why the call has been closed and closes the call. We also do 'We tried to contact you...' emails from snippets after each attempt at contact so people can't say 'You never called me.....'

Unless we are told otherwise (annual leave / sick) we will try at three different times on three days during the week and after that it's closed. We don't hold calls open with no contact for any longer than 5 days.

It would be useful for emails to be sent based on a substatus being set, i.e. Call placed on 'Strike 1' substatus - Send 'Strike 1' email template to customer but to be honest I think that is a little niche and the snippet provide a two click email which is logged on the timeline. 

[samwoo]

20 hours ago, Dan Munns said:

It would be useful for emails to be sent based on a substatus being set, i.e. Call placed on 'Strike 1' substatus - Send 'Strike 1' email template to customer but to be honest I think that is a little niche and the snippet provide a two click email which is logged on the timeline. 

What a fantastic idea!!! ++++++1

Like having an action set, where we can define actions that can occur when a sub-status is set

[Victor]

21 hours ago, Dan Munns said:

It would be useful for emails to be sent based on a substatus being set, i.e. Call placed on 'Strike 1' substatus - Send 'Strike 1' email template to customer but to be honest I think that is a little niche and the snippet provide a two click email which is logged on the timeline. 

@samwoo @Dan Munns this can be done... not with sub-statuses but can be done...

[nasimg]

Hi @Victor

Don't keep us in suspense - how???

I'm interested in this one too.

Nasim

[Keith]

This is exactly what I have been trying to develop in a BPM whereby I have nested "wait status change" requests with expiry times, with each sending an email. However there is a problem with the timers not getting reset which Hornbill are looking into - @Victor is aware of this (or do you have a better solution?)

See this thread 

 

[Victor]

@nasimg well... I don't want to keep you in suspense but with so many people now interested I got stressed  ... I should have never said it (joking)

So, just to understand this right, the idea is that when sub-ststus changes, an email is automatically sent... the email that is sent depends on the sub-status... did I get this right?

[Dan Munns]

@Victor got it in one. 

I set a sub status of 'Waiting for 3rd party supplier' and an email telling the user that we are waiting for delivery (via an email template) is automatically sent.

So many times i have seen tickets like "On hold.....off hold.....email sent to customer.....on hold....." because someone forgot to let the customer know something 

[Victor]

@all

I am still working on this, as soon as I have a working example I will post a copy of the BP configuration. Apologies for delays.

[Victor]

@dwalby @nasimg @Dan Munns @samwoo @Keith

I know you thought I forgot about this thread, I didn't ... I did manage to create a "self-sustained" chasing mechanism not using multi "wait for status change" nodes but is it quite convoluted making use of statuses and sub-statuses and I didn't like it...  ...

However, now the fix for multi "wait for status change" nodes is available so the auto chasing mechanism should be easy to build  

[nasimg]

@Victor

Thanks for the update....and yes I had forgotten about

[Keith]

@Victor I might be confused (it happens a lot) but I'm not sure what "fix" has been applied. However, having just tested my multi stage closure as per the below topic I still do not get past the first instance of sending a mail. Has the issue with the timer being missing after the first expiry been fixed?

17 hours ago, Victor said:

However, now the fix for multi "wait for status change" nodes is available so the auto chasing mechanism should be easy to build  

 

Regards

Keith

[Victor]

@Keith it seems I was talking rubbish ...  ... The fix is not yet in live instances, it will be on the next Service manager update... I have no idea why I thought it was already available... I am sorry *sniff...

[Keith]

@Victor Ah, we all make mistakes. Any idea on timescale, I was due to chase you on this

[Steve Giller]

From another post I believe I read that the next SM update is due in a couple of days.

[Keith]

Thanks @DeadMeatGF

[Victor]

@Keith @DeadMeatGF yes, anytime now... should be deployed, I think, early next week...

[dwalby]

Has anyone successfully managed to configure this following the recent update. I'm hoping to give it a try over the next few days/weeks.

[Keith]

3 minutes ago, dwalby said:

Has anyone successfully managed to configure this following the recent update. I'm hoping to give it a try over the next few days/weeks.

Yes I have this configured on a couple of services and tested it successfully but not published to live just yet.. 

[dwalby]

@Keith @Dan Munns Did either of you manage to create a BPM for auto-chase? I need to give it another crack myself but wanted to know whether you'd had any success.

[samwoo]

In relation to the original idea in the first post, maybe this could work in conjunction with....

But outside of the BPM

 

[Keith]

On 4/24/2018 at 8:22 AM, dwalby said:

@Keith @Dan Munns Did either of you manage to create a BPM for auto-chase? I need to give it another crack myself but wanted to know whether you'd had any success.

@dwalby yes I have implemented this successfully on a couple of services. It's pretty easy to setup. I use the await status change functionality with an expiry date so that if it expires it triggers an email and resets another await status change event. I also use a different email template for each successive letter with stronger wording. Whilst I don;t have any hard evidence I think this has been effective and resulted in more closures.

See the below thread for clearer explanation.

 

[dwalby]

@Keith - Thanks for this (sorry for the late reply!).

Just so I understand the logic. Presumably when an analyst e-mails or speaks with a customer and agrees to the put the call on-hold, the analyst uses the e-mail function then manually changes the sub-status to "Awaiting Customer Response" (Or similar) at which point the "Await Status Change" node kicks in that expires after a set number of days, then fires a chase e-mail?

With regards to your chase e-mail, does this contain the message from the original e-mail but also explain the 3-strike rule?

[Keith]

@dwalby  - My process is based around the need for a user to close (or reopen) a request after it has been marked as resolved so is a rather different. Essentially I set a wait status after setting to resolved then after a number of days send an automated reminder if the status has not changed. The problem I think you will find is that the Await Status change does not work on sub statuses (at least as far as know). 

My emails use a different template in each case with increasingly stronger wording.