The 3 strike rule on ITSM and incident management (2024)

In a nutshell, the 3 strike rule is a policy, guideline, or simple behavior expectations that can be introduced as part of incident management process to help to reach closure of incidents when the user is not coming back to us.

ITIL recommends that: “The user or business agreed that the incident has been resolved and that normal state operations have been restored”. Now, that might become an issue if users are unresponsive.

As we commented on my previous article, once a technical fix is provided, the desired action to take is to resolve the incident. User can always reopen that incident. So that leaves the scenario in which we need more information from the user to continue investigation, but we are not able to get an answer back.

The rule typically involves a sequence of escalating communications, each with increasing levels of urgency, to attempt to resolve the incident with the user. The first strike might be a gentle reminder, followed by a second strike with a more urgent tone, and a final third strike with a clear warning that further inaction could result in the incident being closed without resolution.

There are some benefits of implementing a three strike rule, which include:

1. Improved incident resolution time: By setting clear expectations and guidelines for user response, incidents can be resolved more quickly, leading to improved service levels and a better overall user experience.
2. Increased accountability: Aids in guaranteeing that users are accountable for their involvement in the incident management process, thereby improving communication and cooperation overall. This rule provides a structured framework for user participation and accountability, ultimately promoting greater adherence to incident management protocols and a heightened sense of ownership in the resolution process.
3. Consistent approach: The establishment of a standard procedure for dealing with unresponsive users ensures uniform and equitable handling of incidents, irrespective of their individual circ*mstances. A standard protocol fosters consistency and fairness, providing a structured framework for incident management that ensures prompt and efficient resolution of issues. This consistency in approach also helps to establish trust and confidence among users, as they know that incidents are being handled in a consistent, standardized manner.
4. Reduced workload for incident management staff: By establishing clear guidelines for user engagement, incident management staff can spend less time chasing unresponsive users, and more time on resolving the underlying issues.

Essentially, IT will attempt to contact the user 3 different times using at least two methods of communication on different days. If an answer is not obtained within a reasonable timeframe, IT will resolve the service request/incident.

Questions to make yourself

• Which is the timeframe enabled from strike to strike.
  Some might consider that 24h as standard, but depending on the maturity of your users and the organization, and the relation between ITSM processes and business stakeholders, some organizations might consider it too tight and decide to go for 48h. Higher timeframe seems inefficient for the purpose itself.
• How to use your ITSM to assist and automatize the process.
  - You might want to enable a “follow-up date” field when the incident is on hold awaiting caller, so that the support agent can track when chase the answer. You might add an email to be sent to the support agent who has the tickets assigned.
  - You might instead have an email sent to the user if the incident is on hold awaiting caller and the incident has not been updated on the last “n” hours.
  It depends on how much you believe the impact might be on the users, if those are in the process of engaging and accepting your ITSM you do not want them to get flooded with emails.
  In any case, tools like ServiceNow can be enabled to automatize the task via flow like the one below, that will send an email every 24 hours until the updated by is set to the caller.

You could also schedule jobs for the purpose.

• How to measure effectiveness and side effects

It is important to be able to justify and show the improvements of any action that modifies the process, and particularly those which have direct interaction with the business and end users.

For that, I would recommend establishing a couple of controls:

1- Measure the average resolution time of your incidents for a relevant time frame (for example, weekly). It should be consistently lower.

2- Measure the number of reopened incidents for that timeframe. A slight increase might be tolerated, but if the increase is dramatic, those reopened incidents should be reviewed to understand the reasons behind and the policy should be iterated.

Last but not least:

• Try to use at least two different communication channels. User might not be getting notifications from the ITSM tool, try to contact them via organization’s messenger or even call them by phone.
• Leave the incident in a state in which the SLA is not in progress, since incident property is on user’s side.
• Add extra value by establishing a metric that will measure the amount of 3-strike rule applied. There are various ways depending on your ITSM o on how your ITSM tool is configured. As an example, add a “close code” = “no response” (or similar) for the purpose.
• Don’t forget to promote visibility and communicate this policy to your stakeholders and users, including it in your incident handbook as a standard.

Incidents should not be left open ad eternum. The 3-strike-rule ensures that incidents belonging to unresponsive users are handled consistently and fairly.

Overall, implementing a three strike rule can help to streamline incident management processes, improve user engagement and accountability, and lead to more efficient and effective IT service management practices.