SKU and Product-Version Control for Growing Stores

From the operations archive

Two almost-identical variants became a dispatch risk

Several product stories in one week exposed the same weakness. An apparel concept was changing through samples, remaining textile stock belonged to a range being wound down, and repeated device damage suggested that one batch or configuration needed to be isolated. Marketing names alone could not distinguish what was approved, sellable, obsolete or under investigation.

The risk grows quietly. A new supplier photo can look close enough to the current listing; an internal shorthand can refer to two finishes; replacement stock can sit beside the affected batch. The store keeps selling one option while the warehouse sees several physical versions. Without a stable SKU and version record, the wrong unit can be dispatched perfectly efficiently.

The team separated product identity from product status. Each customer-ready version needed one code, a matching reference image or specification, batch or receipt context, and explicit states such as sample, approved, sellable, held or retired. That did not make the catalogue prettier. It made changes recoverable and allowed growth without asking the longest-serving operator to remember every exception.

Reality check: This is a privacy-safe composite drawn from reviewed operations conversations. Markets and product families are broadened, and identifying details are removed. Read the dated field note: Custom dresses, a flags business winding down, and a run of cracked screens.

A product name is not a reliable warehouse identity

The store may use a customer-friendly name, a supplier may use a factory code, and the warehouse may recognise a photo or translated nickname. That can work for a handful of orders. It becomes dangerous when products have similar colours, sizes, generations or packaging.

A SKU should identify one inventory-controlled variant. Shopify recommends a unique SKU for each product and variant and warns that duplicates can disrupt integrations and tracking. The code does not need to describe everything, but it must be unique, stable and readable by the people and systems using it.

Build one product record around the SKU

Store product and variant names.
Supplier and supplier item reference.
Approved actual photo and specification version.
Colour, size, material, compatibility and included components.
Barcode or GTIN where used, plus warehouse location.
Packaging, QC and route restrictions.

Keep aliases as searchable references, not competing identities. If the supplier changes its name, the warehouse SKU should not change unless the physical product version must also change.

Know when a change needs a new version

A spelling correction is not a product change. A new material, formulation, size, function, pack quantity or customer-visible promise may be. GS1's GTIN rules ask whether customers or supply-chain partners need to distinguish the changed product and whether the change materially affects disclosure or handling. That is a useful test even for sellers not yet using GTINs.

Choose the right control

Metadata update: same physical item; improve the record without creating a new SKU.
Revision: controlled change that must be recorded but can share a commercial listing under a clear transition plan.
New SKU: the variants must be stocked, picked, sold or supported separately.
New customer listing: the change alters what the customer is choosing or what must be disclosed.

Plan the changeover

Before the new version arrives, count old stock, decide whether versions may be mixed, and define which orders receive which version. Update actual photos, specifications, QC references and customer information before releasing the new stock. If old and new versions look alike, a temporary location or label separation can prevent accidental mixing.

Reconcile physical and system truth

Run cycle counts by SKU and record the reason for adjustments. Separate sellable, committed, incoming, damaged and held stock. A correct total across the catalogue is not useful if one high-demand colour is wrong.

Give every sellable version one shared identity

A SKU answers "which physical variant?" A version record answers "which approved state of that variant?" Growing stores need both, tied to the same evidence.

Operating rule: Give every customer-ready version one stable SKU, an approved reference and an explicit state such as sample, sellable, held or retired. Keep old and new batches distinguishable; growth should not depend on one operator remembering which similar-looking unit the listing means.