Why an SKU should not be marketing copy

An SKU is an item reference. A product name helps customers understand what is being sold. These two functions do not need identical text. If codes change with every renaming or campaign, references between the catalogue, orders and other systems become harder to follow. Choose stable codes and manage changes deliberately.

Separate recognition by people from identification between systems

Visitors benefit from a clear product title with relevant characteristics. A system mainly needs an unambiguous reference. An SKU may contain recognisable elements, but need not tell the product's entire story. Long marketing names in codes give later wording changes unnecessary technical significance.

The WooCommerce's product management guide describes SKUs as part of product data and identifies separate data for variations. Decide at which level a sellable variant is identifiedin your catalogue. This requires coordination with administration and any source data.

Set rules for new and discontinued items

In a fictional shop, a lamp is renamed to explain its intended use more clearly. The physical item and its specification remain unchanged. A new title therefore need not automatically mean a new item code. A substantially different variant, however, may need its own reference even if the commercial name stays almost identical.

Define which changes represent a new item. Use examples from your own range: different packaging, a changed component, a successor model or simply a text correction. Let the content owner determine these distinctions. The website administrator should not have to infer that decision from a word that happens to have changed.

A discontinued code may still appear in old orders, documents or external systems. Do not quietly reuse it for another product. Record its relationship to any successor separately. This keeps it possible to explain which item was originally intended.

Check the relationship with integrated systems

For a WooCommerce–AFAS integration it must be clear which field establishes the item relationship and who manages the item code in the source system. The visible online store name can be adapted for presentation while the administrative reference remains stable. Make that division of responsibility explicit before entering large numbers of products.

During an import, check how empty, duplicate or changed codes are handled. A file that looks logical to an editor may be ambiguous to an integration. Use a small trial dataset and compare the results in both systems. Code changes require more care than correcting a product description.

Also consider handover to people discussing an item by phone. A stable code can help distinguish two variants with almost identical names. Make clear where staff can find the code and which parts have meaning. Treat this practical recognisability as an additional requirement without trying to encode the entire commercial description.

Give staff a practical decision framework

  • Is this the same sellable item or a new variant?
  • Which existing code belongs to it?
  • Which system determines the official reference?
  • Where is the code already used?
  • How will a necessary change be checked and recorded?

Use these questions for new products and catalogue clean-up. Add one well-developed example to the administration guide. In online store development this helps keep product entry and integration connected.

A well-managed SKU structure does not promise error-free administration. It does prevent editorial preferences from unintentionally changing item identities. Customers get clear names, staff retain recognisable references and future changes can be assessed against the item's actual meaning.

Previous insight
Next insight

Start with your question

Where does your team get stuck?

Your first enquiry does not need to be a technical brief. Tell us which systems you use and where work gets stuck. Together we discuss what is possible and which step you can take next.

Discuss my project