2 step closure Resolution and Closure of Requests

[Jeremy]

So we are moving away from the 2 stage closures as we want to utilise the feedback function within Service Manager.

I do remember when we set the system up that we were given some advice around this area although I cannot remember it as it was so long ago!

What are the downsides if any to changing the BPMs to just closing the requests once resolved?

In my testing the any thing that I can see so far is that after a request is re-opened, when you re-resolve it the resolution email does not seem to be sent to the customer. Is there a setting that we need to turn on to allow resolutions outside of the BPM to trigger the email?

[Hornbill Staff DR]

HI @Jeremy

thanks for your post.

I'd be interested to know why you feel that feedback can't exist in a two-stage closure situation, can you elaborate on your decision to remove two-stage closure?

Dan

[Jeremy]

Feedback does not prompt the customer until a request is closed, we want to resolve our requests and within the resolution email have a link to complete the feedback straight away. Other wise we have to wait until the request is closed which but that point (over a week later) the customer cannot give feedback as they don't remember with enough clarity any issues or feedback that we would find useful.

Ideally feedback (in our opinion) should be able to be provided on resolved and closed requests.

[Jeremy]

forgot to tag you @DanielRi

[Hornbill Staff DR]

I see. So the motivation is to increase the quality of feedback?

Just to claify, I notice you state that the customer "cannot give feedback" which might imply customers simply aren't bothering to leave feedback. Do you find you receive a good number of feedback responses and it is just the quality of feedback that's lacking?

 

[Jeremy]

@DanielRi we have not turned on the feedback properly yet as we need to get over the hurdle of customer not being able to provide feedback on requests that are in a 'resolved' state and need to the requests to be 'closed'.

Sorry the 

2 hours ago, DanielRi said:

"cannot give feedback"

bit was more regarding the issue of giving feedback on something that happened a week or more ago. We want the customers to be sent the feedback link when we are resolving the job.

[Steve Giller]

@Jeremy If the Customer is ready to provide feedback, are they not also ready to close the Request?

That's what a number of my customers do.

[Jeremy]

@Steve Giller we are trying to reduce the amount that the customer has to do, with your suggestion they would have to say 'it's working' then provide the feedback. We would prefer the customer to just be able to provide feedback without this step. Hence why we wanted to close the requests in the BPM then send the email, this will work for us, however as mentioned in the original post if the request is then re-opened for any reason the resolution email is not sent.

It is this second resolution email that is the main issue for us, we are happy to just to close these requests in the BPM.

[Hornbill Staff DR]

Hi @Jeremy,

 its an interesting ask. Typically, I would never advise that a two-stage closure set up is removed. An exception might be in specific requests (e.g. new starter, hardware,) where the process is established and reliable in fulfilling the customer needs. Here a two-stage closure may not offer value because the bpm is helping to ensure things are delivered the right way, every time.

As I'm sure you're aware, the period between resolution and closure is intended to give the customer opportunity to confirm the resolution has been successful or re-open the request. I appreciate the distinction between resolution and closure is sometimes lost on the customer, but going directly to closed sets the precedence that closed requests can be reopened. Where is the line then drawn? Can a customer come back and open a closed request 3, 6, or 12 months later? Effectively, the ticket doesn't have an end to its lifecycle. If the bpm was adjusted to ensure resolution emails were sent after a ticket was reopened from closed, the bpm would technically never complete because you have to keep the bpm active in order to catch a reopen action and then loop to a wait for resolve before then sending the resolution email again.

There are elements in Hornbill that are specifically designed to instil good practice. The two stage closure, "Its working/It's still broken" buttons, and feedback only being left once closed are the three elements involved here. There isn't really a way to circumvent these best practices without causing problems elsewhere.

From my perspective, closed is closed and shouldn't be reopened. I'd suggest experimenting with the duration of the two stage closure, or remove the resolution text from the email and have a generic notification stating that their resolution is available in the portal. Forcing the customer to interact with the portal, thus building familiarity. Other campaigns outside of the tool to raise portal awareness and how feedback can be left will also help.

Dan

[Jeremy]

@DanielRi although I understand where you are coming from, we have requests that are re-opened several times and the customer does not seem to ever get notified of the resolution.

Is Hornbill really suggesting that if a request is closed and the customers come back to us that we should open a new request and start again from the beginning?

Surely there should be an admin setting that we can adjust so that if a request is closed an email template is sent?

[Victor]

Aside from the business perspective discussed with Daniel, I need to clarify how the functionality works:

On 5/23/2022 at 9:56 AM, Jeremy said:

In my testing the any thing that I can see so far is that after a request is re-opened, when you re-resolve it the resolution email does not seem to be sent to the customer. Is there a setting that we need to turn on to allow resolutions outside of the BPM to trigger the email?

The resolution email is indirectly linked with the request... The only reason why the (automated) resolution email is sent when the request is resolved is that the workflow associated with the request is configured to (automatically) send an email once the request is resolved. This type of notifications(*) are not sent by the request entity itself, but by the workflow associated with this entity (request). Therefore the resolution email will be sent automatically as long as the associated workflow is active. Once the workflow is completed (this no longer active) the entity responsible for sending the automated resolution email (the workflow) cannot send this anymore. It is important to understand the request and the workflow, while working together, are in essence separate and distinct entities that can behave and work independently of the other.

Besides the business reason for no reopening a closed request, advised by Daniel, there is also a technical reason: when a request is closed, most of the times it also means the associated workflow is completed. Because is now completed, and can no longer become active, any configured automations (such as sending the resolution email) will no longer work on that workflow and, by extension, on that request. This is the technical reason why a new request (and a new workflow) is usually advisable.

A possible alternative solution is to take the two stage closure mechanism (sort of) a bit further... for example, when the request is closed, do not also complete/finish the workflow (as it probably does now). Instead have it suspended for a reasonable amount of time(**) to cater for any potential reopening after closure. Again and as per above, keeping in mind that is the workflow that does the automation, we would need to keep that workflow active if we need that automation to work after and up to a certain point in request lifetime.

(*)this is different than analyst notifications which use a non-workflow mechanism for analyst notifications

(**)what is reasonable depends on many specific circumstances relative to your business. Keep in mind, ideally a workflow should complete as soon as possible, there is no need to have a workflow active for longer than really necessary.