OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Service Catalog Design for Clearer Requests

ServiceNow service catalog design should help a person recognise the service they need, provide information that the fulfilment team can use, and understand what happens after submission. A catalogue is not improved by adding more items if the names, questions, ownership, and outcomes remain unclear.

For service-catalogue owners designing a clearer route for employee and IT requests..

ServiceNow service catalog designservice catalogue itemsrequest forms
Discuss this ServiceNow topic

Guide map

Turn catalogue reviews into a repeatable routine.

Start with tasks users recognise

Start with the tasks people actually request, not the internal team names that handle them.

Give each catalogue item a clear promise

Each item's description should state what can be requested and what the requester receives.

Keep questions connected to fulfilment

Every question should either affect routing, approval or fulfilment, or be removed.

The practical framework

Design a clearer ServiceNow service catalog by organising real tasks, useful questions, ownership, approvals, fulfilment, knowledge, and closure.

The best first review is usually a task review. What are people trying to get done, and where does the current request path create uncertainty?

Start with tasks users recognise

Employees may want access, equipment, a change, a report, or help with a service. They may not know the internal team name, application owner, or technical category. Catalogue structure should reflect the task while preserving internal routing behind the experience.

Use words people already use when asking for help. If two items appear similar, explain the difference before the requester selects one. A short, specific description is more useful than a broad promise that covers every possible exception.

Give each catalogue item a clear promise

An item should explain what can be requested, who it is for, what information is needed, and what the requester will receive. The outcome should be honest. Do not promise a result the fulfilment process cannot consistently provide.

The ServiceNow consulting service is the relevant internal route when catalogue language, service boundaries, and ownership need to be designed together.

Keep questions connected to fulfilment

Ask for information that affects eligibility, approval, routing, fulfilment, security, communication, or reporting. Conditional questions can keep the first view simple while gathering detail only when it becomes relevant.

Review every field with the person who fulfils the work. If the answer is not used, it may create friction without improving the outcome. If the fulfilment team needs a value the form does not request, the request may return for clarification.

Build ownership into the catalogue

Each item needs a process owner, fulfilment owner, approval rule, knowledge owner, and review point. One team may hold several roles, but the responsibilities should still be visible.

Define what happens when the item no longer fits, the owner changes, an approval is delayed, or a request becomes an incident. The ServiceNow implementation service provides the appropriate route when catalogue decisions move into controlled delivery.

Review items through request evidence

Look at abandoned requests, repeated searches, reassignments, returned forms, cancellations, and reopened work. Each pattern can indicate a different problem: confusing language, too many questions, missing ownership, an incorrect approval, or a fulfilment result that does not match the item’s promise.

Use the evidence to improve the item itself. Creating a second similar item may hide the original problem and make the catalogue harder to navigate.

Common questions

Questions teams ask about catalogue design

How many fields should an item have?

Only as many as the workflow can use. A field should affect a real decision, action, control, communication, or report. Remove fields that only transfer uncertainty to the requester.

Who should own a catalogue item?

The process owner should be accountable for the promise and operating meaning. A fulfilment team can own delivery, while a platform team maintains the configuration.

The research-grounded boundary

Flow Designer and App Engine matter here because catalogue items often trigger workflows and custom applications. The practical rule is disciplined scope: keep a reusable workflow or bounded customisation separate from the surrounding process, state who can change it, and record the evidence that supports the next decision. Configuration detail should stay subordinate to the service decision and the record needed to defend it.

Deciding what belongs in the catalog and what does not

A catalog fills up quickly when every team asks for an item of its own. Over time the list holds several entries for the same thing, each written in the language of the team that requested it, and employees cannot tell which one to choose. Catalog design begins by deciding what the catalog is for. It is a menu of requestable services with a defined outcome. Knowledge that explains a process, a status page for work in progress and a channel for reporting faults each belong somewhere else, and placing them in the catalog makes the menu harder to read.

A rough sorting test helps. If a person would ask for the thing and expect a defined result, it is a catalog candidate. If they would ask how something works, it is a knowledge candidate. If they would report that something is broken, it is an incident route. Applying the test to the existing list can remove a surprising share of the entries.

