IT Service Management
Showing results for 
Search instead for 
Do you mean 

Confused by request management vs. incident management? Don’t be!

‎04-11-2014 02:06 PM - edited ‎04-15-2014 03:06 PM

Guest post by Pete Budic, HP R&D Functional Architect



In planning your IT Service Management (ITSM) solution, it is important to understand the differences between Service Request Management and Incident Management, as well as the types of processes served by each discipline. I know that users are often confused by these two types of management, so I want to clearly describe their differences to you.


The overall goal of ITSM is to provide a business service that provides meaningful value to the users of that service.  It is important not only to define the service itself, but also several important sub-processes that the consumers have access to such as:


  • How can someone become a user of the service?
  • How can someone stop being a user of the service?
  • How can someone ask questions about the usage of the service?
  • How can someone make a complaint about the service?
  • How can someone get help on an issue they are having with the service?
  • How can someone request a modification to how they are using/receiving the service?
  • How can someone can make a suggestion on how to improve the service?


All of the above are part of the overall service definition.  The IT department expects the service consumers to use these processes as part of the day-to-day operation and consumption of the service.


From these questions we can derive the high level definition of the Service Request Management process. 


 Service Request Management encompasses the consumer-facing processes that make up the expected, day to day activities involved in providing a service to an individual or group.


These activities can be defined at a high level as either Service Requests or Support Requests. 

Service Requests are the set of pre-defined activities that can be performed against the service itself (such as increasing the size of a standard email mailbox, requesting additional memory for a virtual machine, or resetting a password for a specific application).  Service Requests will usually require the same type of information from the user each time (such as a user id or application name), and often lend themselves to automation.


Support Requests, on the other hand, encompass those requests that have not been pre-defined or even expected by the service owner.  This can include questions, suggestions or even complaints.  For many of these, a good Knowledge Base will allow a consumer to find answers on their own to their questions.  This removes the need for a service desk agent to manually respond to the request. 


However, many times a support request involves a perceived issue that a user is having with the service.  Here we start to see some confusion over whether the issue should be processed by the Service Request or Incident Management department.  To clearly see where the issue belongs, we can compare the definition we have above with our definition of Incident Management:


Incident Management encompasses the processes used by the service provider to track and resolve any issue that impacts the ability of a user to consume the service.



It is important to note that an issue that impacts the operation of a service may or may not be reported by a service consumer.  For most hardware or application issues, the incident will most likely be created directly by the service provider either manually or by some type of event management software.  However, for those Incidents that were either reported by a service consumer, or for those that affected a consumer that then reported it via a Service Request, both processes (IM and SRM) will need to be followed.  To understand this we need to look at the end goal of each process.


The goal of Service Request Management is to ensure that the user can consume the service to their satisfaction.


The goal of Incident Management is to restore normal operation of a service as quickly as possible.


The line between the two processes becomes more clearly defined at this point.  Using these definitions, one of the easiest ways to help determine if an issue needs to be handled by Incident Management is simply to determine whether or not the issue could affect the availability of the service as defined in any Service Level Agreements.  While this is not the only determination that we might use, if the answer to this question is "yes" then the issue in question needs to be handled within Incident Management.


Here are some examples that might be encountered, and which processes should be followed for each:





A   user has forgotten their password for their email system

SRM   (Service Request)

A   good candidate to automate

A   user cannot connect to an application.    Investigation by the agent determines that the issue is caused by an   improper proxy definition on the user's machine.

SRM   (Support Request)

The   issue is not caused by the service provider

Event   Management detects that one of the servers in an application has   crashed.  Redundant systems keep the   application online, but users are taking longer than normal to login.

Incident   Management

While   the service is still available, there is an impact on the ability to provide   it

A   user calls in reporting that they are taking a long time to log into the   application.

SRM   (Support Request) - with link to IM

The   Service Request Management process will be used to handle the consumer.  They may want to be notified when the issue   has been corrected, or may simply be satisfied by the explanation.  The Service Request is linked to the   Incident to facilitate either.


