OBLYTECH Logo
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Service Portal Navigation: Design for the Next Step

ServiceNow service portal navigation should help a person understand what service they need, find the right route, provide the required information, and know what happens next. Navigation is not only a menu structure; it includes service names, search terms, eligibility, content, ownership, and escalation.

For ServiceNow experience and service owners improving how people find and start the right service..

ServiceNow service portal navigationServiceNow portal designservice catalogue navigation

Guide map

Menus and Links That Lead to the Next Action

Start with what users are trying to do

Portal navigation improves when menus are arranged around the tasks people arrive with, such as reporting a problem or checking a request, rather than the internal team names.

Name services in the user’s language

Use the words requesters already use for their problems in service names and menu labels, not the internal names the platform team prefers.

Connect navigation, search, and eligibility

Menu items and search results should only offer services a person is allowed to request, otherwise people click through to a form they cannot submit.

The practical framework

Design ServiceNow service-portal navigation around user intent, service names, search, eligibility, audience, ownership, content, and escalation paths.

Begin with user situations and decisions. People often describe a problem rather than the department or catalogue item that owns it.

Start with what users are trying to do

List common tasks, questions, symptoms, role differences, and the point at which a person needs help. Group services by user intent where that improves discovery, while preserving the actual service and owner boundary.

The ServiceNow employee-service route is the relevant internal destination when portal navigation needs to connect different employee and enterprise services.

Name services in the user’s language

Use service names and descriptions that explain the outcome, eligibility, required information, and next step. Keep internal team names, platform terms, and implementation labels from becoming the only way to find the service.

The ServiceNow service-catalogue route provides an internal path when catalogue structure and intake need design.

Provide examples and related terms without creating duplicate routes that split ownership. A person should know when to choose a request, incident, case, knowledge answer, or contact path.

Connect navigation, search, and eligibility

Test menus, search, categories, filters, links, role visibility, and service eligibility together. A result that appears but cannot be requested creates a different problem from a service that is eligible but impossible to find.

The ServiceNow knowledge-management route gives the reader an internal path for search content and preparation guidance.

Define what happens when no result is useful: a clarifying question, support route, incident path, or service owner review. Do not send people into an empty search experience.

Keep content and ownership current

Assign an owner for service description, eligibility, instructions, search terms, related content, and review trigger. Review navigation when a service, process, owner, role, or route changes.

The ServiceNow continuous-improvement route provides an internal path for portal findings and content changes.

Test the path from question to completion

Use real user questions and role contexts. Check whether the person can find the service, understand the route, complete intake, see ownership, receive communication, and reach closure or escalation.

The ServiceNow user-adoption training route gives the reader an internal path when user feedback or training reveals navigation problems.

Common questions

Questions teams ask about portal navigation

Should every service appear on the home page?

No. Prioritise common or important user intents, provide a usable search and category path, and avoid hiding less frequent services. Visibility should reflect user need and service ownership rather than a department’s preference alone.

What should happen when search fails?

Offer a clearer question, related service, knowledge guidance, support route, or owner review. Record the failed intent so content, naming, or service structure can be improved.

The research-grounded boundary

Navigation design should stay specific to the service being decided. A service or business outcome is easier to run when its purpose, boundary, owner, exception handling, and evidence are written down. ServiceNow platform and ITSM are where many of these services live, but they do not replace that written decision. Keeping that order makes portal navigation a question of service decisions rather than a general platform claim.

Choosing a navigation model that matches how people arrive at the portal

Service portals are usually organized in one of three ways: by the department that delivers the service, by the kind of task the person has in mind, or by the audience the person belongs to. Each model answers a different arrival pattern. A department-led structure suits people who already know which team owns their problem. A task-led structure suits people who know what they want to achieve but not who handles it. An audience-led structure suits a portal that serves very different groups, such as employees, contractors and managers, who need different entry points. Some portals combine two of them, but one usually leads.

