How to Track Incident Closures Effectively
Incident is an unplanned interruption. When the operational status of any activity turns from working to failed and causes the system to behave in an unplanned manner it is an incident. More than one incident can give rise to a major problem which should be resolved, preferably as soon as possible. This article describe the details about incident closure monitoring methods and its importance. Timely and effective incident closures help in eliminating repeated flaws and avoiding similar incidents to be arising in future; thus increasing client satisfaction. The previous blog mentions 7 Ways to Increase Help Desk Efficiency and this article gives you a deep dive into one of the most important aspect to turn your helpdesk into an efficient tool for service delivery. Let me give you an insight on How to Track Incident Closures Effectively.
Who tracks incident closure and what actions are taken?
Incident closure is performed by the service desk operators. It is the final step in the incident management process and includes a number of activities.
Amongst the checklist of activities that need to be performed is verification of the initial categorization that was assigned to the incident and a satisfaction survey of the end user regarding the way the incident was handled.
The incident is formally closed; BUT in rare circumstances an incident can be re-opened. Incident re-opening should be defined in terms of metrics. A common example is that if an incident re-occurs within a 12 or 24 hour period, then the original incident can be re-opened, otherwise a new incident must be logged.
Incident resolution and closure
We know it is not over until the customer confirms it is over. Hence the two-step resolution:
- An assigned engineer says it is over
- Customer contact person confirms it is over OR a reasonable amount of time passes since the resolution without the customer complaining
Here is a more detailed review of the issues that have to be addressed during incident closure and resolution:
1. Resolution
An assigned operator or engineer declares that the service is restored and puts the incident record into “Resolved” status.
2. Remember
The owner of the incident, SD operators, have to check if the service is really fully restored. Also, sometimes the process is charged to the customer by the time spent on the incident, so Service Desk checks if the work hours have been entered in the incident record or the corresponding time-sheet application.
This is also a good time to check the initial category or affected services set in the diagnosis/ classification phases of the incident. The Service Desk should check every incident category during resolution and correct it if necessary.
3. Customer satisfaction
There are a number of ways we can rate customer satisfaction during incident closure. The most obvious method is to ask the customer to respond to a set of short questions about every single incident during the resolution phase.
A more general impression of customer satisfaction can be achieved by periodic meetings with customer representatives, i.e. monthly or quarterly meetings.
Other methods like phone surveys and group interviews can be effective.
4. Knowledge
If a Knowledge Management (KM) process is implemented, the Service Desk can mark this resolution as a knowledge base article.
5. Closure
We expect the customer to confirm the resolution of the incident. This can be done by a phone call with the Service Desk, a reply to an automatic notification from the ticketing application or via a web- based application. After the customer confirmation, an incident record can safely be put into “Closed” status. The customer should be notified upon closure.
6. Reopen
Very often, there are various cased where there are response to a closure notification. Such incidents have to be reopened by the Service Desk, and treated as “work in progress”.
The following entries of an Incident Record are investigated for their integrity and completeness during the closure of an Incident to track incident closures effectively :
Protocol of actions:
- Person in charge
- Support Group
- Time and Date
Description of the activity
- History of status changes, for example “New” into “Initial Analysis Completed”
- “Initial Analysis Completed” into “Assigned to 2nd Level Support”
- “Resolved” into “Closed”
Documentation of applied Workarounds
Documentation of the root cause of the Service interruption
Documentation of the applied resolution to eliminate the root cause
Date of the Incident resolution
Date of the Incident closure
Why we need to track incident closures effectively?
Closed incidents will be filtered out of view, but will remain in the system for reference purposes. Closed incidents can be reopened if the user or service desk believes that it needs to be reopened.
Incidents that are on the Related Incidents list of a problem can be configured to close automatically when the problem is closed through business rules.
If the knowledge check box is selected, a business rule is triggered by closing the incident, and a knowledge article is generated with the information from the incident. This is useful for knowledge management, and knowledge-centered support, reducing the number of repeat incidents by distributing the information related to the incident.
It is also possible to generate customer satisfaction surveys upon closure of incidents. This allows the service desk to gather information about their quality of service directly from the user.