Incident Priority - High and downgrade or low and escalate

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply

Incident Priorities

Start at priority 3 and raise to 2 based on SLA
0
No votes
Start at priority 2 and lower to 3 based on issue being resolved within the SLA
0
No votes
 
Total votes: 0
User avatar
TCH-Frank
Newbie
Newbie
Posts: 2
Joined: Mon Jun 01, 2015 8:00 pm

Tue Jun 02, 2015 5:30 pm

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!


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3634
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Wed Jun 03, 2015 2:04 am

Neither. If you change the priority, up only. Down never.
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Wed Jun 03, 2015 7:13 am

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.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
Kranti
Senior Itiler
Senior Itiler
Posts: 59
Joined: Thu Jun 04, 2015 8:00 pm
Location: Hyderabad ,India

Sat Jun 06, 2015 2:04 pm

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
Kranti Kiran Kumar Gedela

Project Manager - SAP

ITIL® Expert
Prince2®
CSM® CSPO® CSP®
PMI® SAP®
Lean Six Sigma Black Belt ®
User avatar
TCH-Frank
Newbie
Newbie
Posts: 2
Joined: Mon Jun 01, 2015 8:00 pm

Mon Jun 08, 2015 11:09 am

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.
User avatar
UpritS
Itiler
Itiler
Posts: 5
Joined: Sun Jun 07, 2015 8:00 pm

Mon Jun 08, 2015 5:44 pm

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.
User avatar
Garofski
Itiler
Itiler
Posts: 9
Joined: Mon Aug 11, 2008 8:00 pm

Fri Jul 22, 2016 4:27 pm

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
User avatar
lsimonsen
Itiler
Itiler
Posts: 5
Joined: Mon Jan 30, 2017 7:00 pm

Tue Feb 07, 2017 12:02 pm

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?
User avatar
lsimonsen
Itiler
Itiler
Posts: 5
Joined: Mon Jan 30, 2017 7:00 pm

Tue Feb 07, 2017 12:05 pm

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