Best approach to unstructured service requests

[magnushedlu]

Hi community,

So we are about to implement ServiceNow ITSM and got a question about how to best manage the need for registering ad-hoc or unstructured Service Requests. 

Use case 1: A user emails the system and a Universal Request is created. The 1st line support group concludes that this is a request for a service that is not matching a existing item in the catalog. What to do?

Use case 2: A service team is assigned an Incident from 1st line support. But when analyzing this they confirm it is not an Incident really but rather a request for service. The service is not defined as an item in the catalog. What to do?

My proposed way of managing this would be to have one or more items in the catalog that they can use to catch these undefined needs. Although I think it my users will be confused by the fact that the system will create one REQ, RITM and a SCTSK item when all they practically need is one task representing the need.

Any input from anyone on how this has been resolved? I assume that most organizations have similar use cases.

[Damhoej]

There is a well hidden tool in ServiceNow "Service Creator"

I would suggest you take a look at that. 

With this tool you create the service requests correctly and at the same time empower the user to adjust to their need.

https://docs.servicenow.com/bundle/washingtondc-application-development/page/build/service-creator/c...

[magnushedlu]

Interesting. Didn't know of this feature. This would basically be similar to creating a custom table and record producers from the catalog.

Not sure it will fit good with the use cases I had in mind but will try it out to see more. 

[Ralph Hand]

Users should not have to understand the difference between an incident and a request.   We are already asking a lot of them to look at the catalog and then log a ticket if something doesn't match.

Everything that does not have a defined catalog entry comes in as an incident in our design.   Service Desk or the receiving technical team classifies them as an incident or request and goes from there.

Ideally you would set up tasks on incidents to further facilitate this so people can add ad hoc tasks to these tickets.

Adding things to the catalog is fine if the volume dictates but having them search hundreds of low volume catalog items is just going to make your situation worse.

Analyse the types of issues you get in the incident module and then decide if it warrants an independent workflow/catalog item.

[magnushedlu]

Hi Ralph,

Thanks for the response. I completely agree with you about that requesters should not have to pick and we need to keep it simple for them. In our case we will be using universal request for all inbound interactions unless they use defined items in the catalog. 

The issue I have is for the IT users (fulfillers), not the requesters. For example, an application team would need an AD account to be set up by the AD team but the AD team do not have a catalog item set up to manage this specific request.