Using same Categories & Sub-categories for Incidents and Service Requests
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2019 11:40 AM
Ok, am I way out in left field here...?
Coming from other ITSM platforms, SN seems to have a different take on SR's vs Incidents. I understand the ITIL definition of both, but to the more I dig into SN, the more it seems like the SC is more about Items...not services. The documentation and videos I've read such as "ITSM Webinar: Service Catalog: How to quickly realize value" found here https://youtu.be/nWjcgsLl7tM seem to support this.
If anyone has any links or documentation to help me understand this I'd be grateful.
First Question:
How does an agent create a service request on behalf of a customer. Say a customer calls the service desk (lets face it, they do!) and requests a service. ie: create a new account, How does the SD agent create this? Do they go to the incident table and create a new incident (it's not an incident by ITIL definition)? Do they go to the service catalog and create a RITM on behalf of the customer...?
Second Question
ServiceNow recommends using the Service Desk Call plugin to track all incoming interactions with the service desk and then routing based upon "Call Type" but interesting is that they list Incident, Request, etc...in the pull-down. If you pick Request, it creates a RITM with a request Item. Let's say "Access", but can I create sub-categories of requests AND have those categories and sub-categories align with the incident table of Categories and Sub-Cats?
Other ITSM platforms might have a "Type" field that would differentiate between Incident, Request, etc.. ie: Here is one implementation of ServiceNow in which they use incidents for all and have designed their Category to be "Incident, Service Request or General Inquiry"
Then sub-category of say service disruption as the level of disruption and then using Configuration Item field to further define WHAT is being disrupted.
Real Question:
I guess there are many ways to implement this, but what is the best practice for creating a customer focused IT service catalog that uses the same categories and sub-categories as found in incidents?
Sorry this was a long message 🙂
Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2019 12:16 PM
Hi,
Yea...a bit all over in this post...but I think you're grabbing at different ways to implement this and not all work for you...or anyone else.
We personally do not use the Service Desk Call plugin that you mentioned. I've done 3 implementations and none of them have used this. It is nice, but I find that it's too generic and it's a bit immature to me...we empower our Service Desk to find out the issue and then work with the user over the phone, email, Skype to fill out the correct ticket (whether that's an Incident or a Request).
If the user calls in and is requesting a service (or a request basically) the technician will search for the respective catalog item and begin to work with the user to fill it out. On all catalog item we have a requested_for field that they would fill in on behalf of the user and then work their way through the form.
Our categories for both Incident and Request are MOSTLY...identical. I think we may have 1-2 more categories in our service catalog than we do in the Incident space, but yes, to create consistency, they are almost the same.
As far as breaking things down even further with sub-categories...we've been able to avoid this because our request items are very versatile...meaning...inside the request for the application itself...we then ask what the request type is...if it's an: inquiry, additional, removal, etc. This allows a more streamlined catalog item and creates more of a "one-stop shop" for end-users...otherwise...they start drilling down in to categories and subcategories and things can get messy.
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2019 12:24 PM
Hi Allen,
Yeah I was all over the place on that message (a brain dump that was interrupted multiple times).
I like the how you described your versatile request items. I'd like to learn more about your structure there if you don't mind sharing a bit of info (an example request form with the request type ...)
I'd also like to avoid drilling down into sub-categories and further...
Thanks for your quick reply!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2019 12:39 PM
Sure, also be sure to mark above post as Helpful if it was.
But currently....say we have a proprietary application...we have a catalog request for that application in the category: Applications...which is the same on incident. For incident, the subcategories would be stuff like: Bug/System Error, Data, Slow Performance, etc. But in the request side of things for that same application, obviously we won't have the same subcategories, but the main category of Applications is there...and we call out specific ones that should have a request for it. NOT software....we're talking specific business apps here...so then we met with the owners of the different applications to try and make their forms as identical as we could...but let them have "some" creative liberty in the "request type(s)" and "service" - so the services can be the various team names that are associated with this application. I'm in healthcare so we have services such as: Clinical Files, Eligibility, Encounter, etc. then they pick their request type and those choices would be stuff like: Analysis, Configuration, Maintenance, etc.
So that's what we did.
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!