Why service request catalogs struggle and how to fix them
I still remember the moment I realized I had underestimated the service request catalog. I was leading an ITSM tool implementation in a previous role, and most of my attention went to the parts that looked more complex on paper. Incident, change, integrations and the overall design of the tool. The catalog felt simple in comparison, so I treated it like a small configuration task. Something to finish once the major pieces were in place.
At first, everything seemed fine. The system went live, people logged in and tickets moved. Nothing dramatic happened. But small signs started to surface. Users weren’t selecting the request types we had carefully designed. They weren’t choosing the wrong item. They were choosing Other, because nothing else felt close to what they needed. I remember opening the usage report, expecting to see which items were gaining traction so we could refine them. I was even a little excited to look at the early data.
Then I saw it.
The most used category in the entire catalog was Other, and my heart sank. That single data point said more about the catalog than any feedback session ever could. It didn’t guide anyone. It didn’t automate anything. It didn’t reduce work. It simply confirmed that users had nowhere meaningful to go. That moment changed how I viewed service request management. We missed cost savings because none of the automation behind those items was triggered. We missed the chance to give users a predictable experience. And instead of reducing manual work, we created more of it.
A pattern that appears in many organizations
After seeing it firsthand, the same signs became easy to spot elsewhere. Many organizations proudly share a high self-service adoption rate. On paper, it looks like progress. But when Other is the top request, the value is not there. No automation is firing. No insight is captured. The numbers may look healthy, but they hide the real story.
Why catalogs struggle
A common issue is the perspective they are built from. IT teams think in categories, systems and internal structures. Users do not. They look for outcomes. When the language does not match how people naturally describe their needs, they guess. And when they guess, everything downstream breaks. Data, automation, routing and reporting. Ownership is another challenge. Without someone maintaining the catalog, items become outdated. Once trust fades, usage becomes inconsistent, and the numbers lose meaning.
The numbers behind the impact
A manually handled service desk ticket often costs around 20 - 25 dollars.
A request routed through a clear catalog with automated workflows usually costs between 2 and 5 dollars.
Some simple examples illustrate the gap:
A basic access request that costs 25 dollars manually might cost 3 dollars through self-service.
A password reset handled by the service desk might take seven minutes of technician time. A self-service reset takes zero.
If a company gets roughly 10,000 requests a year and even 30 percent move into proper self-service, the savings start to add up fast.
For a simple illustration, imagine those 3,000 requests moving from manual handling at 25 dollars each to self-service at 3 dollars.
That drops the cost from 75,000 dollars to 9,000 dollars, which means a saving of 66,000 dollars. All from making the path clear enough for people to use it.
Studies also show that 60 -70 percent of employees prefer self-service when the path is simple and predictable. And with a well-structured catalog, adoption rates above 70 percent are realistic. These numbers made the consequences of my own project much clearer. We had the potential to save both time and cost, but the catalog prevented us from capturing any of it.
Where my own project went wrong
Looking back, the mistakes are obvious. I focused too much on the landing page and not enough on the request items themselves. I treated the catalog as a side activity. I never assigned ownership. I wrote items in IT terminology instead of the language users actually use. And once the catalog went live, I assumed it was finished. It was not.
What works
Strong catalogs feel simple because the work behind them is deliberate. They speak in outcomes rather than internal terms. They focus on the high-volume requests that shape most of the user experience. They avoid jargon. They automate where it makes sense. They have clear ownership. And they are reviewed regularly so they stay aligned with how the organization actually works. A good catalog is not a project. It is a product. It grows and adapts.
How AI changes the landscape
AI will influence how people request services. Some interactions will move into conversational channels where users never see a traditional catalog. But the backend still matters. Automation, routing and fulfillment logic do not disappear just because the front-end changes. If anything, AI depends even more on a structured foundation. Without clear request definitions beneath the surface, even the smartest interface will struggle to deliver value.
A closing thought
That early mistake shaped how I work today. A strong service request catalog reduces cost, streamlines work and creates a far better experience for users. A weak one creates friction that spreads across the entire service landscape. When you take the catalog seriously, everything built on top of it becomes easier to manage. The result is not only efficiency. It is clarity, consistency and fewer surprises for everyone involved.
