How to ensure that incidents and service requests are closed quickly when there is no SLA

By ITIL® from Experience©

Without Service Level Agreements (SLAs) many incidents and service requests are not closed quickly because something with a higher priority comes along. Without a process to review the old ones, they can age until the client complains. However, prompt service is possible without SLAs.

Fast food restaurants deliver orders quickly without SLAs. Their processes are focused on that goal. Often, they measure the time it takes to complete each task. Or, at least management monitors "production" to ensure that the processes functions properly and that people meet the expected performance requirements. During busy times like at lunch or dinner it is common for Supervisors to help assemble orders that take longer than usual. This moves orders blocking the smooth execution of the process and it helps avoids bottle necks.

I.T. can do the same by focusing on the age of incidents and service requests.

The first step is for line managers to systematically review all open incidents and service requests starting with the oldest ones first. Three (3) questions should be asked for each one:

  1. What is the status?
  2. What is needed to move this forward?
  3. Who is taking the next action and do they need help to do it?

The purpose is not to review the history that caused the issue or to find a culprit. The goal is to determine actions required for resolution.

Depending on the organization and nature of calls1 , the review process can be done daily or weekly. Although the manager can go to each team member to review what’s assigned to them, our experience shows that a face-to-face or a virtual meeting is most effective.

A meeting brings accountability and peer pressure. Most people will review their incidents and service requests prior to the meeting to ensure they are prepared to answer the above questions. As a result, many people will take action to avoid being at the top of the list. However, the goal is not to review people's work and to chastise them for having something on the list! The goal is to find resolutions. A meeting also makes it effective for people to provide tips and suggestions to peers. At the same time caution must be used not to launch into a problem solving discussion during the meeting — an easy trap for technical staff and managers to fall into. If a brain storming or trouble shooting session would be helpful, the action is to schedule one.

A sophisticated ITSM tool is not required for this. A simple report of incidents and service requests sorted by date logged suffice. If the date logged/open is not available the ticket reference number can usually be used since most ITSM tools create them sequentially (i.e. smallest number was opened first).

It is important to realize that this review process is based on age, thus the oldest is looked at first regardless if it is an incident or service request. Although an incident is an interruption or degradation of service2 all incidents are not created equal3 . Moreover an incomplete service request will over time impact the business. In addition, this review process is done regardless of the incident or service requests priority4 . The goal is to review work that has been pushed aside due to other priorities and to bring it at the forefront of people’s attention and priorities.

In time, when the oldest incidents and service requests backlog is eliminated the meeting can evolve to proactively intervene to prevent them from getting old. The meeting's agenda can then be to review:

  • First, the ten (10) oldest.
  • Second, the ones which have been reopened (reopening usually indicates that the solution is more complex than anticipated or that I.T. did not understand the issue).
  • Thirdly, the ones which have been reassigned the most (frequent reassignment between teams or technicians often indicates a lack of understanding of the issue or a lack of ownership (see How can we tell that no one has taken ownership of an Incident before we get a complaint).
  • Finally, the ones with the most actions or work notes.

In all cases the same three questions are asked with the same relentless focus on making two decisions: 1) what needs to be done, 2) who is tasked for doing it and, 3) Do they need something to get it done.

On a final note, this meeting can be called a review of the “Work In Progress.” However, its acronym spells “WIP” which can be associated to reprimands and discipline. Thus, we prefer calling this meeting the “Aging Review Meeting (ARM).” Regardless of the name used for this meeting, like a "Stand-up Meeting"5 , what is most important is that management and people have the discipline to follow a process focused on monitoring the age of calls whether an SLA is in place or not.

Last updated on: 2015-10-28

"To set the right priority, ask yourself the question "if one had to go, which one would it be? Repeat until the last item." Unknown

More Quotes


More on Incident Management
More on Service Requests and Request Fulfillment

ITIL Process > Incident Management
ITIL Process > Request Fulfillment
ITIL Process > Service Level Management (SLM)

1 Call: (ITIL® Service Operation) A telephone call to the service desk from a user. A call could result in an incident or a service request being logged. Source: ITIL® glossary and abbreviations, 2011, http://www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx
2 Incident: (ITIL® Service Operation) An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident – for example, failure of one disk from a mirror set. Source: Ibid
3 Prioritization addresses these differences by evaluation impact and urgency.
4 Priority: (ITIL® Service Operation) (ITIL® Service Transition) A category used to identify the relative importance of an incident, problem or change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken. For example, the service level agreement may state that Priority 2 incidents must be resolved within 12 hours. Source: Ibid


Copyright 2014-215 - ITIL® from Experience - D.Matte