Service Level Target not set when running widget

[lee mcdermott]

Hi,

I have an issue when running a widget where a portion of the calls show as Service level target not set.

I have had this issue before and it was because there was a service  that was not assigned to the SLA.

However all Services are assigned to the SLA now. 

 

Any idea why this would be happening or how to find out why?

 

thanks

 

lee

 

[Victor]

@lee mcdermott it might be that all services are linked or have an SLA but this does not necesrarily mean the request actually has a target timer (for response and/or resolution)...

Let me know what widget is that and I’ll have a look on Mon...

[lee mcdermott]

@Victor

Hi Victor,

 

the 2 widgets it is happening on is 

Incidents - service level success for last month

Service requests - service level success for last month

 

cheers

[Victor]

@lee mcdermott upon looking at some of requests it seems there is a mix of reasons why there are 58 requests showing as "Service Level  Target not set" because within fix record does not have a value and this is due to a missing resolution timer. I'll have a look at these requests and give you a list of things/configurations that would need to be looked at...

[lee mcdermott]

@Victor

 

thanks Victor

[Victor]

@lee mcdermott ok, I had a look through all 58 requests. Requests that have a process against them (see below which don't) have the "Incident BP v2" process associated to them, here is the breakdown:

• 11 requests have not been raised via a catalog item meaning they don't have a process;
• 42 requests do not have an owner;
• 5 requests raised between Sep 2017 and Feb 2018 do not have an SLA most likely because  there was no SLA rule for them at the time they were raised.

Besides the last 5, for which nothing can be done, there is some configuration that needs to be looked at, especial for the majority of these which do not have an owner. Due to how the process is configured right now, the resolution timer is only started after the request has been assigned and categorised but for those 42 this logic was bypassed as the request was resolved without having the owner meaning the process has never progressed past this point. For the 11 requests raised without going via a catalog item you would need to either ensure a catalog item is selected when the request is raised and/or ensure the service itself has a process configured against it.

Note: the 58 requests I mentioned here are requests, incidents, which are either resolved or closed, having a resolved date between 01/06/2018 and 30/06/2018 (tried to mimic the measure behind the "Incidents - service level success for last month" widget). I can give you the list if you want.

I haven't looked at "Service requests - service level success for last month" widget but I'm fairly confident the same above reasons apply there as well...

[lee mcdermott]

@Victor

thanks victor

so for the 11 without a catalog item I suspect some analysts I believe dont always select the catalog item. I think they get to select service as below and select next without actually clicking the Service request or Incident.

Is there anyway to force them to select it before they can select continue?

 

For the 42 requests without owner - again is there any way to force them to assign it to an owner? I thought maybe to try locking the resolution until it has been assigned to a owner then unlocking? Do you think this would work or would there be a better way to do it?

 

thanks

 

lee

[Victor]

16 minutes ago, lee mcdermott said:

Is there anyway to force them to select it before they can select continue?

Yes, there is a Service Manager app setting designed for this purpose: servicemanager.progressiveCapture.servicedetails.catalogRequired

 

 

16 minutes ago, lee mcdermott said:

is there any way to force them to assign it to an owner?

Not exactly but you can prevent request resolution/closure if the request has no owner using this Service manager app setting: app.request.allowResolveCloseWithoutAnalyst

[lee mcdermott]

@Victor

 

thats great thanks victor - I will give this ago.