Tactical ITIL -- service, incidents, and problems

The world of ITIL separates help desk calls into two distinct types. There are "service tickets" and "incidents." These types are resolved differently.

If yours is like most organizations, there is a process in place that allows your users to communicate issues they might be having. This process generally involves calling into a phone number and telling the person on the other end about the situation. Hopefully, the caller provides a clear picture of the problem. More frequently, a tech will need to call the user back and elicit more information.

The world of ITIL separates these calls into two distinct types. There are "service tickets" and "incidents." These types are resolved differently.

A service ticket is straightforward. If a user needs a password reset, the call is classified as a service ticket. The user has called and requested something that can't be solved by changing a business process. Let's face it, as we evolve password requirements for length and complexity, our end users will be hard pressed to remember them. So a password reset, even though it's done many times in a metrics reporting cycle, is not an incident. The root cause can't be fixed without a project that would have impact on the enterprise as a whole.

That said, the metrics that result from the resolution of password reset tickets can be used as a driver for the implementation of a self-service password reset tool or deploying a password vault tool. The value of differentiating between service and incident becomes apparent when considering strategic deployments.

What makes a call an incident? An incident is something that happens because of an incorrect action that can be traced to a root cause that can be fixed. The service desk takes five or 10 calls because people can't reach the server. The ticket goes to the server team who discovers that the server has been unplugged. The root cause of the problem is not that the server has gone down. The root cause is that the unit was unplugged. IT brings the server back on line, resolving the symptom. Then they tag the electrical cord in a way that indicates that the server must not be unplugged from wall power.

In that example, resolution of the root cause not only brings the server back online, it also resolves the reason the server went down.

These two examples are extremely simplistic but serve to differentiate whether the call that just landed in your queue should be qualified as a service ticket or an incident. Knowing the difference is part of how you make your ticketing system work better for you. By analysis of your metrics, you will know the kinds of calls you're are most likely to get, what the frequency is, and what solutions work and don't work. In the unplugged server scenario, calls to the service desk telling you that the server is down again may cause you to consider if the cord is being a trip hazard. It also may lead you to question the cleaning staff. Either way, it will lead to a solution that is durable.

Incidents are an element of problem management, which is literally the task of resolving the underlying root cause of an incident, thus preventing the problem from reoccurring.