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!
Incident Priority - High and downgrade or low and escalate
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.
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
William Penn 1644-1718
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
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 ®
Project Manager - SAP
ITIL® Expert
Prince2®
CSM® CSPO® CSP®
PMI® SAP®
Lean Six Sigma Black Belt ®
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.
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,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.
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 agreementUpritS wrote:As you mentioned the root cause and workaround/fix is not identified it cannot be defined as a known error,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.
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.
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?
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?