A service catalog instead of 'just email IT': how internal IT maturity grows

In most companies the relationship between IT and the rest of the business follows roughly the same pattern. A business unit wants something, so it contacts IT. IT tries to help. Nobody knows exactly what they are allowed to ask for, how long it will take, or who is responsible. Everything runs on personal relationships and the goodwill of specific individuals.

This works up to a point. After that it stops working. IT becomes an overloaded buffer where all requests accumulate, and nobody understands why everything takes so long.

What a service catalog changes

A service catalog is the answer to one question: what exactly does IT provide, and on what terms.

Not "we help with everything" but specifically: a new computer within three days, provisioning a user account within one day, connecting a new office to the network within two weeks, developing a new report - discussed separately.

A catalog does several things at once:

• it makes expectations explicit;
• it lets the business plan instead of just waiting;
• it lets IT measure its own work and manage priorities;
• it creates a shared language between IT and internal customers.

This is not bureaucracy. It is what makes the relationship predictable for both sides.

Why IT directors avoid it

Formalisation is uncomfortable for two reasons.

The first is fear of accountability. If you write down that a service is delivered in three days and it actually takes seven, that becomes visible. When expectations are not recorded anywhere, there are formally no complaints.

The second is the feeling that this is "not for our scale". A service catalog is associated with large corporations, ITIL, and heavy processes. A mid-sized company assumes it does not apply to them.

Both objections are understandable. But the first is not an argument against a catalog - it is an argument for bringing reality into line with commitments. And the second is a myth. A service catalog for a company of 200 people can be a simple document a few pages long.

What an internal product approach looks like

A mature IT department thinks about its services as products for an internal customer. Each service has:

• a description of what it includes and what it does not;
• delivery conditions - timelines, dependencies, what is needed from the requester;
• a cost - at least approximately, even if it is just an internal transfer price;
• an owner and a point of contact for problems.

The question of who decides and who calls whom when something breaks is a related piece of the same maturity picture.

This resembles how an external service provider operates. Just inside the company.

This approach changes the conversation with leadership. Instead of "IT is slow", it becomes possible to say: "Here is what we provide, here is the pace, here is what would need to change to make it faster". That is a manageable conversation, not mutual frustration.

When it makes sense to introduce one

A service catalog is not for everyone at every stage. There are signals that the time has come:

• the IT team regularly receives the same requests but handles each as if it were new;
• delivery timelines are unpredictable to the people asking;
• business units do not understand what IT does or why some things take a long time;
• there are now several IT staff, and coordination between them requires real effort.

This is not about headcount. It is about a level of coordination that no longer works informally.

A practical filter for getting started

If you are unsure whether a catalog is needed, answer three questions:

1. Can any employee in the company find out right now what IT will do for them and in what timeframe?
2. Can a new department head spend one hour and understand what to expect from IT?
3. Can the CIO explain to senior management in one meeting what IT actually produces?

If the answer to at least two of the three is "no", a catalog is already overdue. Even the simplest one will help.