Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: BernieHean
New Today: 9
New Yesterday: 31
Overall: 231513

People Online:
Visitors: 113
Members: 1
Total: 114 .



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.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - When to close the Incident ticket?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

When to close the Incident ticket?

Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message

Joined: Aug 31, 2005
Posts: 2

PostPosted: Thu Sep 01, 2005 1:42 am    Post subject: When to close the Incident ticket? Reply with quote

Hi there,

My first post so be gentle Smile

I was just wondering, when an incident is raised that ultimately becomes a problem and a problem call is raised, at what point should the Incident call be resolved?

I understand that the Incident call can be closed when a workaround is implemented, but what happens if there is no workaround and the user/s must simply hang on until the undrlying problem (and thus it's associated Problem call) is resolved? Does the Incident ticket remain open? This seems a little illogical to me.
Back to top
View user's profile

Joined: Aug 31, 2005
Posts: 3

PostPosted: Thu Sep 01, 2005 5:56 am    Post subject: Reply with quote

The incident call should be always closed as quickly as possible. The main determinant is to restore the service for the User. It doesn't mater how (it can be workaround) but when. From my point of view it is rather not posible that user is affected longer time and there is no workaround. The problem call is opened to investigate the root cause of the incident (or group of incidents) and to find permanent solution. If the cause and action which allow to eliminate the problem are know the problem call can be closed. On that point the change call should be opened which can be closed after the implementation of change.
Back to top
View user's profile
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu Sep 01, 2005 10:26 am    Post subject: Reply with quote

Remeber that one of the key metrics is 'Time to Repair' (and its aggregate Mean Time to Repair).

That is, it's not Time to Closure. Personally, I don't really like 'Repair' as it focuses the attention on break-fix incidents. I prefer 'Resolution'. And most tool sets use Resolved as a status value for an incidenet record.

Closure occurs after a predetermined lag and/or negotiation with the end-user / customer (depending on the classification, context, impact, SLA etc...)

So in the first instance, you should be looking at how quickly (and effectively) incidents move to resolved / restored / repaired / whatever...

As _GrenDel_ (is that a reference to Beowulf?) implied incidents that remain unresolved because there is no acceptable work around are likely to be rare. But they can occur, and even remain unresolved after a known error is registered against the underlying problem, because the ability to implement the required changes may be beyond current capability. For example, what if the problem is tracked to an error in the code base of a closed-source application, and you are going to have to wait until the vendors get around to providing a patch? There may not be much you can do - other than reaching for a loaded lawyer Smile

When this happens you absolutely want to keep your incidents open. ITIL isn't just about Service Support - keeping things ticking along. It is also about Service Delivery - planning and improving. And that requires information that reflects what is actually happening. Never fluff the data - it isn't about getting 'sweet numbers' it is about getting accurate ones.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger

Joined: Aug 31, 2005
Posts: 2

PostPosted: Thu Sep 01, 2005 6:59 pm    Post subject: Reply with quote

Thanks for the comments guys. Most helpful. However, for whatever reason I would suggest that the frequency of incidents that we get raised that we are not able to resolve either permanently or with a workaround within the allotted SLA is relatively frequent. In these instances we will raise a problem call in order to find an ultimate resolution, but until we do, often the users just have to wait.

We had a good example of this a couple of days ago when our exchange server developed a strange error whereby internal emails were not being sent or received. Nobody in-house could resolve the issue, and in the end we had to get Microsoft to assist. Obviously, whilst this was all going on we were logging multiple related incident tickets as users called the Service Desk.

My question, in light of the above expample, was should we have closed the incident tickets once we realised that there was a Problem and had subsequently raised a problem call? My gut feeling was yes, but in retrospect, and after having read your emails, I now feel that it should have been no. We should have left the Incident call open until a permanent resolution was found via the Problem investigation. That way our metrics would have reflected the real impact on the service rather than just the time it took to recognise that there was a problem.

Thanks again guys.
Back to top
View user's profile

Joined: Aug 31, 2005
Posts: 3

PostPosted: Fri Sep 02, 2005 6:55 am    Post subject: Reply with quote

From my point of view incident can be closed after restoration service for the user. Moreover user have to confirm that he happy and his issue is fixed After that the incident can be closed. This way which you have presented for me is not acceptable because you cheat SLA (if you close incident in order not to breach the time of resolution)
In the situation which you have presented the problem call can be opened simultaneously with incident and closed after revealing the root cause (probably at the same time as incident)
Back to top
View user's profile
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Mon Sep 05, 2005 8:42 pm    Post subject: Reply with quote


your example is most illuminating.

Where ITIL based processes are mature they work in concert. In the early stages the requirement to get a workable definitions and clear concepts into the processes can obscure the practical imperatives a little - perhaps by creating an underlying either/or assumption.

What you describe, in my opinion is a Major Incident - and a Problem

It may be helpful to consider that a single event can be more than one 'ITIL entity' at the same time.

As a disruption to a service it is an incident. An accordingly _GrenDel_ is correct to say that leaving the incidents open is best because it reflects actual delivery.

As a failure in a system that is a constituent of the Service it is also a problem.

A large number of incidents will be caused by a fault somewhere, so a both/and understanding is helpful.

To me, you described a major incident that required escalation to vendor support. As no workaround could be found, the incident was immediately raised as a 'Problem' - something done implicitly when you went into root cause analysis - and an emergency change undertaken. But even though this was the case the disruption to the service remained, and therefore so did the incident.

Is this unecessarily 'officious'? Maybe in the case you described - but on average no.

As for the incident reports pouring in - it is customary with incidents, especially major ones, to designate one report as a parent incident, and relate all further instances as 'duplicates' - while recording the end users details against them there is no need to retake the details in each case.

Most of the better ITSM tools have assistance for efficient tagging of duplicates built in. And when the parent incident is set to 'resolved' they automatically propogate the status change to all the 'duplicate' incidents.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.