Five hundred products, and the five that mattered

A catalog I went through recently held five hundred and thirty-eight products. The renewal book sitting on top of it — around four hundred live agreements — used five of them. Not five families. Five records.

The other five hundred and thirty-three aren't clutter exactly. They're one modelling decision, made early, probably by somebody solving a real problem that afternoon, and then copied forward into every quote, contract and invoice the business has issued since. That's the part worth pulling on, because it's the part that generalises.

A line item is a copy, not a link

Here's the mechanic that makes a product library different from the rest of your configuration. When a product goes onto a quote, the system takes a snapshot of it — name, description, price, billing rhythm — and that snapshot is what travels forward. Change the product tomorrow and yesterday's quote doesn't move. It isn't pointing at the product any more. It's a copy.

On a contract the copy then locks. There's no editing a line item after the fact. If the price was wrong, or the name reads badly on an invoice, or the frequency says monthly on an annual agreement, the remedy isn't an edit — it's terminating the agreement and building it again.

Six decisions do most of the work. Each is easy to make casually and expensive to reverse, because reversing means reissuing paper.

Where does quantity live?

This is the one that shapes everything downstream. You can express eighteen devices two ways: as a product called 18 Devices sold once, or as one product sold eighteen times.

That catalog chose the first. It has a separate product for every device count, one through past a hundred, which is where four hundred and forty-three of its products came from. Each one is a real record with its own price, and the totals all come out right, which is why nobody caught it.

But quantity stops being a number anywhere in the system. It's always one. The count lives inside a name, as text. Operations reads quantity as an instruction — ship this many, provision this many — and gets 1 on every line. Nobody can tell you average devices per customer without parsing product names. There's no per-unit price recorded anywhere, only inferable by dividing. And when a customer grows from eighteen devices to twenty-two, that isn't a quantity change, it's a different product, so this year's agreement can't be compared to last year's.

Everything else in this piece is downstream of getting this one right.

Who reads the product name, and when?

Product names get written by whoever is closest to the catalog, usually so the thing is findable in a picker. That's the wrong audience.

The name is copied onto the quote the buyer reads, and then onto an invoice that lands eleven months later in front of someone in accounts payable who wasn't in the sale, has no context, and is deciding whether this is a real obligation. It's also the string that gets keyed into the customer's own accounting system, where it will sit for years.

Write it for that person. A line reading Diamond Annual, described as a per-device annual network cost, at eighteen units, is something a stranger can verify. The same money as one unit of Diamond | 18 Devices | Annual is a string they can only take on faith. Unrecognisable invoice lines are one of the most reliable causes of slow payment, and the cost isn't really the delay — it's somebody in finance reconstructing what was sold, on every queried line, forever.

Is the price a list price or a final price?

If sellers adjust the price directly, the system records what was charged and loses why. A line reading two thousand three hundred isn't wrong, but a year later nobody can tell you whether that's the standard rate, a negotiated concession or a typo somebody never caught.

The alternative is to hold the product price as a list and express every reduction as a discount against it, so the record carries both numbers and the concession has a shape — list, percentage off, resulting amount. HubSpot has an opinion here that's worth noticing: contract line items accept a percentage discount and reject a flat dollar amount outright. Real concessions are almost always negotiated in dollars, so you convert. It reads as an annoyance and it's actually a design position — the platform wants the discount stored as a relationship to list, not as a different number.

Without a list price there's no discount reporting, no view of margin erosion across a book, and no way to roll a first-year concession off at renewal, because nothing ever recorded what the price would otherwise have been.

Does the product carry its own billing rhythm?

Recurring frequency and billing terms sit on the product and copy onto the line. They look like metadata. They're the engine — they generate the billing schedule, and every recurring revenue figure the business reports is computed from them rather than entered by anyone.

This is the quietest failure in the whole system, because a wrong frequency still produces a correct-looking invoice. An annual agreement mis-set to monthly bills the right amount on the document and reports twelve times the recurring revenue. Nothing on the paper looks wrong. And because the figure is derived, it won't reconcile against anything, so finance ends up maintaining a spreadsheet beside the system — which is how a system stops being trusted.

Where does the term live?

Most teams put contract length in a field on the deal, because that's how people talk about it. Three-year deal. But the system derives term from the recurring line item — specifically how many payments it's set to make. A three-year agreement is three annual payments on the line. That's the fact the billing schedule actually reads.

A text field on a deal saying three years drives nothing, can't be enforced, and will disagree with the line item inside a quarter. The reverse case is worth stating too: a line left to renew automatically with no payment count is saying something specific and true — this runs until somebody cancels it. Evergreen agreements are routinely invisible in a CRM precisely because nobody built a field for no end date, and three quarters of the book in this case was exactly that.

Is the catalog governed, or just accumulated?

Sixteen products in that live catalog have TESTING in the name. A handful are priced at zero, including one named for the renewal motion itself. None of that is negligence. It's what happens when a catalog has no owner and adding a product is faster than finding the right one.

The risk isn't that the entries exist, it's that they're selectable. A test product and a real one sit next to each other in the picker separated by a suffix, and the wrong pick copies straight onto something a customer signs. A zero-priced product produces a zero-priced line without complaint, because zero is a valid price. Catalog hygiene isn't housekeeping — every selectable wrong answer is an invoice waiting to go out incorrectly.

Where each decision surfaces

The reason to decide these deliberately is that one product record gets read five times, by five audiences who never speak to each other, and only the first of them has any context.

Quote

The buyer reads name, description, quantity and price, and decides whether the thing described is the thing you discussed. This is the only stage where anyone involved was in the room.

Signature

The line is snapshotted and frozen. Frequency and terms become the billing schedule; the payment count becomes the term. Whatever got approximated on the quote is now the agreement, and this is the last moment a change is cheap.

Invoice

Another copy, in front of somebody matching it against a purchase order and a memory. Name and description are doing all the work, and quantity is what makes the arithmetic checkable.

Fulfilment

Operations reads quantity as an instruction. If the count is text inside a product name, this stage can't be automated at all — somebody opens the agreement and retypes the number into another system.

Renewal and revenue recognition

Finance reads figures nobody entered, derived from frequency and terms. Renewal needs to compare this year's line to last year's, which only works if they're the same product at a different quantity rather than two unrelated records.

How to tell whether you have this

Five checks, none of which takes longer than a query.

• Count the catalog, then count what's actually referenced by live agreements. If the ratio is worse than about ten to one, most of the catalog is modelling debt rather than product.
• Search product names for digits. A number in a name usually means a variant axis — quantity, tier, size — that belongs in a field instead.
• Look for two products that mean the same thing. Suffixes like test, old, new, or a year are the tell.
• Check for zero prices. Every one is a line that can be issued for nothing without anybody being warned.
• Read your own invoice as a stranger. If you can't tell what was bought and check the arithmetic without opening the CRM, neither can the person paying it.

The part I'd want to work on

A product library gets treated as setup — something you do once so quoting can start — and it's really the schema for every commercial statement the business will ever make. The cost of skipping the design pass doesn't show up for a year, and then it shows up everywhere at once, in a form nobody can trace back to the decision that caused it.

Five hundred and thirty-eight products isn't a tidying problem, and cleaning it up isn't the work. The work is deciding what a product is, once, and then making the system state it — so the answer stops depending on which record somebody picks on a Tuesday.