Naming and grouping that a requester recognizes

Categories should follow the vocabulary of the people who make requests, not the org chart of the teams that fulfill them. The table compares two approaches to the same set of requests.

Request as the team names itRequest as the requester names itLikely result if left as is
Provisioning of end-user computing assetsGet a new laptop or replace a broken oneRequesters browse the wrong category and open a generic ticket instead
Identity and access management changeGet access to a shared folder or applicationRequests split between two items, with the same approver and different forms
Facilities moves and adjustmentsMove my desk or change my roomA search for the everyday phrase returns nothing useful

Keep the names in plain language, avoid internal codes in titles, and let the search terms carry the technical synonyms. If two items would be confused by a requester, the description should state the difference in the first line, before the form opens.

A review routine for each catalog item

Every item should be reviewed against the same short set of questions before it is published and again at a fixed interval. The sequence below is one way to run that review, and it can be applied to items already live.

  1. Confirm the outcome the item promises in one sentence, and check that the fulfilment team can deliver it consistently.
  2. Confirm the process owner, the fulfilment owner, the approval rule and the knowledge article that explains the item.
  3. Check each variable against the fulfilment step it affects, and remove or condition any that do not.
  4. Check whether a similar item exists that a requester could choose by mistake, and merge or differentiate them.
  5. Check the last set of requests for the item, including returned, cancelled and reopened ones, and note the patterns.
  6. Record the decision to keep, change, merge or retire the item, with the reason and the date of the next review.

Retiring an item without breaking the work behind it

Items are retired less often than they are created, and the reason is usually that nobody is sure what depends on them. Before retiring an item, check open requests, scheduled tasks, automations, virtual agent topics and any links from knowledge articles or the portal. Redirect the requester to the replacement item and keep the retired item hidden rather than deleted, so the history stays readable.

Variables that make the item hard to finish

Variables are where catalog items accumulate weight. A variable added to answer a single exception case appears on every request, and a field that is mandatory for one route becomes a barrier for everyone else. Conditional visibility helps, but it does not remove the cost of a question the requester cannot answer. Review variables for the requests that were returned for clarification, since those show which questions confused people most. A question that is frequently misunderstood is usually worth rewording or removing, rather than adding a help text that nobody reads.

Signs that the catalog is getting easier to use

Search that returns the right item on the first attempt, a falling share of generic tickets raised because the catalog seemed to have no match, and fewer items that are cancelled after the requester reads the description are all useful signals. The number of items should not be the measure. A catalog with fewer, clearer items often performs better than one that has grown to cover every variation, and a shrinking list after a review is a sign the review is doing its job.

When a redesign is not the first fix

If the fulfilment process is slow, misrouted or unclear about who does what, redesigning the catalog will make the requests look better without changing their outcome. Repair the fulfilment process first, then reflect it accurately in the catalog. Similarly, if the platform configuration is not stable, a new layout of items can add to the problems people already have with navigation. In those cases the catalog review should be scheduled after the process and configuration issues are under control.

Questions about service catalog design

Should every team have its own catalog section?

Not usually. Sections organized by team tell requesters who does the work, which they rarely need to know. Organizing by what people want to get done tends to produce a shorter, more consistent menu, with the team ownership visible on each item.

How should the catalog handle a request that spans two teams?

Make one item the front door with a clear owner, and let that owner’s process create tasks for the other team. Two separate items that the requester must assemble themselves produce the most confusion.

Who should be allowed to publish a new item?

A person who holds the process owner role and has reviewed the outcome, the approval and the knowledge article. Publishing rights held by a platform team alone tend to produce items that the fulfilment team cannot deliver as described.

What is the best way to test a new item before release?

Ask three people who were not involved in building it to request it in their own words, with no briefing, and record where they hesitate. Their hesitation points are more reliable than a checklist.

Next step

When items, owners and approvals need reviewing together, the change request and service catalog management page covers helping a person recognize the service or change they need and understand what happens after submission. The service portal navigation post covers how navigation helps a person find the right route, and contacting OBLYTECH is the way to discuss your own catalog.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading