ITIL - Defaulting Urgency/Impact in User Interface

[Aluria]

I am not sure if this is the correct forum for this question, but my group has been asked to change our Tool, CA Service desk, to always default both urgency and Impact to a specific option (in this case 5 - the lowest). This is because users complain they don't want to have to remember to set those 2 fields and we make them required (we drive priority by Urgency/Impact).

My question is this the right thing to do. I beleive it isn't as it wouldn't force users to tell the support group the correct Urgency / Impact, and often times it would end up with the tickets being reset later in the process.

Any giudance is appreciated. Thanks.

[rickyticky]

We take the same approach for our Self Service(SS) ticketing. However, we tell them up front that the Self Service tickets are for low priority events. Also, that does not mean that your Service Desk team can't review the SS tickets and raise the priority where needed.

[UrgentJensen]

Hi Aluria,

I tend to agree with RT. I have never given customers the ability to choose priority for themselves. In fact I'd go so far as to say it defeats the purpose of service management because you're taking away it's ability control demand and supply to IT.

Cheers,

UJ
_________________
Did I just say that out loud?

(Beige badge)

[Diarmid]

Hi,

Users are being asked to to state urgency and impact from which will be derived priority, and they ought to where they can it is as much part of there job as reporting the incident.

Now sometimes these cannot be realistically be determined at the point of incident because the reported incident is a symptom of something bigger. When this happens, the service desk or support may (or may not - it all depends) be able to see the implications right away. That is why you need flexibility to update the information and recalibrate the incident.

Sometimes the user will (inadvertently or otherwise) exaggerate the urgency or impact. Again recalibration required.

The whole prioritization should be underpinned by customer requirement and evaluation of worth and this can include the customer asserting the capability - or otherwise - of users to inform on priority.

The practical point of the question is whether setting defaults will lead to better (and quicker) correct prioritization of incidents. I would suggest that the answer is very organization dependent and also largely affected by the type of services involved and the skill set of the users who might report incidents.

Forcing users to fill in these two fields will help if the users have a reasonable understanding of the implications, but not if they will just be guessing. One possibility is to provide a "don't know" value and to treat such entries to rapid evaluation by the service desk.

Of course much depends on users understanding that better information leads to quicker restoration of service.
_________________
"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