Email notification on resolution

[Alisha]

Hello,

In our Business Process, we have an 'Analyst Assigned' checkpoint in the 'In Progress' stage. We have an email notification sent to the customer in the Resolution stage once the request has been resolved. However, if the request has no owner, the customer won't receive the email notification

My question is, is it possible to trigger the email notification even though the request has no owner? I'm trying to configure the Business Process so that if the request status is Resolved, it would still send the email, but that doesn't seem to work.

Many thanks,
Alisha

[Steven Boardman]

@Alisha could you not have a suspend await analyst node in the progress stage, and use the lock operation to disable the resolve action until the suspend await analyst action is complete, and then another node to unlock it once the analyst has taken ownership?  this way an analyst has to take ownership of the request, in order to be able to resolve it (as the resolve action won't be available until they do? this way the rest of your process will flow as once assigned, they can resolve, but not before

 

 

[Steven Boardman]

Another option is using the Suspend Await Resolution node in your process, once the resolution is added, the process will move forward and the email will be sent to the customer, if it follows this node.  This way would mean you would not enforce analyst ownership.  

[Alisha]

Hi @Steven Boardman,

Is there a way of showing 'Analyst Assigned' in the HUD (through a manual assignment) without using the suspend await analyst node?

Many thanks,
Alisha

[Steven Boardman]

@Alisha sorry i am not sure i follow 100%

The '''Analyst Assigned''' is a checkpoint in a stage in your process (i am presuming)?

If that is the case, the only way to mark it in the HUD is through an action in your business process , be that using a Set Stage Checkpoint node, or setting a checkpoint on another node in the stage, but in either case it can only be set by an action driven by the business process.  It can't be set by completing a manual action on the request that is not in some way tied to the business process i.e it is a manual action to assign the analyst (using the suspend wait analyst node from the business process), but it is then the checkpoint you use after this process managed manual action which flags it in the HUD.

There is no way to have undefined manual actions on a request show in the HUD, as the HUD represents the process.   

Obviously the Information section on a request shows if a request is assigned and who too, and this is also visible on the request list with the team and owner columns.    

Let me know if i have misunderstood (which is always a distinct possibility)  

[Alisha]

Hi @Steven Boardman,

Sorry for not being very clear. When the analyst assigns a request to themselves, can we configure the Business Process to show that action in the HUD without using a suspend wait analyst node?

I believe it's the suspend wait analyst node (which we had already) that is stopping the email notification from being sent to the customer on resolution (if the analyst forgets to assign the request to themselves).

Many thanks for your help.
Alisha

[Steven Boardman]

@Alisha I think that is the issue, unless you use the suspend await analyst node then an agent assigning the request to themselves will not trigger anything in the business process to say - It's Been Assigned so do two things 

* Mark the checkpoint on the HUD (using a checkpoint marker in your process

* Unsuspends the process, and let it proceed to the next action or stage - in your case the resolution and resolution email 

My suggestion to avoid this happening and for the agent to forget to assign it to themselves, was to use the lock resolve action option, before the suspend await analyst - this way they can't resolve the ticket before taking ownership (see image below where the resolve action is greyed out

Once the take ownership the Owner Assigned checkpoint is marked and the resolve action is unlocked and can be used by the agent to resolve the issue, after this the resolution email will be sent because the resolution will have been defined.

Here Graham takes ownership - and resolve action is unlocked (not grey anymore)

Graham then adds the resolution as it's not greyed out, the HUD is updated and the resolution email is sent

 

A basic example of this process is here:

The lock / unlock is the following node

The one thing i can see agent's asking is why they can't resolve their tickets - but i would hope they would very quickly see that taking ownership allows that action and it will be second nature.

Hope that helps as a suggestion.

Maybe one to discuss with the customer success team if it was of interest

 

 

  

 

[Alisha]

Thank you very much @Steven Boardman

Will this affect the auto-resolve/self-help fixes that we already have set up in our Business Process?

[Steven Boardman]

@Alisha unfortunately not knowing what you have set up in each of your processes specifically, it's difficult for me to comment to much further.   I don't see any reason why you could not combine the two things in theory, but perhaps this is something the customer success team could discuss with you, especially if they have visibility of your current configuration of your workflows, as we would not want to blindly advise on changes or amends to your live processes.

If the challenge is as you have described, then the above is a solution for that issue, however this has to be considered in the wider context of the existing business process configuration, so it sounds to me like one to discuss with customer success.

 

[Alisha]

I understand, thanks for all your help @Steven Boardman

[Jeremy]

There is also the option within the setting of Service Manager not to allow requests to be resolved without on owner, we have this turned on so that every request has a owner before resolving and the resolve action is not visible until this happens.

Although this is for every type of request, so certain request we have a closure via the BPM after tasks or specific criteria has been met.

[Steven Boardman]

@Jeremy is absolutely correct - the setting is a global setting and would therefore apply to all requests for all teams

If this was appropriate it could be used, as long as all teams on your instance are happy to work this way.

If you need different behaviour per process or by teams, then the process and locking option might be the way to go