Adrian Simpkins Posted November 12, 2020 Share Posted November 12, 2020 Hi All, We have introduced automated SLA's across our Services this week, and these were all swapped over across all our Services on Monday. However, i have a request which was in a Resolved/Closed status which triggered the Response breach SLA timer after it was resolved / closed? The request timeline flows like this: - raised on 5/11 when old SLA was in place - SLA swapped on the Service this was raised against on Monday the 10th (I believe this was swapped in the morning on the 10th - see 2nd line below showing the change in SLA) - Assigned to a team member on the 10th at 1.45pm - shows change of SLA on the request at 1.45pm on the 10th - would this be because it was raised against the old SLA on the 5th but assigned to a team member on the 10th which meant the system auto updated the assigned SLA against the Service? - resolved at 1.48pm on the 10th - closed by one of the Team engineers at the same time on the 10th at 1.48pm - Response SLA triggered on the 11th at 3.21pm advising that the Response SLA has reached 90% of the target (request was resolved / closed at this point) - Response SLA triggered on the 12th at 11.26am advising the Response Timer has breached (again request was resolved / closed at this point). What i wanted to understand is why this triggered still even when the request was Resolved? Would it be to do with swapping the SLA on the live Service on Monday 'resetting' the timers so that the system missed the Response timer? Many thanks as always Adrian Link to comment Share on other sites More sharing options...
David Hall Posted November 12, 2020 Share Posted November 12, 2020 Hi @Adrian Simpkins Thanks for the post and the timeline of events, could you confirm when the response target itself was marked? Just trying to confirm if these escalations that are incorrectly firing are as a result of the SLA change, so it would be useful to know when the response was marked and whether the request was on-hold or not at the time of the SLA change. Kind Regards, Dave. 1 Link to comment Share on other sites More sharing options...
Adrian Simpkins Posted November 12, 2020 Author Share Posted November 12, 2020 Hi David, Thank you for the response. The Response target shows as breached (1st screen shot below), and the Timeline shows a change in SLA at the time the request was assigned to the Analyst (2nd screen shot). The request did not go on hold at any point - looking at the updated SLA it looks like it reset the original SLA set on the 5th on the 12th so in effect looks like the Response timer was reset by the change in the SLA. I am presuming this is just due to changeover of the SLA on the live service but just wanted to confirm this Many thanks! Link to comment Share on other sites More sharing options...
David Hall Posted November 12, 2020 Share Posted November 12, 2020 @Adrian Simpkins Ah ok... so it simply looks like the response timer has never been marked... therefore the timer and escalations will remain active until you reach the relevant stage of your BPM process where you call the BPM Node Timer -> Mark Response Time . In this scenario the change of status to resolved or closed will not automatically mark the response timer. Regards, Dave. Link to comment Share on other sites More sharing options...
Adrian Simpkins Posted November 12, 2020 Author Share Posted November 12, 2020 hi David, Ah ok, would it not have been marked though when it was assigned to the Analyst? Or was it 'reset' when it was assigned to the analyst as the system would have applied the new SLA that we put in place on Monday? Thanks Link to comment Share on other sites More sharing options...
David Hall Posted November 12, 2020 Share Posted November 12, 2020 Hi @Adrian Simpkins It all depends on your BPM process being used for the request and where within that process the Timer -> Mark Response Time node is placed, we do not automatically mark it on any one specific action as every customer will make their own business decision as to what point in the process it should be marked so you should use the node in your BPM at the appropriate stage. The change of SLA will update the targets, but if the target has already been marked then it will not generate any new timers/events for that request. Does that help to answer your question? Regards, Dave 1 Link to comment Share on other sites More sharing options...
Adrian Simpkins Posted November 12, 2020 Author Share Posted November 12, 2020 Hi Dave, The BPM behind this catalogue item marks the Response Timer straight after the status is set to Open so I would have expected it to trigger when it was picked up by the Analyst at 1.45. Its not a massive issue but I wanted to understand if this same scenario may occur on any other requests that were active under the old SLA when I swapped this over to the new SLA on Monday so i can communicate this to all teams to make them aware that this may happen on other requests. Thanks Link to comment Share on other sites More sharing options...
David Hall Posted November 12, 2020 Share Posted November 12, 2020 Hi @Adrian Simpkins I would have expected the node to correctly mark the response and end the timers, but with the change over and the SLA change then its possible that this is causing a scenario with an issue that I have not seen before. If this persists with requests logged after the change over then by all means come back and we can take a further look. Regards, Dave 1 Link to comment Share on other sites More sharing options...
Adrian Simpkins Posted November 12, 2020 Author Share Posted November 12, 2020 Hi Dave Thank you, i thought it would be something to do with the change in SLA on Monday. I will monitor for any other issues Many thanks 1 Link to comment Share on other sites More sharing options...
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