Replicating NCR’s automatic category assignment

NCR Retail Online connected ecommerce catalogues with operational data held in retail management systems, including stock, pricing and product records. Its discontinuation changes the platform, not the underlying business requirement: Australian retailers still need products to land in the correct category, carry the right attributes and remain accurately represented when an order moves between the website, inventory and fulfilment systems.

Replicating NCR’s automatic category assignment based on product attributes means translating product signals—brand, model, material, size, pack quantity, ingredients, dimensions and compatibility—into consistent store categories. The aim is not to guess from a product title alone. It is to reproduce a repeatable result that merchandisers can explain, audit and improve as the catalogue changes.

For an Australian store, this work touches more than navigation. A Sydney warehouse and a Melbourne click-and-collect store may draw from the same inventory, while AUD prices must include 10% GST. Product records also need to support Australian Consumer Law returns, couriers serving regional areas and catalogues sold through local marketplaces such as Woolworths or Coles where relevant.

Many NCR Counterpoint customers are moving to Magento or WooCommerce with an NCR Counterpoint partner. The replacement should therefore separate category logic from the commerce platform, preserve product identifiers and attributes, and expose unmatched or conflicting records for human review. That structure reduces migration risk while giving the new team control over automated classification.

What the replacement must preserve

A useful specification begins with observable outcomes rather than assumptions about NCR’s internal implementation. Compare the operating models that could reproduce its category-assignment behaviour and identify the balance between speed, control and maintenance that fits the retailer.

The preferred pattern is usually scored rules with human oversight. It combines the consistency of automation with an escape route for unfamiliar products, incomplete records and conflicting attributes. A retailer can also start with rules-only processing, then introduce confidence thresholds once it has enough reviewed examples.

Whichever model is selected, each assignment should retain its source attribute values, rule version, destination category, timestamp and resulting confidence. Those details allow a merchandiser in Brisbane to understand why a product received a particular category without asking a colleague to reconstruct the decision from memory.

Model attributes before assigning categories

Product data should be normalised before classification begins. Separate stable identifiers, descriptive attributes and merchandising attributes, then retain the source and original value beside every normalised field. This prevents a migration script from replacing a carefully structured value with an inconsistent free-text entry.

Attribute coverage will vary by department. Apparel may rely on fibre content, garment size and colour, while electronics need manufacturer, model, connectivity and voltage. Grocery products may require ingredients, allergen declarations, net quantity and storage conditions. The taxonomy should also distinguish a pack of six from a single unit, because Australian shoppers and retailers often use pack quantity to compare products and pricing.

Imported stock requires additional care. Country of origin, tariff classification and Australian Customs information can affect landed cost and border treatment, but they should not be confused with the ecommerce category. A product might belong to “Small Appliances” while carrying a separate HS classification for customs purposes. Keeping those dimensions independent prevents one change from silently rewriting another.

Define the expected category, eligible attributes, permitted values and conflict priority for every department before importing rules. Field names such as “colour”, “product type” and “pack size” then need shared definitions across Counterpoint, Magento, WooCommerce and any warehouse or marketplace feed.

Build a deterministic classification pipeline

A practical pipeline generates candidate categories, applies category-specific rules, resolves conflicts and records the final decision. Candidate generation narrows a large taxonomy using broad signals such as department or product family. Detailed rules then test attributes that distinguish sibling categories, reducing both false matches and unnecessary processing.

Rules should be ordered and explicit. For example, an electronics rule might require manufacturer, model and connectivity before choosing between televisions and computer monitors. A grocery rule might identify a 500 ml package before selecting milk, while a bakery rule could use product type and ingredients to distinguish bread from a prepared dessert. Ties require a documented tie-breaker, not whichever rule happened to run last.

Confidence scores should reflect documented conditions rather than an opaque model. “High” might mean that every mandatory attribute matched and no rule conflict occurred. “Medium” could indicate a valid match with one non-critical attribute missing, while “low” should send the record to a review queue. Thresholds can then be tested against known catalogue examples before they affect live storefront navigation.

The discipline is similar to the precision described in a satellite dish alignment guide: one misaligned input can weaken the whole result. Every signal therefore needs a documented role, reliable source and controlled set of values before bulk classification begins.

Migrate data without losing catalogue meaning

Export product identifiers, attributes, current category paths and stock information from Counterpoint before changing platforms. Keep the old category identifiers in a cross-reference that maps them to Magento or WooCommerce category IDs. This preserves a traceable route back to the original catalogue and supports reconciliation after each batch is processed.

The migrated category tree should reflect how the new storefront is organised, not merely copy an old structure. Review breadcrumbs, search terms and URL changes at the same time, since a technically correct category can still be difficult for customers to navigate. Feed mappings should then be tested against warehouse, ERP and marketplace requirements to prevent inconsistent product presentation.

Store teams also need clear ownership for catalogue exceptions. The staff transition checklist can support decisions about who reviews ambiguous classifications, who approves rule changes and who receives operational alerts. Assigning these responsibilities before launch prevents the migration from depending on one experienced merchandiser.

Measure results and improve controlled exceptions

Monitor the quality of category assignments rather than treating a completed migration as the finish line. Track manual-review rates, unmatched products, changes to category paths, search exits and stock-feed errors. A rising exception count may indicate that a rule has become outdated, while a sudden drop can reveal that products are being assigned too broadly.

Returns provide useful evidence about catalogue quality. The refund and returns workflow shows why SKU, category and return-reason data must continue flowing between the store and operational systems. Patterns such as frequent “wrong item” returns can reveal ambiguous attributes that should feed back into classification rules.

Keep a versioned record of every rule and reviewed correction so later changes can be compared with earlier results. Release improvements through a small test batch, measure their effect and promote them only after a named reviewer signs off. The first controlled step is a pilot sheet containing 25 representative SKUs, their agreed attributes, expected categories and one assigned reviewer.