Configurable Products, Complex Catalogues: Modelling Industrial Products for Online Sales
Most eCommerce platforms were designed with a retail catalogue in mind: a few thousand products, each with a handful of options like size and colour, arranged in one tidy category tree. Industrial catalogues do not look like that. A single pneumatic cylinder family can legitimately expand into thousands of orderable variants across bore, stroke, port thread, seal material and cushioning options. Cable is sold by the metre, fasteners by the box of two hundred, gaskets in pack multiples. Buyers do not browse by product name; they filter by operating pressure and thread standard. And the same physical product may be certified, stocked and sellable in one market but not another.
When manufacturers take these catalogues online without rethinking the data model, the failure is predictable: unusable search, wrong-variant orders, a catalogue nobody can maintain, and a webstore the sales team quietly tells customers to ignore. Complex product catalogue eCommerce is, at its core, a data modelling problem — and this article is about getting the model right. We will work through the recurring challenges of selling configurable products B2B: variant explosion, units of measure, parametric attributes, customer- and region-specific catalogues, the line between configuration and engineering, and the question of where product data should live. Throughout, we draw on our B2B eCommerce work in the manufacturing and industrial engineering sector, including the global composable web store we built for Norgren.
Where Retail Data Models Fall Over
It is worth being precise about the assumptions a retail-shaped platform makes, because each one fails separately on an industrial catalogue.
The first assumption is that options are few and every combination is sellable. Industrial products have many independent option axes, and most of the combinatorial space is not valid — not manufacturable, not offered, or not certified. The second is that a product is bought as “one each”; industrial goods are sold in lengths, packs, reels and drums, in quantities constrained by pack multiples and minimums. The third is that buyers navigate by category and pick by image and name; engineers select by specification, which demands typed, unit-aware attribute data rather than marketing copy. The fourth is that there is one catalogue; in reality, assortment varies by customer agreement, by region and by channel. A platform that hard-codes these retail assumptions forces you to fight it on all four fronts at once. A data model that acknowledges them makes each one tractable.
The Variant Explosion
Start with the most visible problem: combinatorics. Five option axes with a modest number of choices each can multiply into tens of thousands of theoretical combinations. Enumerate them all as flat SKUs and you get a catalogue that is enormous, mostly invalid, and impossible to maintain. Refuse to enumerate anything and buyers cannot order.
The way through is to distinguish two regimes and model each honestly:
- Enumerated variants make sense where the valid combinations are finite, known and — usually — recognised by the ERP as real part numbers. Here the parent product defines the option axes once, valid combinations are generated or imported from the part master, and each child variant carries its own orderable part number, its own stock identity and its own attribute values where they differ.
- Configured combinations make sense where the space is effectively unbounded — cut lengths, custom strokes, option codes that compose into a built-to-order specification. Here you do not pretend every combination is a pre-existing SKU. Instead the product carries option logic and constraints, the buyer’s selections are validated against them, and the outcome resolves to an orderable identity the back office understands, typically a composed part number or a configuration attached to the order line.
Two disciplines matter in both regimes. First, the part number is the contract: whatever the buyer configures must resolve to something the ERP recognises and can promise, or the order dies at handover. Second, define option logic once at the product-family level rather than hand-maintaining thousands of children. When a seal material is discontinued, that should be one change to the family’s constraints, not a spreadsheet exercise across four thousand SKUs. The maintainability of the variant model, more than its initial correctness, determines whether the catalogue is still trustworthy two years after launch.
Units of Measure and Pack Quantities
Units of measure look like a footnote and behave like a landmine. Industrial products routinely have a base unit in which stock is held, a sales unit in which customers order, and packaging levels in between: cable stocked in metres but sold in 50-metre reels or cut lengths, fittings stocked individually but sold in boxes of ten, chemicals in drums and IBCs. Orders are constrained by minimum quantities and pack multiples, and quantities must round correctly against them.
The modelling rules are unglamorous but firm. Every quantity in the system carries its unit explicitly — a bare number is a defect waiting to happen. Conversions between base and sales units are defined per product, not assumed globally. The webstore presents the unit the buyer thinks in (“sold in packs of 10 — you are ordering 3 packs, 30 pieces”) while transacting in terms the ERP will accept, because the ERP’s unit definitions are the ones that govern picking, despatch and invoicing. Ambiguity here produces the most corrosive class of eCommerce failure: orders that are technically valid and commercially wrong, discovered at goods-in by an annoyed customer.
Parametric Attributes: The Search Your Buyers Actually Do
An engineer specifying a component does not search the way a consumer shops. They arrive with constraints — flow rate, operating pressure, temperature range, IP rating, body material, thread standard — and want to filter the catalogue down to the products that satisfy all of them. This is parametric search, it is the native buying behaviour of the industrial customer, and it is only as good as the attribute data underneath it.
That puts hard requirements on the attribute model. Attributes must be typed (numeric, range, enumerated, boolean), unit-aware (a 10 bar rating must compare correctly against a filter set in bar, however the source data was keyed), and governed by controlled vocabularies — if the same thread is recorded as “M5”, “5mm metric” and “metric 5” across three product families, faceting is broken no matter how good the search engine is. Range attributes deserve first-class treatment: an operating temperature of −20°C to +80°C should match a query for “must work at −10°C”, which simple text tagging cannot do. And the technical artefacts engineers expect — datasheets, CAD models, certificates, dimensional drawings — belong in the model as structured product assets, not as attachments scattered across a file share.
None of this is a search-engine feature you can buy your way out of; the engine can only facet what the data supports. In our experience the attribute-governance work is the single biggest effort item in an industrial catalogue programme — and the single biggest determinant of whether engineers adopt the store, because a parametric search that returns wrong or incomplete results is worse than none.
One Product Pool, Many Catalogues
The retail assumption of one catalogue for everyone fails quickly in industrial commerce. Key accounts have contracted assortments and approved-product lists. Distributors see a different range from direct customers. Regional availability differs for supply-chain reasons, and certification differs for regulatory ones — the variant sold into one market may be a physically different certified product from its equivalent elsewhere, and showing a buyer a product they cannot legally or practically be supplied with is worse than hiding it.
The modelling consequence is a clean separation between the product pool — every product and variant you can supply, enriched once — and the catalogues published from it: per region, per channel, per customer segment, each a filtered, priced view of the same underlying data. Assortment then becomes configuration rather than duplication, and a certification change in one market is a change to one catalogue’s rules, not a parallel product record to keep in sync. This same structure is what makes customer-specific experiences possible downstream — we have written separately about self-service buyer portals with Elastic Path, which lean heavily on per-customer catalogues, and about subscription and recurring-revenue commerce for the consumables in those assortments that customers buy on a cadence.
Stocked, Configured or Engineered: What Belongs in the Webstore
Not everything in an industrial range belongs in a buy-now journey, and pretending otherwise is a common failure. It helps to be explicit about three classes of product:
- Stocked standard items — enumerated variants with stock and lead times. These belong fully in the webstore: browse, filter, order.
- Configured-to-order items — valid combinations within defined option logic, built on demand. These can and should still be self-service: a configurator that enforces the constraints, resolves to an orderable identity and sets lead-time expectations honestly. This is where the online catalogue earns its keep, because configuration errors are precisely what phone-and-email ordering handles badly.
- Engineered-to-order items — anything requiring drawings, application engineering or commercial review. These belong in a quote workflow, not a basket. The store’s job is to capture the requirement in structured form and route it, keeping the interaction inside the same account context rather than dumping the buyer to a generic contact form.
The boundary between these classes is commercial, not technical, and it moves: configurations that prove popular graduate into stocked variants, and products once quoted by engineers become configurable as their option logic is codified. The data model should make those promotions cheap — which is another argument for defining option logic at the family level rather than baking assumptions about a product’s class into the platform.
Where Product Data Should Live: The PIM/Commerce Split
Behind every complex catalogue sits a governance question that outlasts any platform choice: which system owns which product data? Three systems compete for the job, and the durable answer gives each a distinct role.
The ERP owns existence and logistics identity: the part master, units of measure, stock and supply data. It likewise remains the authority on pricing — a subject with enough depth that we will not attempt it here. The PIM (product information management system) owns descriptive truth: engineering attributes, controlled vocabularies, translations, media and datasheets, and the relationships between products — enriched once, published everywhere the business sells. The commerce platform owns the sellable view: catalogues and assortments, navigation hierarchies, the option logic buyers configure against, and the transactional surface of carts and orders.
Two anti-patterns account for most of the pain we see. The first is enriching product data in the commerce platform because it was the system at hand — attributes and translations accumulate where only the webstore can use them, and the next channel starts from zero. The second is wiring the storefront to query the PIM (or worse, the ERP) live, coupling customer-facing latency and availability to back-office systems that were never designed for it. The sound pattern is publication: data flows from ERP and PIM into the commerce platform through deliberate, versioned pipelines, so the storefront serves from its own fast, sellable model. If you do not yet have a PIM, a capable commerce product model can carry enrichment for a while — but recognise the tipping point (multiple channels, multiple languages, attribute governance beyond a single team) at which extraction becomes far more expensive than adoption would have been.
Making these systems behave as one coherent whole is systems integration work, and it is where industrial catalogue programmes are won or lost. It is also well-trodden ground for us: for IMI Precision Engineering we built the Digital Edge Platform, a cloud-based integration platform that flows information between IMI’s deliberately best-of-breed systems to give staff a single, current view of the truth. The same principle — let each system do what it is best at, and invest in the connective tissue — is exactly how a PIM, an ERP and a commerce platform should coexist, and we have explored the commerce-specific patterns in our article on connecting Elastic Path to your back office.
How Elastic Path Models Complex Catalogues
Everything above is platform-independent, but the platform still has to carry it, and this is where Elastic Path has served our manufacturing clients well. Its product model supports parent products whose variation options generate child variants — the enumerated-variant regime — while custom fields extend products and variants with the typed engineering attributes parametric search depends on. Bundles model kits and composed offerings. Crucially, hierarchies and catalogues are decoupled from the product pool: the same products can be organised into multiple navigation structures and published as multiple catalogues for different regions, channels and customer segments, which is precisely the one-pool-many-catalogues shape described above. And because it is API-first, it composes cleanly with a dedicated search service for parametric filtering and with the integration pipelines that feed it from PIM and ERP — Elastic Path product modelling provides the sellable core rather than trying to be every system at once.
That composability is not hypothetical. For Norgren, a brand of IMI Precision Engineering with a long-established global eCommerce presence, we replaced a bespoke, externally maintained web store with a composable store built on Elastic Path and other off-the-shelf cloud services for search, navigation and geo-location. The composable approach lowered the cost of ownership and removed single points of failure, lifted the Google Lighthouse score to 100% at launch, and — most relevantly here — freed development effort to focus on innovative features such as product configurators rather than on maintaining platform plumbing. For a business selling precision engineering components in volume across global markets, the catalogue model was not an implementation detail; it was the product.
How McKenna Consultants Can Help
McKenna Consultants has over 25 years of software engineering experience with manufacturers and industrial engineering businesses, and complex catalogue work sits at the centre of our B2B eCommerce practice. We built Norgren’s global composable Elastic Path store and IMI Precision Engineering’s Digital Edge integration platform, so we have worked both sides of the problem this article describes: the product model buyers experience, and the data flows that keep it true.
If your catalogue has outgrown your platform — variants nobody can maintain, attributes too inconsistent to filter on, or a webstore that cannot represent what you actually sell — we can help you design the product model, the PIM/commerce split and the integrations to fix it properly. Get in touch to discuss your catalogue.
