Page 1 of 1

Incident Priority - High and downgrade or low and escalate

Posted: Tue Jun 02, 2015 5:30 pm
by TCH-Frank
Hello all. New to the forums.

I have a quick question regarding best practice. Say there is a potential incident that could occur on a fairly routine basis. This issue has the potential to be rather impactful but normally is resolved within a reasonable time.

When it comes to opening an incident... should we open it as a priority 3 and escalate it to a priority 2 based on a pre-defined SLA? Or should we start it off as a priority 2 and move it to a priority 3 if the issue is resolved within the specified time?

Thank you for your assistance!

Posted: Wed Jun 03, 2015 2:04 am
by UKVIKING
Neither. If you change the priority, up only. Down never.

Posted: Wed Jun 03, 2015 7:13 am
by Diarmid
What is the point in changing the priority after resolution? The priority is what guides your decisions about when and how much resource to spend resolving an incident.

If you lower the priority afterwards you are in effect saying that you should have tackled other incidents first but you let this one jump the queue.

Also priority has little if anything to do with SLA and much to do with business impact.

Further if an SLA is measured against individual incidents then it is not worth much as it is a hostage to fortune.

Posted: Sat Jun 06, 2015 2:04 pm
by Kranti
First get this captured in known Error Data base ,get a problem ticket raised and fix the issue permanently so that you need not increase or decrease the priority .

There is no point increasing a priority or decreasing a priority for a known issue which is closed in reasonable time

Clarification!

Posted: Mon Jun 08, 2015 11:09 am
by TCH-Frank
Thanks for the replies everyone.

It isn't an error so to speak. We monitor customer activities, and sometimes the customers are just delayed in sending us files. Normally, this doesn't pose an issue so the ticket is a priority 3. On occasion if the problem lingers it can cause major issues to other customers, hence classifying as a priority 2. The actual impact can vary based on the significance of the customer and the length of the delay.

It isn't a systematic issue so there is no work around and no reason to add to the KEDB.

Re: Clarification!

Posted: Mon Jun 08, 2015 5:44 pm
by UpritS
TCH-Frank wrote:Thanks for the replies everyone.

It isn't an error so to speak. We monitor customer activities, and sometimes the customers are just delayed in sending us files. Normally, this doesn't pose an issue so the ticket is a priority 3. On occasion if the problem lingers it can cause major issues to other customers, hence classifying as a priority 2. The actual impact can vary based on the significance of the customer and the length of the delay.

It isn't a systematic issue so there is no work around and no reason to add to the KEDB.
As you mentioned the root cause and workaround/fix is not identified it cannot be defined as a known error,
There is not enough business support doesn't mean priorities can be modified to tune up with, a priority should be based on impact / urgency, on the other hand your service level management should ensure business support in order to achieve SLA targets.

Re: Clarification!

Posted: Fri Jul 22, 2016 4:27 pm
by Garofski
UpritS wrote:
TCH-Frank wrote:Thanks for the replies everyone.

It isn't an error so to speak. We monitor customer activities, and sometimes the customers are just delayed in sending us files. Normally, this doesn't pose an issue so the ticket is a priority 3. On occasion if the problem lingers it can cause major issues to other customers, hence classifying as a priority 2. The actual impact can vary based on the significance of the customer and the length of the delay.

It isn't a systematic issue so there is no work around and no reason to add to the KEDB.
As you mentioned the root cause and workaround/fix is not identified it cannot be defined as a known error,
There is not enough business support doesn't mean priorities can be modified to tune up with, a priority should be based on impact / urgency, on the other hand your service level management should ensure business support in order to achieve SLA targets.
The root cause has been identified you just need to priorities a resolution to get it resolved. This is something that your Service Delivery team should deal with as this (as it seems from another supplier) need to be ]on top of and make sure they stick to the agreement

Posted: Tue Feb 07, 2017 12:02 pm
by lsimonsen
You should base the priority off of what the overall business impact is from the start of the incident. So if it impacts many people and external customers, then that would raise the priority level. If it only impacts 1 person and that person is internal then that is very low priority to begin with.

Now while the incident is in progress we have to use our brains to decide if the priority should be raised. For example if that 1 person being impacted is the CEO and he is saying that he will miss a very important business meeting if his phone is not fixed NOW!! well then obvious we need to raise the priority level of that. This is how we work incidents.

Now if you are talking about a problem that continues to happen the exact same way every single time and you have to do the exact same thing to fix it every time well then that should go to problem management rather than incident management yes?

Posted: Tue Feb 07, 2017 12:05 pm
by lsimonsen
UKVIKING wrote:Neither. If you change the priority, up only. Down never.
Can you site where this is stated in ITIL? I am curious to read about it.