Jump to content

% requests within resolution SLA


Lyonel
 Share

% requests within resolution SLA formula  

1 member has voted

  1. 1. Which formula would you use?

    • (Total requests logged this month - Total requests breached this month) / Total requests logged this month
      0
    • Total requests resolved this month with breach / Total requests resolved this month
      1
    • Other suggestion (please post a comment)
      0


Recommended Posts

Hi all,

In my organisation, we are facing a curious situation where we are struggling to identify the best formula to calculate the percentage of requests resolved within the SLA on a monthly basis.

What would be the best practice in your view? Which formula would you use?

Option 1: (Total requests logged this month - Total requests breached this month) / Total requests logged this month

Option 2: Total requests resolved this month with breach / Total requests resolved this month

Link to comment
Share on other sites

Hi Lyonel,

It mostly depends on WHAT information you want to get out:

Option 1 will not, I think, give you a sensible number; it compares calls logged in a period with an amount of calls breached within that same period. Please note that some of these breached calls might have been logged before the period. The percentage generated would imply, but is not, the percentage of calls meeting their SLA logged within the period.

Option 2 is where my vote would go for %breach (one is comparing resolved calls).

Alternatively, one can report on percentage of breached calls currently open.

One can also report on: out of the amount of calls logged within this period, how many have breached (and transform it into a percentage). Please note that calls could still be open and (about to) breach.

OR: out of the amount of calls logged within this period, how many of the resolved calls have breached. Needless to say, this percentage will vary over time as more calls from that period get closed.

The other thing to keep in mind is the various SLAs. Tallying P1's and P3's in the same heap might give a very skewed picture: eg 99% meeting of SLA could hide 100% missing of P1's

Anyhow, I hope I have given you some food for thought.

Sam

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

After putting a lot of thoughts into it and making simulations I think we came to a reasonable compromise regarding the dilemma we have with SLA KPIs.

To date, we were monitoring the % of non-breached requests / requests resolved within the month. As expressed earlier, this doe not take into consideration the volume of calls, which has a direct impact on this KPI. Also, as soon as you clear some backlog you will be very hardly hit.

Any other methods we looked at did not really make sense as it would involve comparing apples with pears...

One of the very nice feature with Hornbill is the field "respond by" and "fix by" available in the requests table. So our idea is to use one of these dates for our measure, and then simply use the "within response" or "within fix" field :) By doing so, we do take into consideration volume of call, as well as priority. Please note that in our case, all services have SLAs setup, which makes this work. In the end, the formula is quite simple: % requests resolved within SLA = (Total requests due this month - total requests due this month that breached) / total requests due this month

The really nice thing about this is that, from what I have seen and experienced on our system, when you change the SLA (i.e. priority has changed) OR put the request on hold, the system recalculates immediately the SLA due date.

What do you think of this formula? I would really like to have some feedback on this.

Thanks!

Link to comment
Share on other sites

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...