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.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Closing the Service Call Ticket
Joined: Aug 20, 2006 Posts: 25 Location: Indonesia
Posted: Sun Aug 20, 2006 3:49 pm Post subject: Closing the Service Call Ticket
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.
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).
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Mon Aug 21, 2006 5:27 am Post subject:
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.
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?
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.
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Sat Apr 14, 2007 9:51 am Post subject:
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.
"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.
I agree completley with your response. However, I am not referring to incidents which have been "Closed" yet, in the situation where, for example, the incident record states are as follows:
1. Open - logging of incident
2. Work in Progress - Incindet has been assigned and is being worked on
3. Resolved - Service has been recovered
4. Closed - Confirmation has been recieved from customer that issue has been resolved.
Now say that a database has hung and an incident record has been created. The database has been recovered. The incident has been placed in "resolved" status (however confirmation from the customer has not been recieved, so the incindent has not been "closed" yet). The database hangs again... recovers... and hangs again.
Again, the incindet is still in "resolved" status, and has not yet been closed. In this situation would you create multiple incindent records (one for each occurence) or possibly change the "resolved" status of the one incident record to "Work in Progress"? Using the later would not show a true indication of the number of occurences, however I guess I'm struggling to understand how you could "Close" the incident when the issue still exists.
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
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