Sending email to customer when a call is re-assigned

[nasimg]

We send an email out to the customer when a call is assigned to an analyst, but if it gets reassigned this doesn't happen.

Is there a way we can get an email to be sent out when a ticket is reassigned?

Nasim

[Victor]

@nasimg only the BP can send out automatic emails (there are other automatic emails, but this one only BP)... you could have the BP is a suspend state "Wait for new request owner" then on BP resume, trigger the email... not sure if and how this would fit with your current BP config as maybe not always a request will get reassigned...

[nasimg]

Hi @Victor, @Gerry, @AbdiH

It doesn't happen on every ticket but we want the customer to be able to call the analyst who has the ticket, so we are emailing the analyst contact details - I have asked about this before and was told we can't publish the analyst's details on the portal but can you check this again.

I know lots of your customers use phone support, but a major benefit of using the portal is it would reduce calls freeing the analysts to do more useful work (rather than logging a ticket manually). Showing the customers you are still able to contact the analyst with their ticket (not email or portal) via the phone would help in transitioning customers from a phone to web only portal. This would be a major selling point.

I understand not everyone wants their analysts contact details visible on the portal, so a toggle switch to enable/disable this would be great.

Nasim

[nasimg]

Its gone a bit quiet here  - just a nudge its something my organisation really would like to see: an option to allow the contact details of the owner of the ticket to show on the portal (enable/disable).

But also interested if we use a suspend state "wait for new request owner" BP to trigger an email.

Nasim

[Victor]

12 hours ago, nasimg said:

But also interested if we use a suspend state "wait for new request owner" BP to trigger an email.

@nasimg so do you want to explore the option to have the analyst details email sent by the BP what the request is reassigned? The only issue here is that the BP would need to "wait" for the reassignment... reassignment can happen, I guess, at any point during request lifetime so the question would be where do I put these suspend node(s)... or you can do with decision nodes if you have the previous and current owner details available (thinking custom fields) ...where do I put this in the BP... basically all is down to "how do I (fully) sync the BP with the analyst actions on a request"... If you have specific points is the request lifetime when the reassignment can happen then we could (somehow easily) cater for the reassignment in the BP...

[nasimg]

Hi @Victor

I'll have a chat with Carl on this and see what he thinks, I believe the portal will be able to show the contact details (by November 2017) which means the email isn't a show stopper.

I know its something that our customers would like, so its worth us seeing if we can get an email working.

Nasim

[carlt]

Hi @Victor 

The part of the BPM where we would want the email sent would be while the process is also waiting for the request resolution.

The request may not get reassigned but it would be about sending an email however many times it does get reassigned.

Is there a way of doing this?

[Victor]

@carlt can you PM the process definition file and I'll have a look if and how you can achieve the assignment notification. On top of my head, we might be able to do it with two parallel suspend processes, but we need to establish what would be the trigger to end the parallel processing. So, for example:
- on the first parallel thread, we would have a suspend "wait for resolution". This will be the main driver;
- on the second thread, we would have a suspend "wait for reassignment". This will be responsible for the email notification and it will loop until the main driver (wait for resolution) is no longer suspended.

So how it works, the BP reached the parallel section and it will have a double suspend... each suspends will behave individually however when both threads are resumed the parallel process ends. Translated into English, it means you can have the email notification on reassignment as long as the "wait for resolution" thread is in a suspended state. Just some quick thoughts there could be challenges on the way that I can't see right now... but we'll have a look...