Retiring a Dead Service Line From the Catalog

Why this matters

Every catalog accumulates dead weight over time: services that made sense when they were added but haven't sold in a year, items superseded by a better version, one-off entries created for a single customer that never should have gone into the shared catalog at all. Left alone, dead lines don't just sit quietly, they slow down every tech who scrolls past them looking for what they actually need, and they create confusion when a customer finds an old line item online or on a past invoice and asks why it's not available. A catalog that's never pruned eventually becomes harder to navigate than one with real gaps in it, because clutter is its own kind of gap. Retiring dead lines on a regular cadence keeps the catalog working for the people who use it every day.

Step 1: pull twelve to twenty-four months of sales data by line item

Before retiring anything, get the facts. Export every catalog line item with its sell count and last-sold date over the past one to two years. A single year can hide a genuinely seasonal item that only sells in one window, so lean toward two years of data when you can, especially for anything tied to a seasonal rotation. See related: Rotating a Seasonal Service Menu.

Step 2: sort candidates into three buckets, not one

Resist the urge to treat "hasn't sold" as a single category. Split it:

• Zero sales, ever. Items added to the catalog that have never once been booked. These are the safest and fastest to remove, there's no customer history to preserve.
• Sold before, but not recently. Items with real sales history that have gone quiet. These need a reason before you cut them, not just a stale date.
• Superseded. Items that were replaced by a newer, better-structured line item covering the same job, often left behind after a catalog restructure. These should be merged into the item that replaced them, not just deleted.

Step 3: find the reason before you cut, for the "sold before" bucket

A line item that used to sell and stopped usually has a specific cause, and the cause tells you whether to retire it or fix it:

• The underlying need went away (a code change, a shift in typical equipment, a seasonal trend that faded) - retire it.
• A better option exists elsewhere in the catalog now and customers or techs have naturally migrated to it - merge or retire, and make sure the replacement is easy to find.
• It's still needed but poorly named, poorly priced, or buried in the wrong category - this isn't a retirement candidate, it's a repair job. See related: Naming a Service So Customers Understand It and Categorizing Services So People Can Actually Find Them.

Don't retire an item just because it's slow if the underlying need is still real, fix the visibility or pricing problem instead.

Step 4: check for dependencies before removing anything

A line item slated for retirement might be referenced inside a bundle, a flat-rate tier, a recurring service agreement, or an active job template. Check all of these before deleting, removing a component out from under an active bundle or template silently breaks it for the next person who uses it. Where a dependency exists, update or retire the parent structure first.

Step 5: don't delete, deactivate

Wherever your system supports it, deactivate or archive a retired line item rather than hard-deleting it. Historical invoices and past jobs reference the item, and deleting it outright can break reporting or leave old records pointing at nothing. Deactivation removes it from the active catalog a tech browses while preserving the history behind it.

Step 6: communicate the change to the team

A line item disappearing from the catalog with no explanation reads as a system glitch to a tech who was used to finding it there. A short note, what was removed, what replaced it if anything, keeps the team from re-adding a duplicate out of confusion a month later.

Step 7: put retirement on a recurring calendar

Treat catalog pruning as a scheduled task, at minimum once a year, ideally aligned with your seasonal rotation review if you run one. A catalog that's only cleaned up reactively, when someone finally complains it's too cluttered, accumulates enough dead weight between cleanups that the audit becomes a much bigger project than it needed to be.

References

• See related: Rotating a Seasonal Service Menu
• See related: Categorizing Services So People Can Actually Find Them
• See related: The Catalog That's Too Complicated vs Too Simple Decision Tree