Service Catalog

A service catalog is a structured, discoverable list of the services an organization offers, whether to employees internally or to customers externally. For each service, it says what the service actually provides, where its boundaries are, and how to request it. Its purpose is to replace tribal knowledge about "who do I ask for this" with a single place anyone can look.

Key components

• A clear description of what each service actually provides — concrete enough that someone can tell whether their need is covered, including what's explicitly out of scope.
• How to request or get support for it — the specific form, portal, ticket type, or contact for requesting the service or getting help with it, not a vague pointer to "IT" or "contact us."
• An owner per service — a named person or team accountable for the service's quality and for keeping its catalog entry accurate, so a request or complaint always has somewhere clear to land.
• Service-level expectations — the response and resolution commitments tied to the service, typically defined in a Service Level Agreement and linked from the catalog entry rather than restated inline.
• Categorization and search — services grouped in a way people actually think in (by department, by task, by system), so someone can find what they need without already knowing its official name.

Why discoverability is the whole point

A catalog that's accurate but buried in a wiki nobody browses, or split across several outdated spreadsheets, delivers none of the value a catalog exists to provide — a catalog nobody can find might as well not exist. The bar isn't just "this is documented somewhere"; it's that someone with a need can find the right entry in under a minute without knowing in advance what it's called or who owns it. That means one authoritative location, consistent naming, and a search or browse structure that matches how requesters actually describe their problem, not just how the service is organized internally.

Common pitfalls

• Entries stale relative to what the service actually does now — a service that's changed scope, ownership, or how it's requested but whose catalog entry wasn't updated sends people down the wrong path with outdated confidence.
• No named owner — an entry with no accountable owner means a request or an escalation has nowhere clear to go, and it drifts between teams until someone reluctantly picks it up.
• Vague service boundaries — a description broad enough to sound like it covers everything leaves users unable to tell whether their specific need is actually in scope, so they either request the wrong thing or don't request anything at all.
• Catalog split across multiple uncoordinated lists — separate catalogs per team or system, none of them complete, forces people to already know which list to check.
• Built once and never revisited — a catalog with no process for adding new services or retiring old ones falls out of date the first time the service portfolio changes.

Learn more

• Service Level Agreement for the specific performance commitments behind a catalog entry's service-level expectations.
• Change Request for how a modification to an existing service typically gets requested and approved.
• Runbook for the operational procedures a service's support team uses to actually deliver on a catalog entry.
• Org Chart for identifying the right owner or team behind a service when a catalog entry doesn't name one directly.