Categorizing Services So People Can Actually Find Them

Why this matters

A great line item hidden in the wrong category might as well not exist. Techs quoting on a doorstep and office staff building an estimate under time pressure both rely on category structure to find what they need fast, and if the structure doesn't match how they actually think about the work, they'll either give up and quote from memory, missing better options, or waste minutes hunting while a customer waits. Category design is invisible when it's done well and a constant source of friction when it isn't, which is exactly why it's easy to under-invest in until the catalog has grown large enough that the friction becomes impossible to ignore.

Categorize by customer problem first, system or trade second

The most common categorization mistake is organizing the catalog the way a technician thinks about the equipment rather than the way a customer describes the problem. A customer doesn't call saying "I need work on my secondary heat exchanger," they call saying "my system isn't heating." Top-level categories that mirror the symptom or the service occasion a customer would actually describe make the catalog navigable for office staff fielding calls and for any customer-facing view of the price book, while subcategories underneath can get as technical as needed for the tech actually doing the work.

The right depth: two levels, rarely three

Most catalogs work best with a category and a subcategory, full stop. A third level of nesting might feel organized on paper, but in practice it adds clicks and cognitive steps between a tech and the line item they need, and the deeper the nesting, the more likely two similar items end up in slightly different branches where nobody thinks to look. If a subcategory is getting large enough that a third level feels necessary, that's usually a sign the subcategory itself should split into two siblings under the same parent, not grow a child level.

Keep the top-level list short enough to memorize

Somewhere around seven to ten top-level categories is the practical ceiling for most trades before techs stop being able to hold the whole structure in their head and start relying purely on search. Once a tech has to search rather than browse, category structure has stopped doing its job, and a search-only catalog puts a lot of pressure on line-item naming picking up the slack. See related: Naming a Service So Customers Understand It. Fewer, broader top-level categories with well-organized subcategories underneath consistently outperform many narrow top-level categories.

One home per service, cross-reference instead of duplicating

A service that seems to belong in two categories should live in one, its primary home, with a cross-reference or tag pointing from the second location rather than a literal duplicate entry. Duplicating a line item across categories to make it easier to find creates a maintenance trap: a price change, a name update, or a retirement now has to happen in two places, and the two copies drift out of sync the first time someone updates only one.

A quick self-check for your current structure

Ask three questions against your live catalog:

• Can a new hire, given only the category names and no other context, correctly guess which category a common job belongs in? If not, your categories are organized around internal logic rather than the customer or job language a new person would reasonably expect.
• Is any category holding more than roughly twenty to thirty line items with no subcategory breakdown underneath it? That's a category overdue for a subcategory split.
• Are there categories with only one or two items in them? Thin categories usually mean over-splitting, consider merging them into a nearby, related category instead of leaving a nearly-empty branch in the structure.

References

• See related: Naming a Service So Customers Understand It
• See related: The Catalog That's Too Complicated vs Too Simple Decision Tree
• See related: Retiring a Dead Service Line From the Catalog