Every trading or manufacturing company has a person who "knows everything about the products". They remember that this particular pipe only fits another manufacturer's fittings, that the paint from the new batch is slightly darker, that this pump model has two connection options and clients keep mixing them up. Meanwhile the accounting system holds the name, the SKU, the price and the stock level. Everything else lives in that person's head. While they are around, the company works. When they go on vacation, the returns, mix-ups and calls from angry clients begin. I call this the thin product card disease, and I run into it in almost every project.
Why typical systems describe products so poorly
A typical accounting system is designed for an average company that does not exist. It has fields common to everyone: name, unit of measure, price, barcode. That is reasonable, because the system vendor cannot know in advance what You sell. But in a real business, products are very different. Clothing has size, height, fabric composition and season. Electronics have voltage, power, connectors and compatibility. Building materials have strength class, grain size and consumption per square meter. Try to cram all of that into a single "Description" field, and a year later You will have a dump of text that cannot be searched, filtered or reported on.
Companies usually get out of this in one of two ways, and both are bad. The first: they ask developers to add twenty more columns to the database for specific characteristics. Six months later a new product category appears and twenty more are needed. The table grows to a hundred fields, most of which are empty for any given product. The second: they keep characteristics in a separate Excel spreadsheet next to the system. That works exactly until the first version mismatch, and the mismatch arrives on roughly the second day.
A form builder: characteristics as data, not as code
The right solution has been known for a long time, and it is elegant: product characteristics should not be part of the database structure, but data that the business configures itself. That is what a form builder is. An assortment manager, not a programmer, creates a set of fields for a product group: "Size" with a list of values, "Power" as a number with a unit, "Compatibility" as a link to other products. Each group gets its own card, its own input form, its own filters. A new product category no longer requires development, it requires ten minutes of configuration.
I like to compare this with a library. You can print a catalog card with fixed fields "author, title, year" and force the librarian to write everything else on the back in tiny handwriting. Or You can let them decide what matters for each section: scale and region for maps, instrument and key for sheet music, issue number for magazines. The library does not become more complicated. It becomes more precise.
An accounting system in which You cannot describe Your product the way Your clients understand it is not tracking the product, but its shadow.
What a detailed description gives the business
The first effect is visible in the warehouse and in sales right away: fewer picking errors. When a product has structured characteristics, a manager does not search from memory but filters: we need a pump of such and such power with such and such connection, here are three matching items, here is their stock. Mix-ups and returns go down, because knowledge stops depending on a single person.
The second effect: quality product cards for online stores and marketplaces. Platforms demand more and more attributes, and if they already exist in the accounting system, the export becomes a technical operation instead of a week of manual filling. A shopper on the website sees filters based on real characteristics and finds the product, instead of leaving for a competitor who has filters.
The third effect, which people rarely think about in advance: analytics. When characteristics are stored as data, You can answer questions that used to require manual digging. Which sizes sell better in which season. Which parameters people search for most often and do not find. Which characteristics account for most of our returns. This is no longer accounting, it is assortment management.
Pitfalls worth knowing about
Flexibility has a price, and it would be dishonest to keep quiet about it. A form builder easily turns into chaos if there are no agreed rules. If every manager creates fields as they please, a year later the system will contain "Color", "product color", "Colour" and "Shade", and all four will mean the same thing. That is why configuring characteristics should be in the hands of one responsible person, and values should be chosen from reference lists whenever possible rather than typed as free text.
The second pitfall is technical: storing arbitrary characteristics requires a well-thought-out database structure, otherwise search and reports will start to slow down at tens of thousands of products. It is a solvable problem, but it has to be solved architecturally from the start, not patched once the warehouse has already grown.
What to do tomorrow
Take the five most problematic product groups, the ones with the most errors and returns. Ask that very person who "knows everything" which three to five characteristics really matter for correct selection in each group. Write them down. Most likely You will be surprised how short the list turns out to be and how many problems it solves.
In Forma, our ERP platform, the products section works exactly this way: custom fields and value reference lists are configured for products, there are categories, types, packaging units and SKU generation, and the warehouse and sales work with this data directly. If a company has a special subject area, at Systems we design a product model for it, and Fractal generates the structure and interface from a description. But in any case the first step is the same: get the knowledge about products out of one person's head and into a system where it works for everyone.
