Incident and Problem Management - Closing an incident

When a potential resolution has been identified, this should be applied and tested. The specific actions to be undertaken and the people who will be involved in taking the recovery actions may vary, depending upon the nature of the fault - but could involve:

• Asking the user to undertake directed activities on their own desk top or remote equipment
• The Service Desk implementing the resolution either centrally (say,rebooting a server) or remotely using software to take control of the user's desktop to diagnose and implement a resolution
• Specialist support groups being asked to implement specific recovery actions (e.g. Network Support reconfiguring a router)
• A third-party supplier or maintainer being asked to resolve the fault.

Even when a resolution has been found, sufficient testing must be performed to ensure that recovery action is complete and that the service has been fully restored to the user(s).

The Service Desk should check that the incident is fully resolved and that the users are satisfied and willing to agree the incident can be closed. The Service Desk should also check the following:

• Closure categorization. Check and confirm that the initial incident categorization was correct or, where the categorization subsequently turned out to be incorrect, update the record so that a correct closure categorization is recorded for the incident - seeking advise or guidance from the resolving group(s) as necessary.
• User satisfaction survey. Carry out a user satisfaction call-back or e-mail survey for the agreed percentage of incidents.
• Incident documentation. Chase any outstanding details and ensure that the Incident Record is fully documented so that a full historic record at a sufficient level of detail is complete.
• Ongoing or recurring problem? Determine (in conjunction with resolver groups) whether it is likely that the incident could recur and decide whether any preventive action is necessary to avoid this. In conjunction with Problem Management, raise a Problem Record in all such cases so that preventive action is initiated.
• Formal closure. Formally close the Incident Record.

Note: Some organizations may chose to utilize an automatic closure period on specific, or even all, incidents (e.g. incident will be automatically closed after two working days if no further contact is made by the user). Where this approach is to be considered, it must first be fully discussed and agreed with the users - and widely publicized so that all users and IT staff are aware of this. It may be inappropriate to use this method for certain types of incidents - such as major incidents or those involving VIPs, etc.

Rules for reitilfoundations.compening incidents

Despite all adequate care, there will be occasions when incidents recur even though they have been formally closed. Because of such cases, it is wise to have pre-defined rules about if and when an incident can be reitilfoundations.compened. It might make sense, for example, to agree that if the incident recurs within one working day then it can be reitilfoundations.compened - but that beyond this point a new incident must be raised, but linked to the previous incident(s).

The exact time threshold/rules may vary between individual organizations - but clear rules should be agreed and documented and guidance given to all Service Desk staff so that uniformity is applied.

---

Other ITIL Processes

Operational Layer:

• Configuration Management
• Service Desk Management
• Incident & Problem Management
• Change Management
• Release Management

Tactical Layer:

• Service Level Management
• Availability Management
• Capacity Management
• Continuity Management
• Financial Management