Closing the Service Call Ticket

[jeffendy]

I heard two different opinions on closing the Service Call ticket. When I was attending the ITIL Foundation for ITSM training, the trainer said that the Service Call ticket cannot be closed when we are using the workaround to temporary solve the incident. The ticket will remain open until the permanent solution applied.

In other product briefing workshop, the trainer told me that the aim of Incident Management is to restore the service as soon as possible, it doesn't matter whether we use workaround or permanent solution. In this case the ticket can be closed when the service return back to normal even if tomorrow the user call again reporting the same problem.

Need feedback on this issue.

[itilimp]

Hmm, well if my understanding is correct then I'd say you received some inaccurate information from the first trainer.

You are correct in that the goal of incident management is to get the user working again as soon as possible, with a workaround if necessary.

However, if there is an underlying problem that requires a permanent fix then this should be raised under the problem management process as a new problem (or the incident associated to a pre-existing problem if there is one).

Hope that clarifies things for you.

[m_croon]

ITILIMP is right, as soon as the service is restored, the incident (service call) can be closed. Of course it is wise to link it to a problem to find out the root cause and solve it. As >1 service call with the same symptoms might be logged, it will give you greater insight in impact and frequency (and therefor of priority) of the occurence of this rout cause.

[hipfan]

Understanding that an incindent is closed once the service has been restored, in your opinions, would this be AFTER the Service Desk has confirmed with the customer that the issue is resolved? I would think yes, however sometimes this formal closure of the incindent may not take place for a week or more. In this scenrio, if the incident re-occurs, would another incident record be recorded, or would the initial be placed back to an "open" status?

[ARoll]

Completely with the above in explaning when it shoul dbe closed.

You would want to create a new incident if the user calls back and i really can't think of why you would want to re-open a closed ticket(with maybe the exception accidently closed). If you are re-opening old tickets you basically lose your measurement on the number of occurances that a particular issue is happening. Also if your closure confirmation time is taking a week or more, sounds like may need to find another solution for confirming. An option, possibly, that would allow your customer to confirm online that their issue has been closed. This would help alleviate some of the work on your service desk.

[dboylan]

I think there are situations where the Incident can be closed to a Workaround, and a second or even third Incident should be opened to restore the user to a normal state and undo the Workaround without involving Problem Management.

An example would be a user calls the Service Desk because they are unable to print to a networked printer. The Service Desk person implements an approved Workaround by routing the user to another, equally capable networked printer. Incident number one is now closed.

But the original printer is still broken. A second Incident is opened to address the broken printer. This would not go to PM because you are not going to do any Root Cause analysis, just swap the broken printer out with a working one. Incident two closed.

A third Incident could then be opened by the user requesting that they be re-routed back to their original printer (although, at this point it is probably a Service Request, since there is no loss of service involved). Incident number three closed.

Now I have been in a room of ITIL experts who have discussed different ways automated systems could handle this, including Incidents and sub-Incidents with parent child relationships. But the fact is that if the user's service was restored but then left in a less than desirable state (but within the agreed SLA), a second Incident probably needs to be opened to address restoring them to their original state.

[hipfan]

[jpgilles]

Depending on the tool you are using for Incident Management you may have 2 closure steps:

1: Technical closure: the service is said to be back by the technician (like your database was restarted)
2: administrative closure: the user confirms the service is back for him/her

Therefore , if the user does not confirm, the ticket is still open, and work will be carried on again to bring the service back "under the same ticket".

If the services fails again later on, a new ticket will be open.

This 2 steps are important if you use delay of incident resolution in your KPIs, as you can track both delays:
1: will be used to measure the performance of the IT staff in restoring the service
2: will be used to measure the total unavailibility (considering that as long as you cannot get a hold on the customer to ask for a confirmation , he/she may not be aware that the service is back ... just waiting for your call at the coffee machine...)

Difference between 2 and 1 is also an interesting indicator.

PS: just seems that the trainer in first place was mixing incidents and problems (strange for an ITIL trainer).
_________________
JP Gilles