ServiceNow Service Catalog Health Check

What a Service Catalog Health Check Evaluates

A Service Catalog health check assesses how effectively self-service request intake is working. The evaluation covers whether the catalog structure is helping users find what they need, whether request forms are clear and capture necessary information, whether fulfillment workflows are working efficiently, and whether users are using the catalog or bypassing it by contacting support directly.

The assessment examines automation opportunities: which routine requests could be automated to reduce manual work. Assessment also includes evaluation of catalog adoption rates and user satisfaction.

Catalog Structure and User Navigation

The assessment reviews whether catalog categories match how users think about their needs. Surveys or usage data show whether users can find items easily or whether they frequently search for items they believe should exist but cannot find.

Request form complexity is evaluated. If forms have too many mandatory fields, users abandon the request process. If forms ask too few questions, fulfillment teams struggle to understand what was requested.

Adoption and Usage Metrics

Adoption metrics compare self-service request volume to help desk request volume for the same types of issues. If hardware requests should be going through the catalog but are instead being submitted by email, adoption is low and barriers should be identified.

User satisfaction surveys ask whether the catalog experience is clear, whether users found what they were looking for, and what improvements would increase usage.

Fulfillment Workflow Efficiency

The assessment examines fulfillment workflows to identify bottlenecks. If requests are spending excessive time in approval queues or if certain types of requests consistently take longer than others, workflow optimisation is recommended.

Opportunities for automation are identified: password resets, group membership requests, and access provisioning can often be fully automated. Account provisioning and hardware requests may require partial automation with human approval for cost or security decisions.

Integration With Other Modules

Service Catalog should integrate with Request Fulfillment so requests flow smoothly from submission to fulfillment. Integration with asset management ensures hardware fulfillment creates asset records. Integration with access management ensures access requests update user role assignments automatically.

Recommended Improvements and Roadmap

The health check produces recommendations for catalog improvements: reorganising categories to improve navigation, redesigning forms to improve clarity, automating routine fulfillment steps, and expanding the catalog to cover additional request types currently handled through other channels.

A prioritised roadmap shows sequencing for improvements based on impact and effort. High-impact, low-effort improvements are prioritised. Major restructuring is sequenced after foundational issues are resolved.

Oblytech’s Service Catalog Health Check Services

We assess current catalog maturity through data analysis, user interviews, and configuration review. We provide recommendations for improvement with an estimated effort for each. Implementation services include catalog restructuring, form redesign, fulfillment workflow optimisation, and automation implementation. Training is provided to help teams use improved workflows.

Feedback Mechanisms and User Surveys

User feedback should be collected regularly to understand what’s working and what needs improvement. In-app feedback forms allow users to report issues or suggestions. Periodic surveys ask users about satisfaction with the catalog experience. Feedback drives improvements.

Integration With Fulfillment Analytics

Catalog analytics should be linked to fulfillment analytics so you understand the full journey: how many people browse the catalog, how many start a request, how many complete it, how many abandon mid-process. Abandonment rates indicate where the request process is causing friction.

Linking catalog items to knowledge articles

Service Catalog items should link to knowledge articles that explain the request process or common questions. A request for access might link to an article about access levels and what each provides. Knowledge links reduce questions and improve self-service completion rates.

Metrics Dashboard for Service Catalog Operations

Operations staff who fulfil requests need dashboards showing queue depth, average fulfillment time, bottlenecks, and resource utilisation. These metrics help managers allocate resources and identify process improvements. Operational dashboards drive continuous improvement in fulfillment efficiency.

Customisation and Configuration Options

Service Catalog can be customised to match specific organisational processes. Item templates can be created for different request types. Conditional logic can show or hide form fields based on user input. Customisation should be balanced against maintainability: excessive customisation makes the catalog difficult to manage.

Integration Success and Metrics

A successful health check engagement produces recommendations that increase self-service adoption, reduce fulfillment time, and improve user satisfaction. Success is measured by comparing adoption rates before and after improvements, comparing average fulfillment time, and surveying users on satisfaction with the improved catalog.

Start from the requests that bypassed the catalog

A health check is most useful when it begins with a question the service desk can already answer: which requests arrived by phone, email or chat that should have gone through the catalog? Those requests show where the catalog is failing. Some will be for items that do not exist, some for items that exist but are hard to find, and some for items that the requester tried to submit and abandoned. Each group needs a different fix, so the review should sort them before recommending anything.

