Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: GitaParker
New Today: 4
New Yesterday: 33
Overall: 231652

People Online:
Visitors: 113
Members: 2
Total: 115 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Setting incident priority
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Setting incident priority

Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message

Joined: Jan 21, 2005
Posts: 1

PostPosted: Mon Jan 24, 2005 8:43 pm    Post subject: Setting incident priority Reply with quote

I'm trying to setup a manual to determine priority for our servicedesk. We are an internal servicedesk for a local government in the Netherlands. We are always having big trouble to set priority correct. Theory of this sounds easy but when trying to work it out in a practical way it seems gut-feeling is the biggest decisionmaker. This gut-feeling is feeded for a large portion by the way the customer acts. So if customer makes it sound like it's terrible the incident gets high priority 9 out of 10 times.

I would like to make this more structured. I thought this was easy but it's not. The biggest problem is that the servicedesk can not detirmine the urgengy and impact of every workprocess in the company. Besides that a certain workprocess might have only normal priority most of the time but at certain days (for example when payments must be done) it is high priority.

So far I came up with a Impact-table thats based on the impact it has on the end-customer (Civillians in our case).

For the urgency-table I was thinking about the number of employees affected by the incident.

But however I put it, these tables raise just as many questions as answers. It gets stuck by the information our users give us.
Some people always say their working processes are disrupted so badly they cannot do anything anymore. How a servicedesk can determine this is really the case? The priority tables don't seem to help in this.

Anyone here has been struggeling with this also?

- Eric -
Back to top
View user's profile

PostPosted: Sat Feb 19, 2005 1:32 pm    Post subject: Reply with quote

We usually start by asking the business to decide what it's critical business applications/processes are.
Then we agree with them at a managerial level which ones they consider should be responded to as critical...when staff cry wolf, we action their job at a high level, because they may not be crying wolf...but this information is fed back to the business managers who made that agreement to educate their staff.
Then the SD staff assign priority/serverity relating to how impaced those business aplications/processes are - which comes down to, what systems are impacted, how severly, how is this effecting the business, and how many users are impacted.
eg, if the payroll system is down, and it's payroll day, that's either urgent or critical, depending on how the client management team defined it, but if the whole network is down, and everyone can't work that's critical.
It seems like the decision on priority is being made at the user level, where it needs to be agreed first at the managerial level, then educated to the user community.
You need agreement and support from managers so they can re-educate staff who try to jump the queue.
The SD Team need a list of business critical applications to refer to.
Back to top
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sun Mar 13, 2005 4:58 pm    Post subject: Reply with quote


there are a lot of variables that feed into this kind of a problem - and there is probably a limit to what you can achieve without going 'upstream' so to speak.

The 'Guest' post made a very important point about the role of Service Level Management in defining urgency.

Urgency is the priority weighting an incident will receive on the basis of the service disrupted - regardless of what the end-user is telling you. It should be negotiated with the business customer for the service in question.

Which goes to another higher level issue - what is your incident classification based on? I've noticed there seems to be pretty much two approaches taken:

1) classifying incidents against CIs - that is the thing, what ever it is that is judged to be the locus of the incident - where the disruption occurs, like cpus, hard drives, MS Office, etc, or

2) classifying incidents against services - that is the business capability being disrupted - eg, email forwarding, monthly client account reconciliation, etc.

Personally I think the worst-case scenario is when the classification schema mixes the two - but that may just be my personality Smile

My feeling is that one serious problem with CI based classification is that you cannot easily assess the urgency in terms of Services - that is, how do you get from a CI going belly up, to an agreed urgency that was previously negotiated with business customers.

So to cut to the chase - without some maturity in your configuration management (a mechanism for seeing the relationship between CIs and Services at the front end of the incident management process) and some maturity in your service level management - you cannot objectively assess urgency - and urgency as a result will be whatever the end-user reports it to be.

Impact can be a little simpler - but bear in mind that it should be objective. Like starting with a simple measure of how many end-users are affected.

And this works better with CI based classification - obviously if a monitor on a desktop dies then 1 user is impacted (usually), whereas if a switch goes out, it may be every users on a sub-net. But again configuration management data will be required if you want to know objectively how many end-users are connected to that sub-net.

In the end you can only improve this part of incident management incrementally - and there is unfortunately no real substitute for knowledge of the business at the Service Desk.
And there is a cultural issue here as well - if you see Service Desk staff as call-centre cattle, you really can't move forward that far on this issue. Their people-skills and knowledge of the business are critical.

One thing I struggle with constantly is getting others to understand the difference between a process and a skill set - usually the problem is that people think they are implementing ITIL processes, when in fact what they are doing is creating a new kind of skill-based IT 'hero', the person on whose tribal knowledge and customer handling skills the whole outcome rests. However the reverse can be the problem too - there are points at which skill sets are a critical adjunct to process, and accurately assessing the severity level of an incident (partly by getting the right information from the reporter) is one of the sill dependent aspects of Incident Management.

As an aside - at one time, we added a "requester-urgency" field to our incident reports. This was not used in determining severity levels, but it was there for the analyst logging the incident to use a a subjective judgment of how 'bothered' the end-user was, based on their own expertise and experience in handling people. It was also the field the end-user could fill in when submitting through the self-serve web site. During the life time of the incident, the Analyst could use this field as a guide to how to 'handle' the end user when interacting with them - it turned out to be quite useful if only because it served as a reminder of the difference between psychological severity and an objectively set severity based on business rules.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.