---
name: service-catalog
description: Use when asked to build or document a service catalog — a structured, discoverable list of the IT or business services an organization offers internally or externally, what each includes, and how to request it — as distinct from a [[service-level-agreement]], which defines the performance commitment for one specific service rather than listing what services exist at all.
---

# 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.