Skip to main content
Talk to an expert
ServicePIM & Data · Current operating model

Most commerce problems are data problems first.
We build the catalogue and the governance around it.

Product data sits underneath search, merchandising, fulfilment, marketplaces, localisation and customer trust. We design the model, set the governance, and run the integrations that keep it operationally usable, at the catalogue size you'll have in three years, not the one you have today.
Contents · 9 sections
  1. 01Data problems surface commercially.
  2. 02PIM is operational infrastructure.
  3. 03Most complexity sits in the model.
  4. 04Governance matters more than tooling.
  5. 05Integrations decide whether the platform works.
  6. 06Catalogue scale changes everything.
  7. 07AI supports governance, it does not replace it.
  8. 08Selected PIM & Data case studies.
  9. 09Common questions.
01 · Surface

Data problems surface commercially.

Search relevance drifts. Marketplaces start rejecting feeds. Merchandising spends afternoons fixing the same attributes. Customer service answers questions the product page should have answered. Fulfilment ships the wrong variant. None of it looks like a data problem on the day it happens.
It almost always is. Inconsistent enrichment, weak taxonomy, missing localisation, brittle inheritance, and ownership that nobody can name in writing. The commercial signal arrives later, in conversion, returns and operational load.
Data problems rarely stay in the data layer. We name them where they actually live, and fix them at the model, the workflow and the integration, not at the symptom.
~70%
Effort below the catalogue
Model, workflow, integrations
8-24
Consuming systems
Per enterprise catalogue
wk 1
Data model agreed
Owners named in writing
per channel
Validation rules
Not per upload
02 · Infrastructure

PIM is operational infrastructure.

A PIM isn't a product catalogue. It's the workflow infrastructure that decides who can change what, when, against which validation, and how that change reaches every downstream channel without anyone re-keying it.
Approvals, enrichment lanes, supplier onboarding, localisation, syndication and audit, designed as one operational system. Tools support the system; they don't replace it. We're platform-agnostic on the choice and opinionated on how it's run.
03 · Model

Most complexity sits in the model.

Taxonomy, attributes, variants, classification, inheritance and the relationships between them are decided in week one. The decisions that look small at the time set the cost of every change for the next five years.
We design the model to fit how the business actually trades, then test it against the channels that will consume it. Marketplaces and search aren't an afterthought; they're a constraint on the model from the first day.
04 · Governance

Governance matters more than tooling.

Tools support governance; they don't create it. The PIM that holds up at scale is the one where ownership, stewardship, validation and publishing controls are set as business processes first, and configured second.
supplier / ERP
Source
merchandising
Enrich
rules per channel
Validate
named owner
Approve
channels & markets
Syndicate
Inbound────────── one workflow, owners named at every step ──────────Channels
Every step has a single accountable owner. Validation runs at the boundary, not at the upload. Publishing is gated, audited and reversible. The platform decision is downstream of getting these calls right.
05 · Integrations

Integrations decide whether the platform actually works in the business.

Data ecosystems fail at the boundaries. ERP feeds, supplier syndication, DAM connectivity, ecommerce, marketplaces, search and middleware all carry their own owners, contracts and release cycles. The PIM is only as reliable as the slowest of them.
We map every integration in week one, agree the contract, and instrument it from day one. Retries and queue depth are first-class concerns, not an afterthought. Nothing about it is dramatic. That's the point.
06 · Scale

Catalogue scale changes everything.

What works at five thousand SKUs often breaks at five hundred thousand. SKU growth, category proliferation, supplier expansion, additional locales and new channels each add a multiplier on the same workflow. The PIMs that age well are the ones designed for the next order of magnitude, not the current one.
We design for the catalogue you'll have in three years. Workflow throughput, validation cost, syndication cadence and human review all sit inside an operating budget, not an open promise.
07 · AI

AI supports governance, it does not replace it.

Where AI earns its place in product data, it earns it inside the existing workflow: enrichment assistance, classification and attribute suggestions, translation support, anomaly detection on incoming feeds. Always inside the same approval gates as a human edit.
AI improves throughput when governance already exists. It magnifies whatever's already broken when it doesn't. We treat it as engineering inside an operational project, not as a separate narrative.
08 · Proof
Platforms · Governance

We pick the tool to fit the operating model.

Selection is led by the data model, the integration map and the people who'll run it day to day, not by preference. We'll tell you when a PIM isn't the answer, and what is.
Run in production
Akeneo PIM · Salsify · Informatica · Adobe Experience Manager Assets ·
Algolia · Constructor.io · Mirakl · ERP / OMS / WMS connectors
Governance & assurance
ISO 27001, 9001 and 42001 certified. Cyber Essentials Plus. WCAG 2.2 AA embedded in delivery.
09 · Questions we get asked

Common questions.

What does PIM and data work cover?

Product data modelling, attribute governance, channel-specific feeds, enrichment workflows and the integrations between PIM, ERP and the commerce platform. The aim is product data that is accurate at source and usable across every channel.

Do you implement Akeneo PIM?

Yes. iWeb implements Akeneo PIM for B2B and operational catalogues and integrates it with Adobe Commerce, Magento, ERPs and downstream channels.

Where should product data actually live: ERP, PIM or commerce?

Pricing, stock, accounts and orders belong in the ERP. Rich product attributes, media, categorisation and channel rules belong in the PIM. The commerce platform reads from both and owns the buying experience, not the master data.

Can PIM publish to marketplaces and other channels?

Yes. PIM is the natural source for marketplace feeds, print catalogues, sales tools and partner exports. Channel rules and validation are held in the PIM so each channel gets the data it actually needs.

How long does an Akeneo PIM implementation take?

Most Akeneo implementations iWeb scopes run three to six months, with longer engagements when the catalogue model itself needs rebuilding. Data quality work usually outlasts the technical build and is planned as ongoing.

When is PIM and data work the right next step?

When product data quality is limiting growth, integration or channel reach: attributes are inconsistent, enrichment is manual, marketplace feeds drift, or the catalogue cannot model how the business actually sells.

What are the typical risks in a PIM project?

The model is built around the current spreadsheet rather than how the catalogue actually works, or governance never lands so data quality drifts again within a year. iWeb names ownership and workflow alongside the technical build.

How does PIM connect to the ERP and commerce platform?

Through governed connectors or middleware. The PIM owns attributes, media and channel rules; the ERP keeps pricing, stock and accounts; the commerce platform reads from both and owns the buying experience.

Can iWeb take over an existing PIM or data programme?

Yes. The first step is to read the model, the integrations and the governance in place, then write down what to keep, stabilise or change. The first month is deliberately conservative on change.

How is PIM and data work usually priced?

Scope-dependent. A focused Akeneo implementation is typically a fixed-scope programme; ongoing data governance is usually a retainer. iWeb brackets cost against catalogue complexity, channel count and integration scope rather than a default template.

Next step

Get the model right. Set the governance. The tooling decision becomes the easy one.

Send the brief. You'll get a written response from a senior expert, the data model shape, the governance we'd put in place, the integration map and the platform decision we'd stand behind.
Talk to an expertor read where data problems surface →