In ITIL v2, Incident Management became a recognized process. (Whether or not this is a correct use of the word “process” is a discussion for another day). Mentioned in passing was the possibility of a call being a Service Request rather than an Incident, at which point the process branched to … nothing. The Service Request branch hung into space, dangling wires and reinforcing steel into the void. Service Request process was never defined.

What came first was never defined either. When someone calls, is the call an Incident until proven to be a Service Request? Or is it a Request until it reveals itself to be an Incident? Or is it something else until it yields to classification? As far as I know, this was left to the implementers (or software vendors) to decide.

Now ITIL v3 elevates the Service Request to equal billing with the Incident. In fact, if importance can be measured by number of pages then Service Requests get slightly more of the “Peas Book” (Service Transition) than Incidents do.

This is a great step forward but I believe it is not the final word. ITIL v3 still delineates between Incident and not-Incident as the two categories. That is, Service Requests are some kind of miscellaneous category for everything that is not actually an unexpected interruption to service. The two processes are quite separate. This does not fit well with my experience of reality. Admittedly my reality has a few kinks, but in this case I speak on behalf of clients who feel the same way. For many service desks, Incidents are not the main part of their function.

ITIL v4 will, most likely, I predict, finally recognise that the Service Desk deals with generic Requests/Tickets/Issues/Incoming. These Requests have multiple categories. Each category has its own variant of a more general process that applies to all of them, in much the same way as there are several categories of Change which all undergo variants of the general Change process.

The categories of request may include some or all of:

Once we come to see an Incident as just one category of a more general Request, then the service desk’s request management process will make more sense and map better to reality. (Certainly Incidents will have their own variant of the process with specialist activities such as Incident Matching).

SLAs will define responsiveness in terms of the categories of Request. (I think restoration of service should be defined as part of the Availability Service Level Objective, not the Responsiveness SLO). Management of Incidents (the restoration of service, incident matching) may still fall to a specialist Incident Manager, or it might be part of the role of the Request Manager.

Incidentally (no pun intended], I still encounter examples of SLA objectives for restoration of service. Outages will be prioritized based on their severity, but they will be restored as soon as they can be restored and no sooner. “Priority 1 incidents must be resolved within one hour” is like saying “Fires must be extinguished within three minutes” or “Missing climbers must be found within an hour”. We’ll find them when we find them. It makes sense to define responsiveness by severity/priority/impact, but not restoration.

From a narrow focus on restoration of service, the understanding of the service desk has grown with each revision of ITIL, and with it the importance of Request. Extrapolating the trend suggests that next time ITIL is revised Request will truly have its day.