Incident Management IT Service Management

Should Incidents Be Re-Opened?

Should Incidents be re-opened? The simple answer is: yes, if it was Closed incorrectly. Incorrect closure may include incorrect or incomplete testing or failure to confirm service restoration with the customer or user. However, IT environments are complex and reality is seldom so simple. I advocate instead against reopening Incidents, after a 2-3 day Resolved period.

The best trade-off, in general, is to allow a 2-3 day burn in period, during which the request is fulfilled or the Incident is Resolved. Resolved means service has been restored, the affected parties have been notified, and all records have been updated. The contact now has 2-3 days to test and validate before the Incident record is Closed, generally automatically by the tool workflow. Once Closed, the Incident cannot be reopened.

There exists perverse incentives to create multiple Incidents, particularly in a pay-per-issue billing model. On the other hand, there is also the opposite perverse incentive to re-open Incidents for new Incidents or requests, and to include multiple, unrelated requests in the same issue. Sometimes this happens just out of laziness, i.e. it is faster to reply to an existing email than to fill in a new one.

In addition there is gray area between what is a new Incident and what is an existing Incident. Some errors are intermittent. Restarting the device or application may restore service, but the Incident may occur again in a few hours, days, or weeks. In this case a Problem record should be raised, but the Incident may reoccur before the Problem Management and Change Management processes can run their course. Are these repeat Incidents new or existing? Every organization should have its own answer and it depends on the Incident. A 2-3 day separation between recurrences is a good, general policy to distinguish between new and existing ones.

Organizations who choose to re-open Incidents should track these Incidents. An independent party should verify they were re-opened appropriately, and any inappropriate activities should be managed through administrative or disciplinary actions, hand-slapping, or public humiliation. If this sounds bureaucratic or patriarchal, it is. In general it is easier to define in terms of time and enforce with a tool.

The 2-3 day Resolved period is not perfect for all situations and not suitable for all organizations. However, I have found through experience it is a good solution that is flexible, widely applicable, unbureaucratic, conceptually simple, and generally fair to all parties. Once Closed, the Incident should remain Closed.

2 replies on “Should Incidents Be Re-Opened?”

Service Level Management is a relevant topic I didn’t mention. You are correct that these can stay open for too long while the assignee awaits confirmation from the user or customer. Resolved can also help with this use case. In organizations with strong emphasis on SLA’s, the tool must be able to stop the SLA clock while in Resolved. In this post I made an assumption the tool can differentiate between statuses specifically called Resolved and Closed. In practice, they could be called anything–Pending Closure, Completed, Awaiting Closure, etc. In practice I have seen these delays range from 1 business day (aggressive) to 5 business days (conservative). Some types of issues, such as requests to disable access, could be closed immediately.

There is another aspect to this. In an organization with little emphasis on SLAs, the incidents tend to stay open far too long. People want to be sure that the incident is really gone, before they close it. That results in many incidents which should have been closed days ago.

The answer is having clear statuses which differentiate between “resolved” and “closed”. The incident could be set to “resolved” status immediately following service restoration. Then, there should be a set period of time for the users to get back with complaints.

You are right, that should not be too long. It really depends on each organization. The ultimate goal is that we find the fine line between when the incident is the “old” one, or a “new” one. In some companies users are quick to respond, in others not so much.

On my ITSM Perfection blog, I talk about such topics as well.

Comments are closed.