Product Variants Done Right: Sizes, Colors, and Flavors
One t-shirt in five sizes and four colors is 20 SKUs. How to structure variant codes, use a product matrix, and read reports so variants stay manageable.
A t-shirt shop sells one design. Just one. But that design comes in five sizes and four colors — and suddenly “one product” is twenty different items, each of which can sell out, pile up, or get shipped wrong. Multiply by thirty designs and you are managing six hundred combinations.
This is where stock records quietly fall apart. Not because there are too many goods — because the variants were recorded half-heartedly.
The original sin: tracking at the wrong level
Two classic mistakes, pulling in opposite directions.
Too coarse: stock tracked per design only. “Dragon Tee: 47 pcs.” The number is true and useless. Nobody shops for “a dragon tee” — they want the dragon tee in black, size L. And black L may have been gone for two weeks while white XL sits fifteen deep.
Too wild: every variant entered as a free-floating product with an improvised name. “Dragon Tee L Black”, “T-shirt Dragon Black (L)”, “dragon blk L”. Three entries, one item. Sales reports per design become impossible, and the cashier just picks whichever entry appears first.
The rule: stock and sales are recorded at the variant (SKU) level, but every variant lives under one parent product. Two levels, two jobs. The SKU level answers “which exact one is out of stock”; the parent level answers “which design is actually selling”.
Designing SKU codes you will not regret
Good variant codes are boring and consistent. A common pattern: PRODUCT-CODE followed by attributes in a fixed order — DRGN-BLK-L, DRGN-BLK-XL, DRGN-WHT-M. The one non-negotiable: never swap the attribute order. If color comes before size, it comes before size on every product, forever.
Traps that surface later:
- Avoid abbreviations that look alike; two color codes one letter apart will be misread at the worst moment.
- Never bake a price or anything changeable into the code.
- If items carry manufacturer barcodes, scan those at the register — your internal SKU still exists as the identity in reports.
For flavor-based businesses (frozen food, powdered drinks), the attributes are flavor and pack size instead of size and color: BOBA-CHOC-1KG, BOBA-TARO-500G. Same principle.
The matrix: the sane way to create and read variants
Entering twenty combinations one by one is tedious and error-prone. An inventory system that understands variants gives you a matrix: define the parent, list the sizes, list the colors, and the system generates every combination with its SKU. Some combination not sold — say XXL only exists in black? Switch that cell off.
The matrix is also the best way to read stock. A size-by-color grid shows at a glance that M and L are nearly gone in every color while XS has never moved — a pattern invisible in a six-hundred-row list.
In Tenavora, variant products follow this parent-and-variant pattern, and each variant can carry its own price and barcode — the jumbo size can cost more without becoming a separate product.
Reports: two lenses, worn alternately
Lens one, parent level: which designs or products moved this month. This drives production and purchasing — which design gets reprinted, which flavor gets retired.
Lens two, variant level: inside a winning design, which sizes and colors actually carry the sales. Interesting patterns live here. Apparel stores typically discover a stable size curve — say M and L delivering 60% of units — and that curve becomes the template for the next purchase. Buying flat across all sizes almost always ends as a discounted pile of XS and XXL. If that pile already exists, it is time to sort priorities with ABC analysis — and to recompute reorder points per variant, never per design.
A note for multi-channel sellers: use the same variant SKU in your physical store, marketplaces, and web store. Once the codes match, stock for every channel can flow from a single source — and the “it still shows available online but we sold the last one yesterday” drama mostly disappears.
If your variants are currently a mixed bag, set aside one afternoon: merge the duplicate entries, fix the code pattern, re-enter through a matrix. You lose the afternoon. In exchange, every report after that can finally be trusted — and “do we still have it in L?” stops requiring a walk to the shelf.