Jump to content

Help on understanding response time and fix time


Alberto M
 Share

Recommended Posts

Hi all.

I've been asked by a colleague about the following and I need some help to answer to the two questions below: I know that these fields are timers in seconds that are handled in the workflow, but sometimes I get values that it's difficult for me to explain.

........................................................................................................ "

I need a help / information on how to check average time spent on a call, Basically I want to arrive below two metrics 

•    Avg Response Time (Person Hours)
•    Avg Resolution Time (Person Hours)

For the above data  I found a column available with in default view (hornbill export option from home screen) Resolve Time (Column AH)  and Response Time(Column AJ) but I am not sure this data is in Seconds or some other value? 

image.png.aaa2e2a88e37bec8ab8358a9c901ceb2.png

For an example : IN00145569 

image.png.f53e0aa3326982350381ecfc3aaa798a.png

Call Logged :- 16/01/2020 12:43 PM
Response Completed: 16/01/2020 2:09 PM
Resolution Completed: 28/01/2020 1:20 PM

When I calculated time difference based in online tool it is coming as 1 Hours and 26 min ( 5160 seconds) , same is matching if we calculated manually.

However “Response Time” (Column AJ)  column shows 98161

Q1:- Is this correct ? how to interpret this value .

...........................................................................................................................

Q2:  To calculate resolution time spent , is this data including on-hold or excluding on-hold value? 
Which means to arrive actual resolution time do we deduct “Total Time on Hold” from “Resolve Time”? or “Resolve Time” is the final value after all consideration. 

IN00143793

Resolve Time= 436118
Response Time= 1102
Total Time on Hold= 85258
image.png.a717d954d1934a1594b7e2d0c1733cc0.png

"

Also, some clarification about the "response seconds" and "fix seconds" and how they relate to the other SLA fields will be nice.

Thanks for some help on this.

A.

 

 

 


 

 

Link to comment
Share on other sites

When looking at SLA data it is important to distinguish between two sets of data stored in the database: one represents the time required to respond/resolve aka. the target and the other represents the time taken to respond/resolve.

3 hours ago, Alberto M said:

However “Response Time” (Column AJ)  column shows 98161

Q1:- Is this correct ? how to interpret this value .

This is the response target or in other words, the time the analyst needs to provide a response according to current SLA (stored in seconds).

3 hours ago, Alberto M said:

When I calculated time difference based in online tool it is coming as 1 Hours and 26 min ( 5160 seconds) , same is matching if we calculated manually

This is the response time or in other words, the time the analyst took to provide the response (also stored in seconds).

 

3 hours ago, Alberto M said:

Q2:  To calculate resolution time spent , is this data including on-hold or excluding on-hold value? 

It excludes on-hold time. The below should explain in more detail.

 

When looking for more information about this type of data that we store on the request, is a good idea to have a look at the respective fields, in the App Entity Viewer.

image.png

You can find this in admin tool within each app. To look at this field we need to it via the "Database Schema" for the "h_itsm_requests" table.

  • h_respondby and h_fixby fields - The date and time the request should be responded by and fixed by respectively (the targets) - this is a date/time value
  • h_responsesecs and h_fixsecs - The number of seconds the request should be responded by fixed by respectively (the targets) - this is a number and is used for various time calculations
  • h_responsetime and h_fixtime - The time it took (in seconds)
  • to respond to the request and to fix the request respectively - this is a number and it represents the number of seconds took to respond/fix
3 hours ago, Alberto M said:

Which means to arrive actual resolution time do we deduct “Total Time on Hold” from “Resolve Time”?

Yes. Which means the answer for - is “Resolve Time” the final value after all consideration - is no.

Now, back to your example, the AH and AJ columns should represent the targets. If you look at all fields I described above, at various requests, and see any values that need further explaining please let me know :) 

  • Thanks 1
Link to comment
Share on other sites

1 minute ago, Alberto M said:

why the h_responseby is not set to 5159?

You mean respondby, not responseby (we don't have a filed with this name)? If yes, respondby is a date/time field which stores the target as a date and time, therefore you can't have a number in there...

Unless you were asking something else....

Link to comment
Share on other sites

@Alberto M yes, responsetime should be 5155 (not 5159, I'll explain the difference in last paragraph). I'll give you an overview of what happened on IN00145569 which will explain why responsetime is 98161 and not 5155:

1. Request was raised and the response timer started. Your workflow is configured to have a "Confirm Priority" task. Once this task is completed the response timer is stopped (at 08:39). At this point the timer calculation were made and the information stored in the requests table (h_responsetime set to 5155) and in the requests timers table:

image.png

What is important to know now is that once the (response) timer has been stopped and all the durations calculated and stored in all relevant tables, the (response) timer for this request was then deleted. You can see in the highlighted row that at the time the calculations were made, the response timer ID was 454620.

2. Request was subsequently escalated (at 16:10) and the service level changed:

image.png



When the SL changed, the timers were also recalculated (different targets for a P5). When this recalculation happened, Hornbill no longer had a reference for the response timer, as I said above, this was deleted when the timer was stopped initially. Now, Hornbill needs to recalculate the response timers and will have to do it from the start and it does not have any reference for elapsed working time or for archived elapsed working time therefore it can only calculate the response duration as the initial target which is 98161. This information is again, stored in the requests table (h_responsetime now set to 98161) and in the requests timers table:

image.png

Since the response timer ID was deleted when it was stopped, you can see now on the escalation recalculation that the timer ID is 0.

 

I know this might sound a bit complicated and convoluted but basically I wanted to say that the info you see is based on how the system is working now in the scenario when a timer is changed after it was stopped via a Service Level update. I also understand (and this is something we raised internally not long ago) this is not exactly the "correct" information therefore we now have a change in place (that is being worked on) whereby we will store the elapsed working time for SLA/SL so when we need to recalculate in the given scenario we have all the necessary information (so to speak).

 

Now, about why 5155 and not 5159. Calculating durations based on date of request was raised is incorrect. I'll explain why: the request timers do not start from the moment a request is raised but from when the timers are started via the workflow. It is only the workflow that can start a timer. Therefore it really depends on where in the workflow you have the start timer node. In this example it took 4 seconds from when teh workflow spawned until the start timer node was reached. The further in the workflow, the greater the difference. Therefore to have a timer start time as close as possible to the request raised time, have the start timer nodes as soon as possible in the workflow. 

  • Thanks 1
Link to comment
Share on other sites

Well... now this makes some sense, thanks a lot, @Victor

We have a few reports and measures set where we use this response time for reporting purposes used by our management team. I believe these reporting are not accurate based on these calculations - at least I believe this is not what is being expected - for requests where the SLAs are changed like this one. I believe I need to work a bit reformulating these reporting. 

 

Link to comment
Share on other sites

  • 1 year later...

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
 Share

×
×
  • Create New...