Passwords resets

[Susannah]

Does anyone know how a password should be logged via the Service Desk. Currently they are being logged as Incidents of the highest priority because it's stopping the user from working. Someone has suggested that these should actually be logged as non-fault incidents instead, then when running reports they can see the percentage of incidents and password resets coming into the Service Desk.

Thanks
_________________
Susannah

[Roger]

Simple answer - It all depends !!!

Some organizations will choose to log a forgotten password as an incident... others will choose to log it as a Service Request on the basis that there is no issues with the infrastructure - it is an end user issue.

The "it all depends" answer is best... and it all depends on what is defined in the Service Levels for the service/s that the user cannot access when the password is forgoten. This is the definition of Incident Management.

A Doctor working in critical care unit of a hospital may in fact require immediate and high priority service to reset a password. An junior office staff member may be able to find plenty of other things to do if the password is forgotten.

[Ed]

Hi Susannah

we have these set up as a Standard Change, they are not Priority 1 because they only stop the user from working, not the whole company,and usually there is a workaround. These come well down the priority pecking order. As the Standard Change allows for immediate implementation by the Service Desk agent, there should be no loss of access for the user.

Regards

Ed

[eisbergsk]

my 2 cents....

'time' is a factor that can up the severity of an incident... the longer something takes to resolve, the bigger deal it is for the person impacted by it.... so ...... we moved the ability to reset passwords for our users for all our applications and environments to the Service Desk (after making sure the processes were standardized, of course ). You call to ask for a reset, and it's done while you are on the phone. no muss, no fuss. no Sev 1.
/Sharon

[kitkatkirsty]

Hi Susanna,

A simple way of dealing with password resets is to make this an automated function either through a web self service portal or through a voice self service system. That way you can route these calls and the high call volume they create away from the service desk. FrontRange ITSM or HEAT Service and Support can provide this functionality along with IPCC.

Kitkat

[littlegong]

Personally, I would not class it as you have been. Although it is important that a user get back to work ASAP, it’s not going to stop the business which a priority 1 would indicate.

If EVERYONE had password issues at the same time then yes it would be a priority 1.
The best system I have come across is an automated system which is set up when the user first gets access to the network.
The user is required as a part of their induction to set up secret questions which can be accessed via a website, so if they forget their password they can go and answer these secret questions from a colleague’s machine, or their immediate manager. Only flaws I could see was if there were no team mates around, but it cut out a lot of calls to the service desk. The incidents were recorded automatically via the password reset function.
It enabled service desk to focus on other issues which cannot be automated.

Regards

Scott

[goitilcouk]

My view (as highlighted by others) is it really comes down to service level expectations. You are correct that a single user not working it is not a P1 but culturally, a lot of organisations see this not only as a high priority but also a "temperature check" of just how goot an IT department is.

Your initial question was about classification ?

That really depends on your trend analysis - are you looking to identify what volume of calls are passwork resets or are you trying to identify what systems are requesting the most resets? Thats really where you classification is going to add value?

Next comes priority ? We utilise a P3 as a "single user - immediate response", this alows for VIP calls and password resets to jump the queue. Not pure ITIL but developed to meet company expectations (which is in essence SLM?)

Finally closure classification ? loads to go for here ranging from forgotten passwords to user did not renew during 14 day reminder cycle to system issues causing passwords to get locked. Once again, its driven by your trend analysis - what are you trying to achive

hope this gives you a different slant
Rob

[ultraimports]

IMO, Service Request...nothing is really "broken" so my group wouldn't see it as an Incident...

Also, not a standard change unless you count network accounts as CI's...AD maybe, but not individual accounts....

Just my 2 cents...high priority due to the simplicity, but service request in my eyes..