Building a Service Catalog Your Staff Will Actually Use
A service catalog is the menu of what your team offers: new laptop, software licence, access to a shared drive, a new starter setup. Without one, every request arrives as free text and your team spends its day asking clarifying questions.
Start from what people already ask for
Do not design the catalog in the abstract. Read the last month of tickets and pull out the requests that repeat. Those five or ten items are your first catalog — everything else can stay free-text until a pattern appears.
Each item needs four things
- The questions to ask upfront. A laptop request that captures role, location and whether it is a replacement never needs a follow-up email.
- Who approves it. Some items need a manager, some need finance above a threshold, most need nobody. Encoding this stops approvals happening informally over chat.
- What fulfilling it involves. The task list your team works through, so it does not live in one person's head.
- What to promise. A realistic turnaround, published, so nobody has to chase to find out.
Requests are not incidents
This is the distinction teams miss most. "I need a new laptop" is a service request — expected, plannable, approvable. "My laptop will not boot" is an incident — unplanned, and someone is blocked right now. Mixing them means your incident queue fills with orders and your genuine outages get buried.
Publish it where people already look
A catalog nobody can find is a spreadsheet. It has to be on the portal people reach when they need something, ideally the same place the knowledge base lives — so half of them solve it themselves before raising anything at all.
Keep it small
The most common failure is a catalog with ninety items nobody maintains, where a third point to people who left. Ten accurate items beat ninety stale ones.
SupportCentral ships a service catalog where each item carries its own intake questions, approval chain and fulfilment tasks, published on the self-service portal alongside your knowledge base. See how requests differ from incidents.