ServiceNow Service Catalog Consulting

Service catalog consulting decides what belongs in the catalog before anything is arranged, and how finely items should be split. This page covers the current-state assessment, taxonomy and organisation, request intake design, self-service automation, routing and prioritisation, knowledge, governance, performance, analytics, three granularity models for splitting items, a review sequence for existing items, the design mistakes that make a catalog harder to use, and when a consulting review should wait.

Current State Assessment

We start by understanding your current request management. Do you have a service catalog? Is it used or do users still email requests? What requests do you get most frequently? What requests cause confusion or rework? We audit your actual request volume and types, not what you think you are being asked for.

Service Taxonomy and Organization

Organizing services logically is harder than it seems. Should services be organized by team (IT, HR, Facilities)? By type (software, hardware, access)? By business function (finance, marketing, operations)? The answer depends on your organization. We help you design a taxonomy that matches how users think about services, not how IT is organized. Users think “I need VPN access,” not “I need a request routed to the Network Security team.”

Request Intake Design

A service catalog item should collect the information needed to fulfill the request, no more. Too many questions and users do not complete the request. Too few and fulfillment teams do not have the information they need. We help you find the balance: required questions that are actually needed, optional questions for edge cases, and conditional questions (ask based on previous answers).

Self-Service Automation

Not all requests need human fulfillment. Common requests like password resets, license keys, software downloads, or access provisioning can often be fully automated or semi-automated. We help you identify which requests can be automated and build the automation: integrations with identity management, software distribution systems, or knowledge bases so users get instant service without waiting for humans.

Request Routing and Prioritization

Requests must route to the right team. A network request should not go to the database team. We help you build routing logic based on category, business unit, or customer type so requests reach the right place quickly. We also help you prioritize: urgent requests from executives might route differently than routine requests.

Knowledge and Self-Service

Many requests could be avoided if users knew how to do something themselves. We help you build knowledge articles for common requests: how to reset your password, how to install software, how to request a laptop, etc. If users find an article that answers their question, they self-serve and do not create a request. This reduces both request volume and user effort.

Service Catalog Governance

Service catalogs grow organically and become unmaintained. New services are added without removing old ones. Prices become outdated. Descriptions are vague. We help you establish governance: who owns the catalog, how often is it reviewed, what is the process for adding or retiring services, and how is user feedback incorporated?

Performance Optimization

We measure catalog performance: how many requests come in, how are they categorized, how many go to each fulfillment team, what is the fulfillment time, how satisfied are users? We identify bottlenecks: requests that are frequently miscategorized, requests that take too long to fulfill, services that are requested often but should be self-service.

Common Catalog Improvements

Many organizations improve fulfillment time significantly by automating routine requests and reducing information collection. Consolidating similar services (multiple laptop request types into one) reduces confusion. Adding knowledge articles for common questions prevents requests from being created. Clear service descriptions help users find what they need.

Catalog Analytics and ROI

A mature service catalog provides analytics: which services are requested most frequently, which are never requested, which take longest to fulfill. We help you use this data to improve: eliminate rarely-requested services, automate frequently-requested ones, and identify process improvements for slow-to-fulfill requests. Strong analytics drive continuous improvement of the catalog and help justify investment in portal improvements. Track metrics like number of catalog requests, percentage of total requests, self-service conversion rate, and average fulfillment time. These show whether the catalog is delivering value.

Oblytech’s Approach to Service Catalog Consulting

We focus on user experience. A good catalog makes users happy because they can get what they need quickly. It also makes your team happy because they are not drowning in clarification questions. We help you build a catalog that serves users first, not one that optimizes internal processes at the expense of user experience. A catalog that is easy to use reduces demand on your service desk.

Decide what belongs in the catalog before arranging it

A catalog is a promise about what the service desk will deliver on request. Before anyone arranges categories or designs forms, the team should decide which requests the catalog is for. Routine, repeatable requests with a clear outcome belong there. Urgent faults, one-off projects and questions with no defined fulfillment path do not, and putting them in the catalog creates a queue that is never really finished. That boundary matters more than any layout decision, and it is worth settling with the service owners who will be held to it.

