Incidents vs. Service Requests

Document created by Sarah Nielsen Employee on Oct 4, 2017Last modified by Sarah Nielsen Employee on Oct 6, 2017
Version 3Show Document
  • View in full screen mode

Jolan'tru (Hello and Welcome)


One of the most common questions that I receive during implementation is, “What is the difference between an Incident and a Service Request?” While most people are familiar with Incidents, they may not understand the realm of the Service Catalog. If the Service Catalog has you exploring a strange new world, we’re here to help you seek out new features! While we’re at it, we’ll clarify the difference between your traditional Incident and a Service Request.


Picking Your Evasive Maneuver (Incidents vs. Service Requests)


First off, let’s quickly tackle the Incident or Service Request debate. They need me back on the bridge for an implementation sometime soon.


Most everyone is probably familiar with your traditional Incident. At Samanage, we like to define an Incident as something that is a break/fix issue that needs to be resolved. This might be something that is not working properly or could be broken. For example, this would include a broken printer, an application that will not load properly or even a warp core breach. Can we get someone to engineering, immediately? We need warp engines by the end of the day.


Now, a Service Request is a request for a pre-approved service that your organization can offer to its end users. You have the option to build Service Catalog items which can include variable information that can be collected from your end user as well as a “behind the scenes” process that includes tasks and approvals that will be sent off to certain groups within your organization. The Service Catalog can be used to build out request forms for employee onboarding and offboarding, various equipment or an office move. You may even find your end users requesting shore leave through the Service Catalog. The Service Catalog will save you time with upfront data collection and automatic tasks or approvals.


Making It So (Helping Your End Users)


Now that you have a grasp on the difference between an Incident and a Service Request, let’s help your requesters boldly go where no requester has gone before. Many end users are probably used to emailing the help desk for assistance. However, now that you’ve introduced the Service Portal to your organization you may have requesters asking about how to properly use the Service Portal. Most likely, you’re getting questions about when to submit an Incident or a Service Request. If you haven’t already sent them the The Guide to the Service Portal, these talking points will assist you with these types of questions.  


Once you have built out your Service Catalog, it should act as your first line of defense on your Service Portal. You should let your end users know that this is their go-to location when they need help with something. The Service Catalog will provide them with a collection of approved services that your organization can provide for them. Whether they are looking for a new hire form or a place to request a new laptop, this should be their starting place. Encourage them to make the Service Catalog menu their first choice when looking for help or requesting a service from your organization.


It might also be helpful to let them know that filling out a Service Catalog Request will prevent some “back and forth” communication resulting in faster delivery times. Gathering variable information upfront will allow your team to get to work on the request faster and more efficiently. You know, because what if your communicators dysfunction or go out of range?


If your end user cannot find what they are looking for within the Service Catalog, they can log an Incident to request help from your organization. An Incident should be submitted whenever they cannot find a Service Catalog item available that pertains to their request. Another great reason for submitting an Incident would be a break/fix issue. Once again, this would be something that is broken and needs to be fixed.


It may take a few minutes longer to submit a Service Request rather than an Incident, but the efficiency of a Service Request will always remain supreme. Encourage your end users to submit a Service Request through the Service Portal when available to save you both time! Remember, you can always remind them that resistance is futile.


See you on the bridge!


P.S. If you are looking for additional help creating Service Catalog items, have Scotty beam you over here..


3 people found this helpful