Incident escalation

Initial diagnosis

If the incident has been routed via the Service Desk, the Service Desk Analyst must carry out initial diagnosis, typically while the user is still on the telephone – if the call is raised in this way – to try to discover the full symptoms of the incident and to determine exactly what has gone wrong and how to correct it. It is at this stage that diagnostic script s and known error information can be most valuable in allowing earlier and accurate diagnosis.

If possible, the Service Desk Analyst will resolve the incident while the user is still on the telephone – and close the incident if the resolution is successful.

If the Service Desk Analyst cannot resolve the incident while the user is still on the telephone, but there is a prospect that the Service Desk may be able to do so within the agreed time limit without assistance from other support group s, the Analyst should inform the user of their intentions, give the user the incident reference number and attempt to find a resolution.

• Functional escalation. As soon as it becomes clear that the Service Desk is unable to resolve the incident itself (or when target times for first-point resolution have been exceeded – whichever comes first!) the incident must be immediately escalated for further support.

If the organization has a second-level support group and the Service Desk believes that the incident can be resolved by that group, it should refer the incident to them. If it is obvious that the incident will need deeper technical knowledge – or when the second-level group has not been able to resolve the incident within agreed target times (whichever comes first), the incident must be immediately escalated to the appropriate third-level support group. Note that third-level support groups may be internal – but they may also be third parties such as software supplier s or hardware manufacturers or maintainers. The rules for escalation and handling of incidents must be agreed in OLAs and UCs with internal and external support groups respectively.

Note: Incident Ownership remains with the Service Desk! Regardless of where an incident is referred to during its life, ownership of the incident remains with the Service Desk at all times. The Service Desk remains responsible for tracking progress, keeping users informed and ultimately for Incident Closure.

• Hierarchic escalation. If incidents are of a serious nature (for example Priority 1 incidents) the appropriate IT managers must be notified, for informational purposes at least. Hierarchic escalation is also used if the ‘Investigation and Diagnosis ’ and ‘ Resolution and Recovery ’ steps are taking too long or proving too difficult. Hierarchic escalation should continue up the management chain so that senior managers are aware and can be prepared and take any necessary action, such as allocating additional resource s or involving supplier s/maintainers. Hierarchic escalation is also used when there is contention about to whom the incident is allocated.

Hierarchic escalation can, of course, be initiated by the affected user s or customer management, as they see fit – that is why it is important that IT managers are made aware so that they can anticipate and prepare for any such escalation.

The exact levels and timescales for both functional and hierarchic escalation need to be agreed, taking into account SLA targets, and embedded within support tools which can then be used to police and control the process flow within agreed timescales.

The Service Desk should keep the user informed of any relevant escalation that takes place and ensure the Incident Record is updated accordingly to keep a full history of actions.

Дата добавления: 2014-12-23