Jump to content

Recommended Posts

Posted

After going live with the new platform today we have realised that the platform does not recalculate the SLA target on the reopen of a ticket

This is a pretty important capability for us & would allow the true reporting against the full ticket life cycle

has anyone else previously asked for this?

 

thanks

Andy

  • Like 1
Posted

Hi @AndyGilly

It has been asked for and there is a change for this to be added to the system, but it is not on the 90 day rolling road map at the moment. 

I have added you as a connection to the change request so as soon as it has been added you will be notified, and as you know you will get it straight away without downtime or consultancy or any of the associated upgrade cost. There is no timescale at the moment, all I can tell you is that it won't be added in the next 90 days. 

In terms of the practicalities, one workaround at the moment is to set the request to be a resolved sub-status when the analyst thinks it is resolved, and then following a number of hours or days the request can auto close via the BPM. It's not ideal as the resolve time won't then be captured, however if the request does get re-opened you will be able to report against the full ticket lifecycle. 

Does this happen often where tickets get resolved and then re-opened by the customer?  

  • 1 month later...
Posted

Morning,

I would like to re-raise, or add some weight to this item please

Although it doesn't happen loads, the premise that our SLA reporting is not completely accurate or reflective of the service received by our customer impacts many areas in our IT organisation

appreciate your thoughts

many thanks

Andy

  • 3 weeks later...
  • 4 months later...
Posted

Hi Yes - we are now live and have found this to be the case. We would like the SLA clock to restart if a ticket is re-opened to truly reflect in reports and our performance

  • Like 1
Posted

As Conor mentioned above, restarting the SLA timer after it was stopped is not currently possible. There is a change on our list to implement this functionality in a future update. @Conor can you please add Victoria as an interested connection to the existing change?

  • Victor changed the title to Restart or resume SLA timers on reopen of a request
  • 7 months later...
Posted

Hi all,

It now seems that this functionality has been delivered under the 2126 build of Hornbill Service Manager this week.

After some investigation on our tickets where they have been reopened since the update has been applied this functionality hasn't changed on our instance.

It seems that a resume resolution timer needs to be added to each Incident and Service Request BPM we have configured.

Can somebody please confirm if this is the case? 

If so it's not fully clear exactly where this node needs to go in the investigation, resolution and closure business process.

Would it be possible to provide some advice/ guidance on how to get this functionality into our BPMs?

Many Thanks

Adam

Posted
26 minutes ago, Adam Toms said:

After some investigation on our tickets where they have been reopened since the update has been applied this functionality hasn't changed on our instance

@Adam Toms the functionality works either via workflow nodes or via app settings. If you are (or plan to) use workflow nodes, since the functionality comes in form of a new workflow node, it won't apply retroactively on any existing running workflows. These workflows simply don't have the required node in their config for this functionality.

26 minutes ago, Adam Toms said:

a resume resolution timer needs to be added to each Incident and Service Request BPM we have configured

Yes, correct. You can add the node and the config in your BP config which means any new requests, that will create running workflows based on the new BP config, will have this functionality.

26 minutes ago, Adam Toms said:

it's not fully clear exactly where this node needs to go in the investigation, resolution and closure business process

I assume those are stages you have configured in your BP. Basically the node needs to go at some point after the request has been resolved. Where that exactly in your workflow that is, I don't know. I can make a speculation based on how the stages were named, so the new node would have to probably be in Resolution stage.

 

As I mentioned above, apart from using the nodes you can also make use of application settings which are independent of workflows and unlike the workflows, enabling or disabling these will apply on any existing requests. Mind you the app settings are global so they will apply the functionality to all requests you have in your instance.

image.png

  • Like 1
  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...