Response time in Request export does not seem correct

[Berto2002]

We exported Request data from the Request list including Service Level Target (SLT) attainment fields "Response Time" and "Resolve Time" and found a large number of our Incidents had the 28810 seconds entry for response time (8 hours as per the SLT) and this was even happening when it's clear from Resolve Time that the Request had been resolved in around 1 minute:

I thought for a moment that I was missing a "Mark Response Timer" node in that BPM but on examination of these Requests we see that the Response Timer was Marked only a few seconds after the Request was logged:

So what I see is that the data in Resolve Time on Request Export does not match my expectations of what it should be. I am expecting for these IN for the Response time to be a few seconds, not seem to default to the 8 hours in the SLT.

Interestingly the flag for "Within Response time" is 1 for these cases indicating that the system DOES know there was a quick response...

Is this something I have not correctly configured or something I need to report to Support?

Thanks

Berto

[Berto2002]

Raised in Premier Support

[Victor]

@Berto2002 on all the above requests, is the SLA recalculated after the response timer is stopped? Can be in any form, manually, using the Re-evaluate SL workflow node or automated (based on criteria defined in SLA rules)?

[Berto2002]

I don't think so. There is only the "Starter Response Timer" node and "Start Resolve Timer" node; both at the start. There is only one "Mark Response Timer" node and then the next SLA-affecting node is "Mark Resolve Timer". We don't have any re-evaluate SLA workflow nodes to escalation rules in play. The only re-evaluation would occur if someone altered the priority I guess?

I noticed this: the "Start Resolve Timer" has no Result Reference

but the "Mark Response Timer" one does have a reference:

[Steve Giller]

21 minutes ago, Berto2002 said:

The only re-evaluation would occur if someone altered the priority I guess?

There are a number of actions that can trigger a re-evaluation, see the SLA wiki page.

[Berto2002]

OK so my Incidents WERE going through an "SLA Re-evaluation" node (now removed) and we have guest.app.view.ITSM.serviceDesk.slm.enableAutomatedSLChanges set to on so we got this in the timeline (although I can't understand how two nodes that are supposed to do the same thing came out with different answers within seconds...)

 

Are we saying that any re-evaluation (be it the node in BPM or the automated process) NULLIFIES any chronologically previous "Mark Response Timer" node outcome?

I'm a bit worried you're going to say 'yes' to that because a Response is a Response and it's done and thus any re-evaluation should only re-evaluate that which has yet to be given an outcome?

And yet even if it does, it does not stack-up with the situation where, in my dataset in the first post, we are getting a "1" flag in the "Within response time" column for IN00052304 which does not tally with the "Response Time" number of 28813 seconds; and the UI states, "Response Completed: 04-10-2022 16:13" so a response was logged.

[Victor]

@Berto2002 the scenario you described has been identified as a product defect which is in development queue, ref: KE00174035. Any SLA re-evaluation will "reset" the response timer data (for response timers that were already marked) with incorrect values.

[Berto2002]

Ah, @Victor I think we have hit it. That's a big issue for us because we need to alter priority quite a lot (we see it as a dynamic field to help us 'prioritise' hehe) so this would explain why all our values are 28810 seconds; many SR and IN get priority altered and so they all lose any response timers they may have had.

Any view on whether this is scheduled for a release? 

[Victor]

@Berto2002 at the moment the KE has been accepted and in progress. I do not have any other information on this at this time I'm afraid.

[Berto2002]

In the meantime, I have moved the Start Timers (both of them) to be AFTER the automated priority setting so that will stop some of the issues. I have removed the manual re-evaluate node.

We are not yet reporting this data so we do have an indeterminate period before the management team get visibility of the issue. I am trying to get thing in line before we start reporting on response times.