The Back Office Is Not a Product Repository
Every e-commerce platform has a product management section in its back office. You can create products, add descriptions, upload images, set prices, and assign categories. It works. For a catalogue of fifty products, it works fine.
For an enterprise with thousands of SKUs, dozens of attributes per product, multiple languages, multiple sales channels, and regulatory requirements for product data accuracy – it breaks down.
The commerce back office was designed to sell products, not to govern product information. These are fundamentally different jobs, and conflating them creates problems that compound as your catalogue grows.
What Goes Wrong
Data Duplication
When the commerce back office is the primary source of product data, every channel that needs product information must either pull from the commerce system or maintain its own copy. Your website, your marketplace listings, your printed catalogues, your sales team’s product sheets, your ERP – each one needs product data, and each one either depends on the commerce backend or creates its own version.
The result is inevitable: inconsistencies. The product description on your website says one thing. The marketplace listing says another. The printed catalogue has last quarter’s specifications. The sales team is quoting features that were changed two releases ago.
Workflow Gaps
Enterprise product data requires governance. New products need to be reviewed and approved before publication. Attribute changes need validation against regulatory requirements. Translations need quality review. Images need brand compliance checks.
Commerce back offices have rudimentary workflow capabilities at best. Products are either published or not. There is no concept of a review stage, an approval gate, or a role-based validation step. For organisations operating in regulated industries – manufacturing, pharmaceuticals, food and beverage – this absence of governance is a compliance risk.
Attribute Model Limitations
Commerce platforms impose their own data model on products. The attributes available, the way variants are structured, the relationships between products – all of these are constrained by the commerce platform’s internal model. When your products do not fit cleanly into that model, you end up with workarounds: custom fields with ambiguous names, attributes repurposed for unintended uses, and product structures that make sense to no one except the person who set them up.
A dedicated PIM system lets you model your products the way your business thinks about them, not the way your commerce platform requires you to store them.
The Right Architecture
The principle is simple: the PIM is the single source of truth for product information. The commerce platform consumes product data from the PIM and focuses on what it does best – selling.
In an Intershop implementation, this architecture is clean and well-supported.
PIM owns the product. All product creation, enrichment, translation, and governance happens in the PIM. Products are modelled according to business requirements, not commerce platform constraints. Workflows ensure that product data is reviewed, approved, and validated before it reaches any channel.
Intershop owns the transaction. Pricing, inventory, cart, checkout, order management, customer accounts – these are commerce functions that belong in Intershop. Intershop receives enriched, validated product data from the PIM and uses it to power the storefront.
The API connects them. Intershop’s composable architecture makes this integration straightforward. Product data flows from the PIM to Intershop through well-defined APIs. Changes in the PIM are reflected in the storefront automatically. There is one source of truth, and every channel reads from it.
What This Means in Practice
Faster Time to Market for New Products
When product governance lives in a PIM, the process of launching new products is decoupled from the commerce platform. Product managers can create, enrich, and approve new products in the PIM while the development team works on storefront features in Intershop. When the product is ready, it flows to the storefront through the integration. No manual re-entry, no copy-paste errors, no waiting for a developer to set up the product in the commerce backend.
Multi-Channel Consistency
The same product data that powers your Intershop storefront also feeds your marketplace listings, your print catalogues, your sales tools, and any other channel that needs product information. Because every channel reads from the same source, the data is consistent by design, not by effort.
Cleaner Intershop Implementation
When Intershop is not burdened with being the product information system, the implementation is simpler. The product data model in Intershop can be optimised for commerce performance rather than contorted to accommodate every possible product attribute. Catalogue imports are straightforward because the data arrives clean, complete, and structured.
This directly affects performance. A lean product data model in Intershop means faster search indexing, faster page rendering, and lower memory consumption. When your Intershop storefront needs to serve pages in under a second – which is what we deliver – every unnecessary data point is a performance cost.
Easier Upgrades and Maintenance
When product governance is separated from the commerce platform, upgrading Intershop becomes a commerce upgrade, not a product data migration. Custom product fields, complex attribute models, and governance workflows live in the PIM and are unaffected by commerce platform updates. This reduces upgrade risk and cost significantly.
Which PIM?
The choice of PIM depends on your organisation’s requirements, existing technology stack, and budget. We have implemented Intershop integrations with several PIM systems and can advise on the right fit for your specific situation.
The important decision is not which PIM to choose – it is the architectural decision to separate product governance from commerce. Once that decision is made, the PIM selection becomes a practical question of features, cost, and integration effort.
Getting Started
If your Intershop implementation is using the commerce back office as the primary source of product data – or if you are planning a new implementation and want to get the architecture right from the start – get in touch. We will review your product data landscape and recommend an architecture that scales with your business.
