Pull the order data on a mature ServiceNow service catalog and the distribution is almost always the same. A few items carry nearly all the volume. A long middle tail is ordered occasionally. And a substantial block — frequently a third to a half of everything published — has not been ordered once in the last year.
The instinct is to treat this as housekeeping. It is not. The dead items are what make the live ones hard to find, and being hard to find is the whole ballgame: a portal people cannot navigate is a portal people stop using, and a portal people have stopped using cannot deflect anything.
Three mechanisms that produce sprawl
Creating an item is cheap; retiring one is a decision
Publishing a new catalogue item takes an afternoon and makes somebody happy. Retiring one requires establishing that nobody needs it, finding whoever asked for it, and accepting the small risk of being wrong. The costs are asymmetric and they point one way, so the catalogue only ever grows.
This is not a failure of diligence. It is what happens by default to any collection where addition is delegated and removal is not.
Items get named after systems rather than outcomes
A catalogue written by the teams who fulfil the requests is organised the way those teams are organised. “Request AD group modification.” “SAP access form.” “VPN token request.” Every one of those is accurate and none of them is what the person searching has in their head, which is closer to “I have joined the finance team and cannot open anything.”
The mismatch is invisible to the people who built it, because they know what the items mean. It is the first thing a new joiner hits.
Every exception becomes an item instead of a variable
A request arrives that is almost the standard one but differs in a detail. The fastest route is a new item. Repeat over three years and you have eleven laptop requests differing by region, cost centre and approval chain, where one item with a variable set and a few UI policies would have done — and would have kept its reporting in one place.
What it actually costs
Search stops working first. Relevance ranking degrades as near-duplicates accumulate, so the correct item ranks below three obsolete ones. Users try twice, then revert to email or the phone — and once that habit re-forms it is expensive to reverse, because it worked.
Reporting becomes uninterpretable next. Volume for a business capability is smeared across nine items nobody realised were the same thing, so nobody can answer what the organisation actually asks for most.
Then fulfilment. Dead items with live workflows still route to groups that no longer exist, so the occasional order against one sits unassigned until a human notices.
And every upgrade carries all of it. Regression testing scope is a function of what is published, not of what is used. Organisations regression-test four hundred items every release to protect twelve.
What a good catalogue looks like
Small, and named in the requester’s language rather than the fulfiller’s. The test is whether someone who does not work in IT can find the right item without knowing which team owns it.
Beyond that, four structural habits do most of the work:
- One item per outcome, variables for the differences. If two items share a fulfilment process and differ only in inputs, they are one item.
- Variable sets for anything repeated. Cost centre, location, manager approval — defined once, reused, changed in one place.
- Record producers where the thing being created is a record, not an order. A request to log a facilities issue is not a purchase, and modelling it as one adds a request and a request item nobody will ever look at.
- Order guides for genuinely composite events — onboarding being the obvious one — instead of asking the requester to assemble eight items in the right sequence themselves.
A pruning method that survives contact
The reason most catalogue cleanups stall is that they begin with a workshop. This order avoids that.
- Start with order data, not opinion. Pull every published item with its order count for the last twelve months. This takes minutes and it is the only part of the exercise nobody can argue with.
- Split the zero-order list from the low-order list. They get different treatment. Zero orders in twelve months is a candidate for retirement. Low but non-zero is a candidate for merging.
- Give each zero-order item an owner and a deadline. Not a committee — a named person, with a stated date after which the item is retired. Silence is consent. Without that default, the list is still open a year later.
- Retire, do not hide. Unpublishing leaves the workflow, variables and reporting artefacts in place, so the maintenance burden stays and the next upgrade still tests it. If it is dead, retire it properly and keep the record.
- Merge the near-duplicates last, because merging is real design work and doing it before the retirement pass means designing around items that should not exist.
Expect the number of published items to fall by a third to a half. Expect somebody to object to exactly one retirement, and expect that to be recoverable in an afternoon.
The governance question underneath
A cleanup without a change to who may publish an item is a cleanup you will repeat in two years. The mechanism that produced four hundred items is still running.
What breaks the cycle is unglamorous: a named catalogue owner, a rule that a new item must state which existing item it is not, and a standing review of zero-order items on a cadence rather than a project. None of that is technically interesting. It is the difference between a catalogue that stays usable and one that has to be rescued periodically.
The finding people do not enjoy
On a lot of instances the honest conclusion is that the catalogue does not need more items, more automation or a portal redesign. It needs to be roughly half its current size and written in different words.
That is a cheaper finding than a portal project, which is precisely why it tends not to be the recommendation on offer.