Service Management Best Practices

Overview

Service discovery is the ability of a Service Requester, customer, consumer, system, application, or stakeholder to find the right service, understand whether it applies to their need, and know how to request, invoke, or consume it. Poor service discovery causes requesters to guess, submit work through the wrong channel, call the Help Desk or Service Desk unnecessarily, use outdated links, send informal messages, or create duplicate and misrouted tickets.

Service discovery should be designed around the needs of the Service Requester. The organization should not assume that requesters understand internal team structures, application ownership, technical domains, support queues, or service management terminology. Services should be named, described, organized, tagged, and exposed in ways that make sense to the people, roles, teams, systems, or applications that need to use them.

A Service Catalog is one common way to support service discovery, but it is not the only way. Services may also be discovered through intranet pages, departmental portals, workflow tools, knowledge articles, chat interfaces, API catalogs, automation platforms, or other approved Service Engagement Channels. Regardless of channel, service discovery should lead the requester to the correct Service Details, request path, invocation method, support path, or next step.

Best Practice

Design service discovery from the point of view of the Service Requester.

Service discovery should begin with how requesters think about their needs, not how internal teams organize their work. Service names, descriptions, categories, aliases, and navigation paths should reflect common requester language, business context, tasks, outcomes, and problems to be solved.

For example, a requester may look for “new laptop,” “application access,” “reset password,” “hire employee,” “set up vendor,” or “request report.” The organization may internally route those requests to End User Services, Identity Management, HR Operations, Procurement, Finance, or Data Services, but the requester should not need to know those internal routing structures to find the service.

Benefit(s)

Requester-centered discovery reduces misrouted requests, duplicate tickets, informal workarounds, and unnecessary Help Desk or Service Desk contacts. It improves customer experience and makes services easier to consume.

Best Practice

Use plain-language service names, aliases, and search terms.

Services should be findable through the words requesters actually use. Formal service names may be necessary for governance, but aliases, keywords, synonyms, and common phrases should also be supported where practical. This is especially important when different communities use different terms for the same service.

For example, “Request Application Access” may also need to be findable through “app access,” “system access,” “user access,” “permissions,” “role access,” and “login access.” A Help Desk or Service Desk service may need aliases for “support,” “service desk,” “help desk,” “IT help,” and “technical support.”

Benefit(s)

Plain-language naming and aliases improve findability, reduce requester frustration, and increase adoption of approved Service Engagement Channels. They also improve search quality in catalogs, intranets, portals, and knowledge systems.

Best Practice

Organize services by context, role, organization, task, and common need.

Service discovery should support multiple navigation paths when requesters have different mental models. Services may be organized by business function, role, service group, lifecycle event, task, technology area, location, requester community, or common need. The organization should choose structures that help requesters find the correct service quickly.

For example, an employee onboarding service might be discoverable under HR Services, Manager Services, New Hire Setup, IT Access, Facilities, and common employee lifecycle events. An API access service might be discoverable under Developer Services, Integration Services, Data Services, or specific product and platform pages.

Benefit(s)

Multiple useful discovery paths help diverse requester communities find the same governed service without creating duplicate services or conflicting request paths.

Best Practice

Support distributed service discovery across approved Service Engagement Channels.

Services may be discovered from more than one place. A service may appear in a formal Service Catalog, intranet site, departmental portal, chatbot, knowledge article, API catalog, or workflow tool. Distributed discovery is acceptable when the underlying service definition, Service Details, request path, ownership, and expectations remain governed and consistent.

For example, a vendor setup service may be discoverable from a Finance portal, Procurement page, onboarding checklist, and Service Catalog entry. Those discovery points should lead to the same governed service or the same authoritative request path, not to competing forms or inconsistent instructions.

Benefit(s)

Governed distributed discovery allows requesters to find services where they naturally work while preserving service ownership, consistency, reporting, and control.