A service catalog exists to let someone request what they need without knowing which team owns it or what the internal process is called. Most catalogs fail this test because they're organised by department — IT, HR, Facilities — which requires the requester to already know who handles their problem, which is exactly the knowledge the catalog was supposed to remove the need for.
The fix is organising by task rather than by owner. Not 'IT Hardware Requests' but 'Get a new laptop.' Not 'Facilities' but 'Book a meeting room' or 'Report something broken.' A requester searching for what they want to do finds it in one click; a requester searching for which department to blame gives up and sends an email, which is how service catalogs get bypassed within weeks of launch.
Keep the number of options small and specific rather than comprehensive. Ninety possible requests, most used a handful of times a year, buries the ten requests that make up eighty per cent of volume. Build those ten properly — with the right approval routing and the right information collected up front — and let everything else go through a general request form. A catalog trying to anticipate every possible ask becomes unusable for the common case it exists to serve.
Measure whether it's working by watching what still arrives by email. Every request that bypasses the catalog and lands in someone's inbox directly is either a gap in the catalog or a sign that the catalog entry for that request is worse than just asking a person. Both are fixable, and both require someone to actually look at what's landing outside the system rather than assuming the catalog is being used because it exists.
