Stork Delivery
A product catalog is an operational system
Treat product data as shared operational information, with clear identifiers, ownership, and rules for publishing changes.
The problem: inconsistent product data creates errors across teams
A product page shows one pack size. The warehouse picks another. The supplier feed uses a third description for what appears to be the same item.
That is a catalog problem with consequences well beyond the storefront.
Product data connects purchasing, sales, fulfillment, customer support, and reporting. It deserves the same attention as the other systems those teams depend on.
A practical approach
Establish a dependable identity
Decide how products, variants, supplier items, and units of measure relate to one another. Keep identifiers stable and record the mappings used by external systems.
A description is useful for a person but often insufficient for matching records automatically. Similar wording can refer to different variants, and the same item can arrive under several supplier descriptions.
When a product is replaced or discontinued, preserve the relationship needed to understand historical orders.
Assign fields to owners
Marketing may own public copy and imagery. Operations may own fulfillment dimensions or handling restrictions. Purchasing may own supplier relationships.
Identify which changes need review because they affect another team. Updating a pack quantity can have a different consequence from correcting a sentence on a product page.
Keep those responsibilities visible in the editing and approval process rather than relying on everyone remembering who to ask.
Validate before publishing
Use checks that match the business: required identifiers, permitted units, valid relationships, and consistency between variants. Keep a review path for exceptions the system cannot resolve safely.
For imported feeds, record what changed and where it came from. A nightly import should not silently overwrite an intentional correction without an agreed ownership rule.
Provide a way to inspect a proposed update before it affects live orders when the consequence justifies that step.
Trace changes downstream
A catalog update may need to reach a storefront, ERP, search index, and warehouse system. Decide how you will know that the required destinations accepted it.
A successful feed upload does not necessarily mean every item was accepted. Surface rejected records with an understandable reason and an accountable owner.
Keep the customer-facing promise aligned with what the business can fulfill. That includes availability and configuration rules as well as descriptive content.
A reliable ecommerce operation depends on product information that means the same thing across the systems using it. Improving that foundation can remove work from several teams at once.
The result: one product identity with verified downstream updates
Select a product family with pack-size or variant confusion. Agree on its identifiers, units, field owners, and approval rules, then send a controlled update through each required destination. Confirm that sales and fulfillment interpret the item consistently and that rejected updates reach an owner. Keep that trace as the acceptance example for future catalog imports.