The request funnel as a diagnostic

The clearest way to see where people give up is to follow the funnel: visits to the catalog, searches, item views, started requests and submitted requests. Each step should be counted for the same period. The table shows how to read the drop at each stage.

Stage with the drop	Most likely cause	First check
Visit to search	Requesters cannot tell what the catalog offers	Compare category names with the words used in tickets
Search to item view	Search returns items that do not match the request	Review the search terms of the top unmatched queries
Item view to started request	The item is for a different need than the requester has	Read the description against the wording of recent calls
Started to submitted request	The form is too long, or asks for data the requester lacks	Count the mandatory fields and the ones left blank most often

A drop at the last stage is the most actionable, because the form is entirely under the catalog team’s control. A drop at the first stage usually needs a change to naming and structure rather than to any single item.

Checking forms against the fulfillment steps

Every field on a request form should be read by at least one fulfillment step, approval rule or report. A useful exercise is to list the fields and tick those that a step reads. Fields with no tick are candidates for removal. Fields that a step reads but the requester always has to type are candidates for population from the user record. The result is usually a shorter form that gives fulfillment teams the same information.

Integration checks that a health check should include

A catalog is only as good as the links behind it. The review should confirm that each item reaches a live fulfillment group, that any asset record created by a hardware request is linked to the requester, and that access requests update role assignments as intended. Testing each link with a real request in a non-production environment, using the testing and acceptance checklist, is more reliable than reading the configuration, because configuration can look right while a dependent group has been retired.

Checklist for the review

1. Pull the funnel counts for the last full period and note the largest drop.
2. Sample twenty recent requests that arrived outside the catalog and classify each as missing item, hard to find, or abandoned.
3. Read every form that is abandoned most often and list its mandatory fields.
4. Test three representative requests from start to finish in a non-production environment.
5. Check that each item’s fulfillment group has active members and a current owner.
6. Confirm which knowledge articles are linked from items and whether they still match the process.
7. Write the recommendations as a short list, ranked by the number of requests each one would move into the catalog.

Automation candidates the review should identify

Routine requests such as password resets, group membership changes and standard access are often better suited to automated fulfillment than to a queue. The review should identify which of these are currently handled by hand and whether the approval rules behind them are still appropriate. Where a linked article could remove a request altogether, knowledge deflection is the option to weigh first. Automation that approves access without a rule that reflects policy can be faster and still wrong, so the review should check the rule first.

When a health check reveals a bigger problem

If most requests bypass the catalog, the cause is usually a trust problem: requesters have learned that catalog requests are slow or lost. A health check can show the pattern, but rebuilding trust takes a visible period of reliable fulfillment. Visible progress often helps adoption, so request status transparency is worth reading once the reasons for bypassing are known.

Questions teams raise about catalog health checks

Is a requester survey required before a catalog review can start?

Yes, because the funnel and the bypassed requests show a great deal on their own. Surveys add the reasons people give for their behavior, which is useful for prioritizing changes, so a short survey is worth adding if the team can reach requesters without causing survey fatigue.

How do we separate a catalog problem from a fulfillment problem?

Look at the time between submission and fulfillment for the items in question. If requests are submitted easily but sit for days, the problem is in fulfillment. If requesters abandon before submitting, the problem is in the catalog. Both can exist at once, so the review should measure them separately.

Should search terms be tuned to match the wording of tickets?

Often yes, through synonyms and item descriptions rather than by renaming items. Renaming items every time a requester uses different words makes the catalog unstable. A short list of common terms with clear descriptions usually closes most of the gap.

What if the same request appears under two items?

Choose one item as the canonical route, redirect or retire the other, and check the reporting so that historical requests still count toward the right service. Leaving duplicates in place splits demand and makes it impossible to see which item is really used.

How often should the catalog be health-checked?

Often enough to catch a broken route before requesters notice, which in practice means a light check on a regular cadence and a fuller review when the fulfillment structure changes. How often that is worth doing depends on the pace of change in the catalog, so agree the cadence with the item owners.

Next step

The team can help decide whether the drop points to structure, forms or fulfillment, and that decision sets the scope of any follow-up work.