Choosing how to split items: three granularity models

Once the scope is clear, the next choice is how finely to split items. The options below each suit a different kind of organization, and they fail in different ways.

Granularity	Example shape	Strength	Failure to avoid
One item per outcome	A single item for getting access to a system, with the system chosen on the form	Short catalog, easy to browse	Forms that branch so much that nobody finishes them
One item per product or asset	Separate items for each laptop model or license type	Very specific routing and fulfillment	Catalog growth every time a product changes
Hybrid, outcome first with product variables	Outcome items with a controlled list of products inside	Balances browsing with precise fulfillment	Variable lists that are never maintained

The catalog item record is where each of these choices becomes visible, and the hybrid model is often the sensible default, but it only holds if someone owns the controlled lists. A product list that nobody updates will quietly send requests for retired equipment into a queue that cannot fulfil them.

A review sequence for the existing catalog items

Many catalog reviews start with an inventory of what already exists. A service catalog design guide is a useful companion for the inventory step. The sequence below works on a catalog of any size, and it produces decisions rather than a long list of observations.

1. Export every item with its owner, fulfillment group, request count for the last period and last edit date.
2. Mark items with no requests as candidates for retirement, and ask the owner whether the service still exists.
3. Compare the top requested items against the tickets the service desk handled by phone or email in the same period.
4. Check each form for fields that no fulfillment step reads, and remove or move them.
5. Confirm that each item routes to a group that currently exists and currently has members.
6. Agree a description for each item in terms the requester would use, then test it with a few people outside IT.
7. Set a review date for each item and name the owner who will be asked to confirm it.

Common design mistakes that make the catalog harder to use

Several patterns recur across catalogs. Items named after the fulfillment team rather than the request, so a requester looking for a new laptop cannot find it. Two items that cover the same need with slightly different forms, which splits requests and makes reporting meaningless. Forms that ask for approval-relevant data before the requester knows whether approval is needed. Each has a simple fix, but each fix changes the catalog’s structure, so it should be made in one planned pass rather than piecemeal.

Signs the design is working

A well-designed catalog shows a few telltale signs. Requests arrive through the catalog rather than by email for the same type of need. Fulfillment teams rarely ask the requester for information that the form should already have captured. Item owners can say when they last reviewed their item. A useful measure is the number of follow-up questions per request, which should fall as the forms are tightened.

When a consulting review should wait

If the service desk has no agreed list of fulfillment groups, the catalog will be designed against groups that will change. If no one owns the catalog, the review will produce recommendations that nobody has the authority to approve. In either case, the first output should be the ownership map and the group list, with the item redesign scheduled after them. The request fulfillment and service catalog governance model is a sensible place to record those decisions.

Questions catalog owners ask during a design review

Should every item have an approval step?

No. Approval should follow from a rule, such as cost, data access or policy, rather than being added to every item out of caution. Items that never need approval should not carry an approver field at all, because a field that is always set to the same value teaches requesters to skip it.

How do we handle requests that do not fit any item?

Give the requester a general request item with a short, mandatory description, and route it to a triage group. Track those requests for a period. The ones that recur are the evidence for a new item, and the ones that do not recur should stay in the general route.

Who should write the item descriptions?

The item owner drafts the description, and someone who regularly handles requests of that type checks it. Descriptions written only by the team that fulfils the request tend to describe the work, not the outcome the requester wants.

Is a mobile-friendly catalog a design question or a configuration question?

Both. Keeping forms short is a design decision that helps every device. Testing how the forms render on a phone is a configuration check. A form that works on a desktop can be unusable on a small screen because of long variable sets.

What should happen to items that are retired?

Retire them visibly. Remove them from browsing, point any linked knowledge articles to the replacement, and keep the historical requests reportable. Deleting an item without checking its links leaves requesters with a broken path and reporting with an unexplained gap.

Next step

An export of your current items with request counts and owners is enough to begin a meaningful review.