In each case we can use the definitions that we derived earlier to determine the correct process:

  • Service Request Management encompasses the consumer facing processes that make up the expected, day to day activities involved in providing a service to an individual or group. The goal of Service Request Management is to ensure that the user can consume the service to their satisfaction.
  • Incident Management encompasses the processes used by the service provider to track and resolve any issue that impacts the ability of a user to consume the service.  The goal of Incident Management is to restore normal operation of a service as quickly as possible.


Applying these definitions to any incoming issue should make it apparent which ITSM process needs to be followed to ensure that the service is being provided in the most efficient way possible.


Are you are looking to improve your processes like incident and request management as part of a technology refresh?  Consider an HP Service Desk solution as both our options include out of the box best practices that can make your journey easy.  For a SaaS solution read about HP Service Anywhere and also test drive a free 30 day trial. Just register, and your credentials will come to your email in minutes. Looking for an on premise solution?  Read more about HP Service Manager Subscription. If you have any further questions, feel free to reach out to me the comments section below.


About the Author


This account is for guest bloggers. The blog post will identify the blogger.

Hee Kiang
on ‎04-15-2014 02:26 AM

hi Pete,


I like your explanation and clear positioning on SRM, and using this process to distinguish between Service Provider's triggered issues as opposed to Customer's triggered issues.


I like to also hear your thoughts on the following scenario


The helpdesk may have attempted to resolve a email-related problem and applying a workaround that does not work for the customer. The customer does not accept the solution and asked for more help and escalation.


This issue may be beyond helpdesk's technical capabilities.


So technically in ITIL, this would require a functional escalation.


Now that the issue has not be confirmed a Service Provider's issue yet, it could still be related to some settings in the customer's PC. Would you recommend that the Ticket be escalated within the SRM process or be escalated to the Incident Management Process?



Hee Kiang

on ‎04-23-2014 02:24 PM

At this point, the question of whether or not the issue should remain in the SRM process is going to be guided by any agreements the Service Provider has with the customer.  If there is any agreement with the customer that the Provider is responsible for ensuring the service works on their PC, then this can be seen as a degradation of a provided service and should be escalated to Incident Management.


In your example, I would imagine that this would most likely not be the case and the issue in question would not be counting against the customer's SLAs. So the escalation would take place inside of the Service Request process. 



on ‎05-02-2016 02:57 AM

This post was very well-written and right on target. But the distinction between the two distinct processes has been obliterated in two of the most prominent ITSM tools on the market today: Remedy and ServiceNow. Thus we have the necessity of posts like this to clarify something that was not confusing until recently.

I believe that the confusion began in 2005 with the release of the ISO/IEC 20000 "Code of Practice" which purported to provide guidance for organizations in achieving ITIL compliance. It actually did so, to an extent, in spite of numerous objections to some vagueries contained therein (such as extensively using the term "event" without defining it). But the real can of worms was opened by its definition of the objective of Incident Management: "To restore agreed service to the business as soon as possible or to respond to service requests."

The first phrase in this definition is straight out of ITIL, but the second appears out of nowhere, and has nothing to do with Incident Management. As IT professionals and ITSM tool-developers began to incorporate this skewed definition, the British Office of Government Commerce (OGC) responded to the newly-sowed confusion with the release of ITIL version 3 two years later. This release clearly spelled out the difference between Incident Management and Service Request Management, which had not been necessary in prior releases, as no one had been conflating Service Desk functions with the technology-centric process of Incident Management.

The confusion persists, however, because some major tools have gone down that path and it would be too disruptive for them to return to best practices. Many in the sales forces of these organizations seem have no memory of a time when these processes were separate - and the certification organization Pink Elephant gladly certifies organizations and tools that have taken this wrong turn.

I now wonder if this particular ship will ever be righted.

Tanmoy Bhattacharya
on ‎05-25-2016 09:58 AM

I am not concluding but reaching a point that user can always raise a Service Request which Servicedesk will decide and put in proper category.

Normally Service Request(SR) invloved with IMAC process and there is no business impact but in case of Inciednt Mgmt interruption of service is there as well "Workaround".

SLA for SR and IM is different and very critical for IM.  IM is closely related with Problem Mgmt and before PM it should be a major incident.

Please correct me if I am wrong.




Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all