Widget shows excsessive number of calls with no set SLA target

[lee mcdermott]

i am just trying to gather info for call volumes for last year within SLA etc.

 

Any idea what the service level target not set will be typically? 

What would these calls be for or why would the SLA not be set? 1380 seems quite a lot

 

see below

[lee mcdermott]

also these are all incidents that use the same BP and the BP does have a start and stop resolve timer as part of the workflow.

 

not sure how i get an actual list of these calls with no service level target set to see if there is anything obvious that is wrong?

[Guest]

Hi @lee mcdermott

I've just taken a quick look at a sample of your data and there is a number of different reasons why the SLA has not been set:

1) Some of the requests are still open/on-hold and have not reached the point where the SLA gets associated
2) Some Services/Catalog Items NEVER seem to have an SLA associated - for example "Ebusiness"
3) It appears that a number of requests have been Closed without following the process e.g. logged and closed immediately before an SLA gets associated - the headsup display has not reached its conclusion as the analyst has gone closed immediately
4) There are a number of cancelled requests - again these have been cancelled before the SLA has been associated.

Plus a number of other exceptions - I was only looking over a 10 day sample - I achieved this by running a statement in Database Direct to view some of the key info (e.g. Service and Catalog Names, Status etc) and just looking for a few patterns. 

This could potentially be avoided by making some small improvements to your Business Process to set a default SLA immediately (which recalculates after a priority has been selected). This, and some corrections to a few of the other areas about (e.g. filtering out cancelled requests from your reports, having a look at the Ebusiness Service to ensure an SLA has been associated to this) will hopefully significantly reduce the other issues as well and your report going forwards may be more accurate. 

This is something you could potentially bring up in your next quarterly success call and Hornbill may be able to have a quick look for you to assist with some of these, or give you some troubleshooting guidance. 

I hope this helps

Bob Dickinson

[Martyn Houghton]

@lee mcdermott

Could be related to the issue we raised below, where you can in essence unset the Service Level, but the volume does look quite excessive for that.

Query below might help to find those which have a Service Level Agreement assigned but not a Service Level. This will at least tell you if that's the cause.

SELECT * FROM h_itsm_requests where h_fk_servicelevelid is null and h_fk_servicelevelagreementid is not null

 

Cheers

Martyn

[lee mcdermott]

@Bob Dickinson

Thanks Bob, Yes I just noticed the ebusiness thing just before and have now associated it with the SLA.

Not sure on the still open on hold calls as this report is only looking at resolved or closed calls?

 

the setting a default sla as  part of the BP sounds like a good idea. I already have the BP setting the default priority. How would you set the SLA in the bP?

 

I do actually have a quartley review next week so maybe worth discussing improvement to BP's here .

 

@Martyn Houghton     thanks for that Martyn I will try running that and see what I get back.

 

 

 

[lee mcdermott]

@Bob Dickinson

@Martyn Houghton

 

I have ran the query martyn supplied and it appears that the majority of the calls are realted to the fact that the Ebusiness service did not have a SLA agreement associated with it. I think this is accounting for the majority of the 1000+ calls

 

There are a few others in there but these seem to be lined to our go live period when calls were logged with no priority set etc.

 

thanks for the help

 

lee