Incident Management - Logging

All incidents must be fully logged and date/time stamped, regardless of whether they are raised through a Service Desk telephone call or whether automatically detected via an event alert.

Note: If Service Desk and/or support staff visit the customers to deal with one incident, they may be asked to deal with further incidents 'while they are there'. It is important that if this is done, a separate Incident Record is logged for each additional incident handled - to ensure that a historical record is kept and credit is given for the work undertaken.

All relevant information relating to the nature of the incident must be logged so that a full historical record is maintained - and so that if the incident has to be referred to other support group(s), they will have all relevant information to hand to assist them.

The information needed for each incident is likely to include:

• Unique reference number
• Incident categorization (often broken down into between two and four levels of sub-categories)
• Incident urgency
• Incident impact
• Incident prioritization
• Date/time recorded
• Name/ID of the person and/or group recording the incident
• Method of notification (telephone, automatic, e-mail, in person, etc.)
• Name/department/phone/location of user
• Call-back method (telephone, mail, etc.)
• Description of symptoms
• Incident status (active, waiting, closed, etc.)
• Related CI
• Support group/person to which the incident is allocated
• Related problem/Known Error
• Activities undertaken to resolve the incident
• Resolution date and time
• Closure category
• Closure date and time.

If the Service Desk does not work 24/7 and responsibility for first-line incident logging and handling passes to another group, such as IT Operations or Network Support, out of Service Desk hours, then these staff need to be equally rigorous about logging of incident details. Full training and awareness needs to be provided to such staff on this issue.

Categorization

Part of the initial logging must be to allocate suitable incident categorization coding so that the exact type of the call is recorded. This will be important later when looking at incident types/frequencies to establish trends for use in Problem Management, Supplier Management and other ITSM activities.

Please note that the check for Service Requests in this process does not imply that Service Requests are incidents. This is simply recognition of the fact that Service Requests are sometimes incorrectly logged as incidents (e.g. a user incorrectly enters the request as an incident from the web interface). This check will detect any such requests and ensure that they are passed to the Request Fulfilment process.

Multi-level categorization is available in most tools - usually to three or four levels of granularity. All organizations are unique and it is therefore difficult to give generic guidance on the categories an organization should use, particularly at the lower levels. However, there is a technique that can be used to assist an organization to achieve a correct and complete set of categories - if they are starting from scratch! The steps involve:

1. Hold a brainstorming session among the relevant support groups, involving the SD Supervisor and Incident and Problem Managers.
2. Use this session to decide the 'best guess' top-level categories - and include an 'other' category. Set up the relevant logging tools to use these categories for a trial period.
3. Use the categories for a short trial period (long enough for several hundred incidents to fall into each category, but not too long that an analysis will take too long to perform).
4. Perform an analysis of the incidents logged during the trial period. The number of incidents logged in each higher-level category will confirm whether the categories are worth having - and a more detailed analysis of the 'other' category should allow identification of any additional higherlevel categories that will be needed.
5. A breakdown analysis of the incidents within each higher-level category should be used to decide the lower-level categories that will be required.
7. Review and repeat these activities after a further period - of, say, one to three months - and again regularly to ensure that they remain relevant. Be aware that any significant changes to categorization may cause some difficulties for incident trending or management reporting - so they should be stabilized unless changes are genuinely required.

If an existing categorization scheme is in use, but it is not thought to be working satisfactorily, the basic idea of the technique suggested above can be used to review and amend the existing scheme.

NOTE: Sometimes the details available at the time an incident is logged may be incomplete, misleading or incorrect. It is therefore important that the categorization of the incident is checked, and updated if necessary, at call closure time (in a separate closure categorization field, so as not to corrupt the original categorization)

---

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