Best practices for handling requests/incidents/service catalog?

[JennyHu]

Need advice with handling requests/incidents/service catalog...

Traditionally, our users would email, call, or visit us in person for any requests/questions they have.   We have implemented ServiceNow so that users are encouraged to submit a ticket via the portal.   What we find is that half of our users simply click on a general "Get Help" link on the portal rather browsing through our Service Catalog and fill in the proper request form.   This means that our Service Desk is tasked with classifying the request/incident/question and having to route it to the right group.   We are currently faced with the following problems:

1. Some users do not use the proper request form but use general "Get Help" record producer, so a request came in as an Incident.   The Incident needs to be cancelled and re-created as a Request.   The user got an email saying that their request is cancelled, and got another email saying that their request has been created.   How shall we solve this problem?   Design a better portal to encourage users to use the proper form?
2. For simple request such as "IP reservation" that has no approval workflow and has a single task, it's currently set up as a catalog item/request.   The hierarchy of Request -> Request Item -> Catalog Task seems to provide little value.   The tech has to go into the catalog task to mark his work notes, and go back to the Request Item to send a note to the client.   To make it simpler for our techs, would it be best practice to use a record producer to the Incident (or another custom) table rather than catalog item/request to manage simple requests that don't have multiple tasks?

On Helsinki, the OOB ServiceNow service portal seems to have simple request such as "Password Reset" and "Ask a Question" created as an incident.   According to ITIL, would it be better to separate the management of "Incidents" vs "Requests"?   If incidents and requests are all in the same Incident table, wouldn't that cause problems down the road as incident and request may have their unique and specific attributes?  

Thanks,

Jenny

[Aka Guglielmo]

Let me say... It depends.
You define the processes, you define the requirements.
When processes are well defined and shared accross all the stakeholders, then you can design your catalog.
Btw, in order to answer to your questions:
- catalog items are used to create requested items. A requested item is a child of a request. A request is the "bafkoffice" part of a catalog cart. Under a RITM you can define one or more task in order to fulfil the request. You can define approval and fulfilment worklows at every level (request, reqitem and task). Use item when you are delivering a catalog of Services.
- record producers are used to create records and run custom scripts. Use them when you want to give a way to submit something that is not a request. Usually Incident and Idea.

Moreover remember that there is not only a way to implement what do you need. Try and try and try on your developer instance till you find the solution that fits.

Hth,

[jaloia]

Hi Jenny,

It's good practice to design your self-service portal experience with the end goal of accelerating the time to resolution and/or delivery of your most common interactions between requestors and fulfillers.

So start by looking at your history of interactions between requestors and fulfillers in your organization.   Are they most often there to make requests, report incidents - at what frequency do these interactions occur, and which of these interactions is in most need of improvement.

This exercise usually results in some pretty clear - and prioritized - goals for your self service portal page.   You can then plan out which interactions you want to call out with discrete inputs (record producers, for example) and funnel through specific workflows that are designed to optimize time to resolution/delivery.

You don't want create a massive list of inputs for every possible incident type or request; but promoting specialized inputs for your few most common interactions between requestors and fulfillers is a great way to prevent the misuse of the generic Get Help "catch-all".

[JennyHu]

Thanks Jason! This is a great answer.