Closure Codes - Pro-Active trending

[PhilH]

We are looking to consolidate the current closure codes used in our Service Desk tool to assist with pro-active problem management.
I was wondering if anyone had done a similar exercise.
How many codes do you thin is manageable?
Do you have specific descriptions or are they more generic to keep the list to a minimum?

Thanks,
Phil.

[RP]

Obviously, 'Resolved' & 'Abandoned' are commonly used ones unless you have different ways of closing an incident.

'suspended' can be used when resolution couldnt be done (but can be expected) owing to a resource not being available. This includes the non-avaiability of the end user to either get and/or confirm resolution. This should eventually be changed to resolved.

'scheduled' when resolution is planned on a known date-time. this could be used when a resource (or user)will be available on a known date and resolution cant be done before that. This should also eventually be changed to resolved.

Yes it is advisable to keep the list simple unless you have varieties of possible closures (as a result of variety and volume of incidents)

[m_croon]

Actually, I would not use the closing codes. The danger you'll face, is that you use these codes for >1 reason. A logical way of using the closing codes (in my opinion) would be to let them say something about the quality of the solution, for example:
* Solved by work around
* Solved permanently
* Not solved (not reproducable)
* Not solved (too costly)
* ....
Now, if you'd combine the codes above with a code for the pro-active state of an event, this is in my opinion a combination of 2 entirely different things.

Obviously, it is usefull to have the possibility in an incident to indicate that it's wise to examine this through a problem, but than the incident has already occured, therefor your problem management would not be very pro-active. In our organisation, we have a separate button in each incident: "possible problem". Anybody can click this button, and all the problem manager has to do at the end of the week is to run a query on this button being clicked.

If you do want to realy use incidents for (more or less) pro-active problem management, I would do 2 things:
1. Use a distinguished account to log any events from your system management tool in your helpdesktool. This way, you can check frequently the ratio between the total number of logged incidents, and the number of incidents logged through this account. As the incidents logged by this account are found not through a user who called, but through your own system monitoring, this could be an indicator for your pro-activeness (not so much an indicator for problem management).

2. Use a logging category for incidents: Possible disruption. This category could be used for calls logged both by helpdesk and system monitoring. Again, by giving problem management the task to look every day or week at the number of incidents with this category, you can focus on pro-activity.

Hope this helps,

Michiel

[RP]

The closure codes based on quality of closure are interesting Michiel. Thanks for that.

If L1 or L2 agent tries to close an incident by providing permanent solution, i think he will not be doing right. His aim should be to provide a quick workaround - not (necessarily) a permanent solution. Giving a permanent fix is not the right goal for incident mgmt - hence the closure code may be inappropriate.

Besides, when an agent chooses this code, will that not be an opinion rather than a fact? You decide to close a problem record when you monitor the success of the corresponding relase for sufficient period. Isn't it? Till such time, we cannot say that the fix is successful (leave alone being permanent). Hence 'Clsd with prmnt fx' is not a useful category.

Proactive prb mgmt based on study of incident records as you rightly say is only partially proactive. I agree - would even say it is not pro-active at all.

Eventually in our organization too we have 'problem flag' which is a check box (un-checked by default) with all incident records. L1 or L2 agent can check them for further investigation by Prb Mgr.

Thanks both of you for making this interesting.

[m_croon]