IncidentHandling

Throughout the Incident lifecycle, nearly all specialist IT groups will handle an Incident at some stage. To do this efficiently and effectively requires a formal approach. This facilitates the timely identification of problems.

 

A way of tracking back is required. It is recommended that the Incident records should be held on the same Configuration Management Database (CMDB) as the Problem, Known Error and Change records, or at least linked without the need for re-keying, to improve the interfaces and ease interrogation and reporting.

 

Incident priorities and escalation procedures need to be agreed as part of the Service Level Management process and documented in the SLAs. The Service Desk is the single point of contact between service providers and users, or their representatives, on a day-to-day basis.

 

The status of an Incident reflects it current position in its life-cycle, sometimes known as its ‘workflow position’. Everyone should be aware of each status and its meaning. Some examples of status categories might include:

–          New

–          Accepted

–          Scheduled

–          Assigned / Dispatched to specialist

–          Work in Progress (WIP)

–          On hold

–          Resolved

–          Closed

 

Throughout an Incident life-cycle it is important that the Incident records is maintained. This allows any member of the service team to provide a Customer with an up-to-date progress report. Example update activities include:

–          Update history details

–          Modify status (e.g. ‘new’ to ‘work-in-progress’ or ‘on hold’)

–          Modify business impact / priority

–          Enter time spent and costs

–          Monitor escalation status

 

An originally reported Customer description may change as the Incident progresses. It is, however, important to retain the description of the original symptoms, both for analysis and so that you can refer to the complaint in the same terms used in the initial report. For example, the Customer may have reported a printer not working, which is found to be have been caused by a network failure. When responding to the Customer it is better initially to explain that the printer Incident has been resolved rather than to talk about the resolution of the network Problems.

 

Ready to buy? Order the Help Desk Toolkit today