Incident Management Process
Be descriptive when entering the resolution text so that the incident record may be useful in future as part of the knowledge base. “Fixed” or “Resolved” is not acceptable
Make sure the incident is set to the correct status at all times, including when waiting for feedback from the user as the clock will be stopped at this point
Following these rules will mean that a clear, concise picture of the status of every incident is available at all times. The length of time it takes to resolve an incident is of course a key metric when determining the level of service being delivered. There are times however when the duration of the incident is affected by circumstances outside the control of [Service Provider] and therefore the elapsed time does not represent a true picture of service provided. In this situation it is acceptable to stop the clock and restart it again when control is once again within [Service Provider]. These circumstances are:
Waiting for further information from the user without which diagnosis and resolution of the incident cannot progress e.g. which printer is not working, what do they mean by “broken”
Waiting for the user to test whether the incident is resolved
Where the incident is waiting for information or assistance from a third party supplier this will not stop the clock as it is a part of the service provided by [Service Provider]. Contracts with suppliers will be aligned with the SLA so that they provide support within the SLA timeframe agreed with the users
2.4.10 Resolution Identified?
Based on the investigation and diagnosis carried out, a potential resolution to the incident may be identified and this may need to be tested and confirmed in the next step of the process. However, if no potential resolution has been found a further step of functional escalation may be required. This could be to the next level in the hierarchy of technical teams or could be to another team at the same level e.g. if the server team has ruled out a server issue and passes the incident to the networking team so that possible network causes may be investigated. In addition, hierarchical management escalation may be required if the incident is proving difficult to resolve and all existing avenues of support have been explored. It may be necessary to involve a specialist external organization which is not part of the normal escalation process.
Version 1
Page 17 of 43
Insert date Powered by CertiKit