Building a Service Catalog Your Users Actually Use

The catalog nobody opens

Plenty of IT teams have a service catalog. Most of them are ghost towns. Users still email a manager, message a friend on the IT team, or file a blank "I need help" ticket, because the catalog is a maze of a hundred cryptic entries that is slower and more confusing than just asking a human. The catalog exists; it does not get used; and the request chaos it was supposed to fix continues unabated.

A service catalog only earns its place when it becomes the easiest way to get something from IT. It is the menu of things people can request or that IT delivers — new laptops, software access, a new hire's full setup, a shared mailbox — presented as clear, orderable items with defined fulfillment behind each one. Done well, it structures demand, automates routine fulfillment, and sets honest expectations. Done badly, it is another dead intranet page. The difference is almost entirely in the design.

Request catalog versus service portfolio

Two things often get called "the service catalog," and conflating them is a common early mistake. Keep them distinct:

• The service portfolio is IT's internal view — every service IT runs, including the back-end infrastructure and platforms users never directly request. It is a management and planning tool.
• The request catalog (or user-facing service catalog) is what employees actually see and order from. It contains only the things a person can request, written in their language.

This article is about the second one, because that is what users touch. The cardinal rule follows directly: the catalog is written for the requester, not the IT department. Users do not know or care whether their need maps to an Exchange configuration or an Active Directory group. They know they need "access to the shared finance drive." Every entry should be named and described the way a non-technical person would ask for it — outcomes and plain language, never system names and internal jargon.

Start narrow with the requests you already get

The instinct when building a catalog is to be comprehensive — enumerate every possible service on day one. That produces the unusable hundred-item maze. The better path is to start with the small number of requests that make up the bulk of your actual demand.

Pull your request history and rank by volume. In almost every organization a short list dominates:

• New hardware — laptop, monitor, phone, peripherals.
• Software and application access.
• Access to a system, drive, group, or mailbox.
• New-hire onboarding setup.
• Common changes — a distribution list, a name change, mobile enrollment.

Build clean, excellent catalog entries for those first. A catalog with fifteen well-designed, genuinely useful items beats one with two hundred neglected ones, because users learn that the catalog works and come back. Expand from there, adding entries as real demand justifies them rather than speculating about requests nobody makes.

Design each entry to be self-sufficient

A catalog item works when a user can complete the request correctly without asking a follow-up question. That means each entry captures exactly what fulfillment needs — no more, no less. The design discipline for a single item:

• Ask only the questions fulfillment actually requires. Every field a user must fill is friction. Cut anything IT does not truly need, and never make the user supply information you already hold about them.
• Use their vocabulary. The title and description should match how people describe the need, so search finds it and users recognize it.
• Encode approvals into the item. If a request needs a manager's sign-off or a budget approval, build that routing into the workflow so it happens automatically — not as a separate email the user has to chase.
• Set a clear expectation. State how long fulfillment typically takes. A user who knows a laptop takes three business days does not open a "where is my laptop" ticket on day one. Managing expectations deflects follow-up contacts as surely as fulfilling fast does.

Getting the intake right is what makes the rest possible. A request that arrives complete and correctly routed can flow to fulfillment — often automatically — instead of bouncing back for clarification.

Automate fulfillment behind the menu

The catalog is the front door; automation is what makes it fast. A structured request with clean, validated inputs is exactly the kind of work that can be fulfilled with little or no manual effort. This is where the catalog stops being a nicer ticket form and starts genuinely reducing load.

The highest-value target is access and account requests, which typically dominate volume. Wired into your identity and access management platform, a catalog request for access can flow through approval and be granted automatically — secure, logged, and consistent, with no engineer in the loop. Role-based bundles take this further: rather than requesting nine things individually, a manager onboarding a salesperson picks one "Sales onboarding" item that provisions the entire standard set at once.

Even where full automation is not possible, a well-structured catalog request routes straight to the right fulfillment team with everything they need already attached, cutting the back-and-forth that inflates handling time. Layer the automation in gradually: start by making requests structured and correctly routed, then automate the highest-volume items as you prove each workflow.

Make it findable, then measure whether it works

A catalog users cannot find might as well not exist, and one you do not measure will quietly drift back into disuse. Both are solvable.

On findability:

• Put the catalog where people already are — the tools and portal they use daily, ideally reachable through search and chat rather than buried behind several clicks.
• Lead with search, not a category tree. People type what they need; make sure the plain-language terms and common synonyms surface the right item.
• Keep the list lean. Every dead or duplicate entry makes the useful ones harder to find. Prune ruthlessly.

On measurement, watch the signals that reveal whether the catalog is doing its job:

• Catalog adoption — the share of requests coming through the catalog versus email, chat, and blank tickets. Rising adoption is the headline sign it is working.
• Fulfillment time per item — where requests stall, so you know what to automate or streamline next.
• Automation rate — the proportion of catalog requests fulfilled with no manual touch.
• Return rate — how often requests bounce back for missing information, which points straight at intake design that needs fixing.

Run the catalog as a living product: watch which items get used, fix the ones that generate confusion, and let real usage guide what you add next.

Where to start

Do not try to catalog everything. Pull your request data, pick the ten to fifteen highest-volume requests, and build clean, self-sufficient entries for those — written in the user's language, with approvals and expectations built in. Wire the access requests into identity automation first, since they carry the most volume and automate the most cleanly. Then measure adoption and expand from what people actually use.

intSignal builds usable service catalogs into managed help desk and IT support, with identity-driven automation so routine requests fulfill themselves instead of filling a queue. If your catalog is a page nobody visits, talk to our team.