I’ve spent the last 10 years helping customers digitize their Enterprise Service Catalog on ServiceNow. I’ve seen a lot 🙂

We often see teams spending 8-12 hours building one catalog item, only to come back a week later and spend just as long fixing it. Not because the build was wrong, but because something changed.

You’ve done this for years,  you and the team know what you’re doing. . You gather requirements, build a few forms, add approvals and flows, but somewhere along the way, things get bloated. Nobody knows who owns what. And suddenly, the intuitive , user-friendly Service Catalog you set out to build feels clunky, hard to maintain, and somehow outdated.

It’s not because people are doing things wrong on purpose. You work fast to meet a deadline, or you copy what was already there, or you follow what the business asked for while giving up a little bit of technical integrity. 

And before you know it, you're living with catalog items that frustrate users, burns out your your developers , and are expensive to maintain. 

Let’s go through the 5 most common mistakes that even experienced teams fall into, so you can spot them early, or avoid them altogether next time around.

1. Too much in one catalog item

The biggest, most common mistake I see combining too many requests into a single catalog item.

It usually starts out simple. You’ve got one request, maybe a handful of questions. But then the service owner wants to add more. One more option. One more section. Before you know it, the form has 50, sometimes even 100 questions. Pick option A, and one section appears. Pick option B, and something completely different shows up. At first, it feels like a nice, efficient way to handle requests. One form, one entry point. 

But what people don’t realize is how quickly that form becomes painful to manage.

Making changes later is where it gets hard. Let’s say you need to add a new field or adjust a UI policy. Now you’re trying to untangle logic that’s stacked across 20 or 30 policies. One change breaks something else. Debugging is slow, testing is even worse.

It also complicates reporting. If multiple services are buried in one item, how do you know what people are actually using? You can’t track usage, so you can’t improve anything.

And from the user’s standpoint, they don’t want to scroll through a massive form either. It’s confusing. They either abandon it or fill it out wrong.

This doesn’t mean you split everything into separate items, but trying to do too much in one place never ends well. Keep it simple. Break it up when it makes sense. Explore Order Guides to meet the requirement of “having one entry point” Your developers will enhance faster, your testers will update tests even quicker, and your users will thank you for it.

2. Not automating enough

The second mistake is not automating enough, and it’s not because the platform can’t do it. What happens is, the business gives you a requirement, and you build exactly what they ask for. They say, “Route this for approval via their manager,” so you add an approval. 

The problem is — they don’t know what’s possible, whereas you do.

So instead of just building what’s on the list, we need to take a step back. Do we actually need that approval? If it’s something that’s simple and always gets approved anyway, maybe a simple notification to inform would do. 

Similarly, do we really need the user to fill out their department when ServiceNow already knows it? Probably not.

The same logic goes for fulfillment tasks. Sometimes we’re creating catalog tasks just to ask someone to push a button. Could that be automated with Flow Designer or the IntegrationHub? Most of the time, we can.

What’s important to the business is getting the outcome, more specifically an expected output.  That’s where you come in. Finding those automation opportunities is one of the best ways to deliver real value, without burning out your team.

3. Ignoring Catalog Builder

When Catalog Builder first came out, most of us tried it once and then forgot about it because it felt clunky and limited. So we went back to what we knew — the platform view, building forms the old way.

But now it’s a completely different story. Catalog Builder has come a long way. For a lot of standard requests, it just makes life easier. In fact, it’s also a great tool if your org is starting to think about citizen development. 

Let your power users or business analysts create simple items within guardrails, while your developers focus on the harder tasks like integrations, custom logic, automation, and more.

It also helps with consistency. You’re not getting a dozen different styles of forms depending on who built them. If you’re like me and were burned by it a couple releases ago, I get it. But it’s worth giving Catalog Builder another shot. Especially if your team is already stretched thin and looking for ways to move faster without sacrificing quality.

4. Not optimizing  for ServiceNow

This one usually shows up during a migration. You’re moving something over from SharePoint, email, maybe the previous  ITSM system. And the instinct is to just copy the form as-is into ServiceNow and keep moving (lift and shift).

Those forms weren’t built for ServiceNow. They often have fields that don’t make sense anymore. By lifting and shifting them to ServiceNow without optimizing, you’re basically importing technical debt.

But the good news is, it doesn’t take much to fix. You just need to take a few minutes to go through the form, and ask yourself what can be automated, what fields can be swapped out, etc. The idea is to remove anything that doesn’t need to be there.

You’re not doing a full rebuild. You just want to ensure that the form is actually compatible with how ServiceNow works, so when you want to expose the form through a different channel (Now Assist, Virtual Agent, Mobile) or report on it it’s ready to go.

5. Not governing the catalog items after launch

This happens more than one would want to admit. A catalog item gets built, goes to production everyone high-fives, and then that’s it. Nobody checks back on it. No usage review. No one asks if it’s still needed six months later.

The thing is, that one catalog item becomes ten, then twenty. Before long, your Service Catalog is full of forms that no one touches, with out-dated logic, and variables that don’t even make sense anymore. 

The worst part is no one even remembers who owns what. And when something breaks or needs a change, we waste time getting the answers we need.  

But the kicker is — you have the data, and you can see how often requests get submitted. It’s not hard to identify the ones that are in use and ones that haven’t been touched in a year. And that’s your signal to clean it up, split out, or even retire it.

The best part is you don’t need a big program to fix this. You just need to add a quick check-in, three months after launch, then again at six. Ask the service owner how it’s going, look at the data. It’s a small step that can save you a big headache over time.  Service Catalog governance.

Manage them better with AI in the loop

Most of these issues happen not because people don’t know better, but because platform teams are strapped for time. There’s barely enough time to build, let alone step back and rethink how it should be done.

So people just go with what they know, skip the cleanup and automation. And the technical debt piles up.

But the solution isn’t working harder, but getting time back by using AI smartly.

If you could build a fully tested, documented catalog item in under an hour instead of a full day, what would you do with that extra time? You’d optimize the form. Automate more, and guide the business better.

What if you could ask AI to review your entire Service Catalog and help you understand which ones have the highest usage and deserve more attention to testing?  Which ones are least used?  Which ones have legacy code/logic/variables that should be deactivated to help you reduce technical debt?  

In fact, service owners should use AI to review and improve their forms without needing a dev. And who knows, maybe someday we won’t need forms at all. But until then, AI makes building smarter and a whole lot easier.

Summing up…

Catalog item mistakes might not crash your instance, but they quietly slow everything down.  More than half your backlog is catalog item enhancements, taking your team away from doing more important work. Innovation slows, users are frustrated, , and eventually eat away the trust in the platform.

But all of this is fixable.  Let AI help you get the fundamentals right, quicker than ever.

That means less firefighting. Fewer escalations. And more time to focus on work that actually moves the business forward because that’s what platform teams are primarily here to do.