SLA's and priority

[chriscorcoran]

Hi

 

If I update a priority once a call is logged its doesn't change the SLA, i have to manually update the SLA, is that correct even though they are linked?

Thanks

Chris 

 

 

 

SLA.pdf

SLA12.pdf

[Martyn Houghton]

@chriscorcoran

The rules are only applied when the BPM node is used to start the SLA Timers. After that point there is not active link at this time.

You have to alter the Service Level on the request by click in on blue Service Level in the right-hand panel or use a BPM node to do it. In essence the 'Escalate' action and Priority fields become historic.

Cheers

Martyn

[Victor]

10 minutes ago, Martyn Houghton said:

In essence the 'Escalate' action and Priority fields become historic

@Martyn Houghton @chriscorcoran there is a change in the backlog to cater for this scenario ... once this is deployed the "link" will be active... @James Ainsworth has more info on the change...

 

 

[chriscorcoran]

Thanks all

[James Ainsworth]

@chriscorcoran

There is also a BPM Operation that lets you update the Service Levels at a set point in the workflow.   This is particularly useful when you have a stage at the beginning of your process where an assessment takes place where you get the details you need to allocate a priority or other information that you have tied to your Service Level Targets. Once you have all the information, you use this operation to update the Service Levels.

 

There is a concern with automation when it comes to the Service Level Targets.  You may have raised a "Low" priority request that has been open for many days and someone changes the priority to "High" which had a one day target associated to it, and it is an automatic breach as you have already passed that one day target.

The manual method of changing a Service Level does protect you somewhat as it will let you know that a breach will occur before you apply the change to the Service Level.

The Priority is also only loosely connected to the Service Level Targets via the Service Level Rules where Priority is one of several options that can be used to tie in your Service Level Targets to a request.  A use case where this works well is when you have a request that starts off as Low priority, but you then allow for the priority to be increased (possibly using the automated escalations) as the Service Level Target approaches.   Something that started as Low, may be a High Priority when it is about to breach.

Saying all of this, as Victor mentioned, we do still plan on providing an option that will dynamically look for changes on a request that would require the Service Level Targets to automatically update... just watch out for the breaches!

Regards,

James

[chriscorcoran]

@James Ainsworth thanks for this. What would be really helpful would be to have services linked to priorities. At the moment our priority list is massive and although we have chosen a service when we log a call we have to go through a long list of priorities and in some cases 1st line staff are selecting the wrong level which means a call doesn't follow the BPM. Do you know if that is something that is also in the pipeline?

 

[Martyn Houghton]

@chriscorcoran

We too have a ever increasing list of priorities which we would want to link to the service/service level agreement they relate too, so only the 'appropriate' ones are listed/select-able.

 

Cheers

Martyn

[James Ainsworth]

Hi 

13 hours ago, chriscorcoran said:

Do you know if that is something that is also in the pipeline?

There are some changes in the backlog to do more with Priorities, but difficult to say if these changes will cater for these different ways of working with priorities.  Looking a your list of priority names, in my opinion these look more like the names of Service Levels.  I'm not sure what IRMA and the other abbreviation are representing, but the way the Service Levels are designed in Service Manager these  look like they may fit well as Service Levels. 

We try to provide lots of flexibility in Service Manager as everyone can operate their Service Desks in different ways and we continue to put out new features an options to continue to extend these features.

Focusing on what can be done now, and I understand that this might be a change from the way you work...   One thing that is the same throughout your priority list that you posted is the High, Medium, and Low aspect of each of these names.  The idea behind the priority list is to host these types of common priority names such as Major, High, Medium, and Low and maybe some desks will add None, as an option.  The Service Level Targets (response and resolution) are part of the Service Levels.  For each Service you can have multiple Service Levels and you can also have Corporate Service Levels to provide common levels of service without having to create duplicates on each Service.

If each of your current Priorities are there to support particular response and resolution targets, the idea would be to move these from being a Priority to being a Service Level against the Service that they represent.  I'm guessing here, but lets say that IRMA is a Service,  you could create Service Levels by these same names under the IRMA Service.  Then by using the Service Level Rules Builder you open yourself to having a number of conditions that can determine which Service Level (response and resolution targets) will be applied automatically.  This might start with matching up a priority directly to a Service Level, but you can add to this had have things like if priority is medium and the customer is CEO then use the IRMA High Service Level. 

Another way to look at the Service Levels is to think of them as per service priorities.  You could create service based priorities (Service Levels) under an IRMA Service (or using the Corporate SLA) called IRMA High, IRMA Medium, and IRMA Low.  Remove all of your current priories but leave just High, Medium, and Low.  Create Service Level rules to match up a selected priority on a request with the appropriate service based priority (Service Level).  The result would be that support staff only have 3 priorities to pick from (High, Medium, Low) and the service based priority that includes the response and resolution targets (Service Level) is applied automatically.   This takes all of the guess work out of the hands of the person raising and managing the requests.

I hope that makes sense.  I'd be interested in your thoughts on this.

Regards,

James