AndyGilly Posted November 26, 2019 Posted November 26, 2019 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 1
Conor Posted November 26, 2019 Posted November 26, 2019 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?
AndyGilly Posted January 10, 2020 Author Posted January 10, 2020 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
AndyGilly Posted January 27, 2020 Author Posted January 27, 2020 Good Morning, any thoughts on this one please??
Victoria Heeley Posted June 18, 2020 Posted June 18, 2020 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 1
Victor Posted June 18, 2020 Posted June 18, 2020 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?
Conor Posted June 18, 2020 Posted June 18, 2020 @Victor @Victoria Heeley - @Bob Dickinson has already added Victoria as a connection to the change this morning 1
Adam Toms Posted January 22, 2021 Posted January 22, 2021 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
Victor Posted January 22, 2021 Posted January 22, 2021 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. 1 1
Adam Toms Posted January 22, 2021 Posted January 22, 2021 Thanks @Victor, much appreciated. My mistake. This is great news the app settings can be turned on, if you haven't got this node configured in your BPMs. Thanks as always for your help.
Victor Posted January 22, 2021 Posted January 22, 2021 @Adam Toms no worries I haven't personally tested the app settings but I don't expect any issues. Just in case, if you spot anything, let us know. 1
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now