Looking at deploying ServiceNow’s Service Request Catalog but looking at an enhanced user interaction without necessarily deploying the Content Management application (CMS)?

OR

Migrating from another ITSM system where you are using a very complex Service Request Catalog structure?

OR

Is your current deployment of ServiceNow’s Service Request Catalog more Item Driven (where you have literally hundreds of items and you can’t see the woods from the trees)?

If you answered yes to any of the questions above, then this article can hopefully show you another approach worth considering. Watch the video first before you continue.
 

The Challenge

Many of us prefer to use (at least initially) the out-of-the-box ServiceNow Service Request Catalog look and feel without going to the extent of deploying the Content Management application. This may present certain challenges especially when we start enabling over 100+ catalogue items. For example, in the screenshot shown below, it’s the out-of-the-box catalog  and most items shown assume that it’s a request for a “New” item/service.

IT organisations have a tendency to define their Service Request Catalog (regardless of solution) from an “inside out” perspective. This perspective results in an Item Driven Service Request Catalog. What we mean by Item Driven is that there is a Request Item in the catalog for each action possible within a Service Offering. To simplify this point, refer to the screenshot below. Here you can see a “Desktop Management – Standard” category with four Request Items. This shows one Request Item for each action, Decommission, Move, New and Replacement.

As organisation’s progress with the rollout of their Service Request Catalog, we find that their users/customers start to complain of the catalog’s ineffectiveness to meet their needs. Submitting a request has become a tedious and confusing process. Users browse various forms and perform numerous clicks to submit a request. In addition, the administration overhead of your ServiceNow platform has increased due to the high number of Request Items that exist in your catalog.

The Approach

The objective is to simplify the Service Request Catalog structure from an end user experience but still allow the flexibility required to drive efficiencies in delivering the services shown in the Service Request Catalog. The solution must considerably reduce the number of Categories and Request Items from an administration overhead perspective.

Let’s take the example discussed above with “Desktop Management – Item Driven” category. Four distinct Request Items were created:

• Decomission
• Move
• New
• Replacement 

With the objective in mind, we could create a single Request Item called Desktop PC and incorporate what we refer to as Action Driven. Refer to the screenshot below.

By selecting a required Action (as per screenshot below), the system then asks the user/customer the required information needed to complete the request.

As the user/customer select the required Action, it would be ideal to also prompt the Service Levels associated to it to ensure we manage their expectations. Please refer to the video shown above to get an in-depth preview of this functionality.

The Solution

In summary, a Client Script is included into the ‘Desktop PC’ Request Item to hide /display fields based on the Action selected. This would prompt the user/customer to only provide information that is relevant for the particular Action selected.

A new table was created in the schema to associate each service with an SLA band. This table is then queried to display the approximate delivery time on the catalog form for the service selected. Here is a sample screenshot of this extended table.

The ‘catalog_item’ UI macro was modified to query the above table and fetch the correct SLA band to be displayed on item form.

The UI page com.glideapp.servicecatalog_cat_item_view was then modified and the following code was included in the Script section to display the actual SLA band for the service selected.

Below is a sample workflow of how Action Driven Service Request Items can be managed using a Workflow. The key is to utilise a “switch” to route to the required step within the workflow.

The above is just a subset of the key configuration elements required to enable your ServiceNow platform to become an Action Driven Service Request Catalog.

The Benefits

As you can see, this approach helps reduce the number of Request Categories and Request Items down to a manageable level whilst enhancing the end user experience, improving administration overhead and driving overall service efficiency.

It can transform the Service Request Catalog to take a more “outside in” perspective which is more beneficial overall to the organisation. Though, this isn’t the only aspect one must consider to ensure that the end user/customer is kept in mind at all times. But you are at least one step closer!