Navigation modelServes bestWeakness to design againstSignal that it is failing
By delivering departmentStaff who already know the owning teamSplits one need across several departmentsPeople search for a service they cannot place
By task or intentPeople who describe a problem, not a teamOverlap between similar tasksThe same service is requested through two routes
By audiencePortals with clearly different user groupsShared services get duplicated per audienceDuplicate services with inconsistent wording
Search-first with a short category setHigh volume of users who type freelySearch quality depends on naming disciplineFrequent searches that return nothing useful

The point of choosing is to make the weakness visible before it is built. A department-led portal that is used mostly through search is paying for a structure its users do not see.

Naming services so that the wording survives a search

Names decide whether a service is found. Internal labels, team acronyms and platform terms are comfortable for the people who maintain the catalog and meaningless to the people who use it. A practical sequence for renaming services follows.

  1. Collect the search terms that people have actually used over a recent period, including misspellings and the phrases they type when they are frustrated.
  2. Group those terms by the outcome the person wants, not by the team that delivers it.
  3. Draft each service name as the outcome, followed where necessary by a qualifier that states eligibility, such as a particular location or employment group.
  4. Check that no two services answer the same outcome. Where they do, merge them, or write a clear rule for choosing between them and show it on both.
  5. Write the one-line description the person sees before opening the service, stating what it provides and what information they will need.
  6. Test each renamed service with the people who originally used the old name, and watch whether they find it without help.

The second step frequently reveals that a single outcome has been split across three services because three teams each owned a part of it. Merging them can be one of the larger navigation improvements a portal makes in a single pass.

Designing the route for a search that returns nothing useful

Every portal will have failed searches. The design question is what the person sees next. A blank results page sends people to a phone call or to a colleague, and both routes lose the detail the portal could have captured. A better response depends on the type of failure. A misspelling should return the intended service with a visible correction. A question that belongs to knowledge content should land on the article. A need that no service covers should lead to a short form that records the intent, so that the gap can be reviewed by the service owners.

Recording failed searches as a review input turns the portal into a source of design evidence. A pattern of unmatched searches for one outcome is often the first sign that a service is missing, or that an existing service is named in a way nobody would search for.

Checks to run before any navigation change goes live

A menu that looks right can still break in a specific role or on a specific device. The checks below are the minimum that should run before a navigation or catalog change is released.

  • Search for each renamed service using the old name and two of the common misspellings, and confirm the new service appears first.
  • Sign in as one user from each audience and confirm that the services they should see are visible, and that those they should not see are hidden.
  • Confirm that every visible service can be started from the navigation, not only from search, and that the request actually reaches the owning team.
  • Check the same paths on a phone-sized screen, where long menus often collapse into lists that bury the second level.
  • Confirm the owner of each service description is named, and that the review trigger is recorded alongside it.

When restructuring the navigation will not help

If the services are themselves unclear, a better menu will only hide that problem more neatly. Before changing the navigation, confirm that each service has a single owner, an agreed eligibility rule and a description that matches what the team actually delivers. Where those are missing, the portal work is a service design task first and a navigation task second.

Does a crowded home page hurt the services people already find through search?

It can. When every tile carries equal weight, the services that receive the most requests lose the visual cue that tells a new visitor where to start. Keep the high-volume services prominent, and let search and categories handle the long tail.

How do we decide between two services that sound alike?

Write the decision rule as a single question the person can answer about their own situation, and show it on both services. If the question cannot be answered by a person, the two services probably should be one.

Who should be allowed to change service names?

The service owner proposes the change, and the portal owner checks it against existing names and search terms. Without that check, well-meant renaming creates duplicates that split the search history.

How often should navigation be reviewed?

Review it when a service, owner, team or eligibility rule changes, and at a regular interval using the failed-search record as the main input, so that the review is driven by what people actually did.

Reviewing portal navigation

If users report that they cannot find services they know exist, a review of search terms and service names is a sensible place to begin. The catalog item explainer defines a catalog item as a self-service request that users submit through the service portal, and the employee self-service page covers organizing employee tasks, catalog language, knowledge and search around what people need.

When portal navigation is on your roadmap, raise it with us through the contact page.

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.

ServiceNow guides on this topic

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

More from the blog