Service catalog in plain language: describing services the way people recognize them

Many service catalogs are written for IT, not for the user. They list application names, server codes and internal abbreviations, and an employee who needs something recognizes none of it. So they call the service desk anyway, because that at least works. The catalog exists, but nobody treats it as the first step. This article shows how to build a service catalog people actually understand, start small, and connect it to the request portal you already have.

Why most catalogs miss the mark

A catalog built around systems mostly tells the user how IT organizes the world. "Access to purchasing module finance system" or "VPN client type 2" means nothing to an employee. They do not know which application sits behind it and they do not want to know. They just want to be able to work from home, or approve an invoice.

That mismatch in language is why catalogs often go unused, even when the technology behind them works fine. People search for what they want to achieve, not for what runs in the background. When those two do not meet, the catalog falls back to a list that only IT itself still understands.

Think from what the user wants to achieve

Translate system names into tasks

Flip the description around. Instead of putting the system name front and center, describe what someone can request and why. "I want to work remotely" is a service. VPN or some other tool may sit underneath it, but the user does not need to see that. The title and the first line of every service should be understandable without any IT knowledge.

Group what belongs together

Users do not think in departments or systems, they think in situations: a new colleague starting, a broken laptop, access needed for a project. Group services around those situations rather than the technology behind them. That makes the catalog easier to scan and stops people scrolling through dozens of separate items.

Start small and connect to the portal

Building a complete catalog in one go is a project that never finishes. It works better to start small with the services requested most often, and expand from there. That works in a few steps:

1. Identify your ten most requested services. Look at your current tickets and requests to see which topics come back most.
2. Rewrite those ten in plain language. One clear title, one sentence of explanation, and the steps needed to make the request.
3. Link every service straight to the request form. A user who recognizes the service should be able to request it in one click, without searching further.
4. Measure what actually gets used. If a service is never requested through the catalog, the description is probably still too technical or hard to find.
5. Expand only once the basics work. Add new services once you are confident the first ten are working well.

This approach keeps you from spending months on a catalog that is already outdated by the time it launches. A small, current catalog connected to the portal works better than an extensive one nobody maintains.

What it delivers

A service catalog written in plain language helps people find the right request themselves, without calling the service desk first to ask what they actually need. That saves time on both sides: the user gets help faster and the service desk receives fewer wrong or unclear requests. That is achieving more with the same people, simply by matching the catalog to how people actually think.

Frequently asked questions

Do we need to rewrite every service at once? No. Start with the services requested most often and expand gradually from there. A small, well-maintained set works better than a large one that is only half right.

Who should write the catalog text? It works best when someone who actually sees the requests writes alongside someone who understands the user side. Purely technical text from the specialist alone tends to slide back into jargon.

Do we need a separate system for a service catalog? Usually not. Most request portals already include catalog functionality. The problem rarely sits in the tool, but in the wording and the structure.

Want a service catalog people actually use instead of skip past? book a call and we will look together at which services to translate into plain language first.

Further reading

• Service catalog (Wikipedia)
• IT service management (Wikipedia)