Don't Panic — Service Catalog Management

A service catalog is the controlled front door for requestable services. It turns “I need something from IT” into a named outcome, a small set of useful questions, and a fulfillment path that somebody owns. Before that door exists, people guess at queues, send email, or describe a need in enough free text to keep several people busy interpreting it. None of these is a crime, but none is a delivery design either.

The central character is the catalog item. It is not an inventory record and it is not every task a team performs. It is one thing a person can request: a laptop, application access, or new-employee setup. The item says who may request it, what result they receive, and what information changes the decision or delivery. This is why a catalog form should not become a survey wearing a lanyard. If an answer changes nothing, remove the question or derive it from known information.

After submission, a request item gives one piece of the order its own fulfillment work. One request can contain several of them. An order guide is the helpful usher when one goal needs related outcomes, such as equipment, an account, and collaboration access for a new employee. It collects shared answers once, then lets the responsible groups work on their separate parts without pretending that several jobs are one job.

Control belongs here, but it needs a reason. Eligibility decides who can see or request an item. Approval is for an accountable decision about access, cost, licensing, security, or policy. Approval is not a ceremonial waiting room. Automation also comes later than people expect: first make the outcome stable, the inputs complete, and the owner and normal fulfillment path clear. Then automate the repeatable portion and leave exceptions visible.

The awkward surprise is that publishing an item is the beginning of its management, not its graduation. Abandonment, rework, rejected requests, misrouting, and long delays tell you where the promise and the delivery path disagree. Low use can mean an item is obsolete, hidden, or hard to recognize. Retire it when the service is no longer available; a catalog promise the operating team cannot keep is impressively efficient at creating confusion.

Read the Intro for the operating model and its boundaries. Use Slides for the request-to-fulfillment flow. Keep the Cheatsheet nearby when reviewing an item. The practice reference turns that review into a repeatable technique, and the exercise asks you to design one item whose decisions can survive contact with a fulfillment team.