How to Organise Product Data Without a PIM: A Small-Business Operating Model

Why this is different for a smaller business

A small ecommerce team often has several lightweight systems because each solves a different job well:

• the ecommerce platform publishes customer-facing information
• a spreadsheet handles bulk product work
• a shared drive stores certificates and technical documents
• supplier email or portals provide upstream evidence
• accounting or customs records hold commercial or border information.

Problems appear when the business assumes that the place where a value is visible is automatically the place that owns the value.

Use an authority map, not a single master file

For each fact, define:

The same business may give a different answer for GTIN, country of origin, recycled content or a conformity document. That is normal.

A minimum viable small-business stack

Ecommerce platform

Use it for information that needs to be published or distributed to channels. Do not make a customer-facing field the only surviving record of why the value is true.

Product master spreadsheet

A spreadsheet can work as a controlled working register when it has stable field definitions, identifiers, ownership and change discipline. Avoid duplicate columns that mean nearly the same thing and avoid storing evidence only as free-text notes.

Shared evidence library

Keep documents in a predictable location and reference them from the governed fact. The document and the product value should remain separate: one is evidence, the other is the current product record.

Supplier request log

Record what was requested, from whom, for which product scope and what came back. Without the request history, supplier silence and “not yet asked” can become indistinguishable.

Change log

When a value changes, decide whether you are correcting an error, versioning a record, changing a variant or SKU, creating a batch distinction or changing the product identity. Do not silently overwrite history when the old value was true for products already sold.

For textile products, see what ActivateDigital can build from those existing records. The starting point is your store, spreadsheet and evidence, not a PIM purchase or another complete passport form.

Before adding anything to that stack, it is worth knowing what it already covers. You can test what the spreadsheet you already keep can support.

A PIM is one way to govern product information, not the outcome

The outcome is stable identity, governed product facts, evidence, change control and reuse across channels and regulation. A small ecommerce business may use Shopify, a structured master, supplier documents and evidence in a shared drive. A larger business may use ERP, PIM, PLM, DAM, MDM and several regional masters. The identity and governance problem can exist in either architecture.

Eurostat reported ERP use in 2025 at 41% among small enterprises with 10 to 49 employees, compared with 89% among large enterprises. That supports only the narrow point that enterprise systems cannot be assumed. It is ERP evidence, not PIM evidence, and the survey's mandatory population excludes micro-enterprises. See Eurostat's 2025 e-business application release and survey metadata.

Your data can stay in systems that already work. The next problem is getting those systems to agree which product they describe. Continue to mapping product IDs across ERP, PIM, ecommerce and a DPP.

The rules that matter more than the software

Keep identifiers stable

Do not let internal stock codes, platform IDs and regulated or external identifiers drift into one another.

Keep scope explicit

A model fact should not be copied into every SKU as if each row independently established it. A batch fact should not be promoted to model truth.

Keep evidence linked

A certificate in a shared drive has limited operational value if nobody can tell which fact, product or version it supports.

Keep ownership explicit

The business owner of a fact can be a person even where the system of record is a spreadsheet. System ownership and human accountability are separate.

Keep unknowns visible

Do not fill missing values with estimates unless the method and status of the estimate are explicit and appropriate. An unknown with a next action is safer than false precision.

That is the whole idea behind a governed record: each value keeps the file it was read out of, so the evidence does not have to be found again later.

Keep the evidence with the fact

A governed fact needs the document that supports it kept close at hand. For what certificates, declarations and test reports each establish, see certificates, declarations and test reports, and what each is worth.

When a PIM may become useful

A PIM can be valuable when the number of channels, products, languages, attributes, workflows or approval steps makes lightweight governance difficult. That is an operating-scale decision, not a DPP legal requirement by itself.

The migration question: which current failure mode would a PIM solve? If the answer is unclear, improving authority and evidence rules may be the better first step.

What managed onboarding actually costs you

There is a third option between a spreadsheet and a PIM, and it is the one providers tend to lead with: somebody else does the onboarding for you, priced per product. Whether that is good value depends on which of three jobs you are buying.

• Catalogue normalisation. Turning what you have into consistent values. This scales with how inconsistent your records are, not with how many you have, so a small messy catalogue can cost more than a large clean one.
• Exception labour. The products that do not fit the pattern. This is the line that decides the bill, and it is the one no quote itemises.
• Evidence chase. Getting an answer out of a supplier who has not given you one. Nobody can price this in advance, because it depends on somebody else's willingness to reply.

A per-product managed service beats building an integration when your catalogue is small, changes rarely and has few source systems, because integration cost is mostly fixed and per-product cost is mostly variable. It stops beating it when the catalogue churns, because you pay the variable cost again every season.

CIRPASS describes multi-tenancy and delegation as a way for providers to spread implementation cost and potentially create economies of scale for smaller businesses. That is a mechanism rather than a measured saving: the study is qualitative, the sample was eight interviews, and any benefit still depends on standardisation, onboarding, product complexity and how ready your data already is. Ask a provider which of the three jobs above their price covers, and what happens to the bill when it hits an exception.

Canonical Knowledge connections

• Which system should own each fact? → Which System Should Own Each Product Fact?
• Where does the fact belong? → Which Product Facts Belong at Model, Variant and SKU Level?
• What happens when the product changes? → Overwrite, Version or New Product?
• What should be extracted from technical files? → Technical File to Governed Product Data
• How does Shopify fit? → Digital Product Passports from a Shopify Catalogue
• What data do I already have? → The Product Data You Already Have

What not to assume

Do not assume that:

• a PIM is required for DPP readiness
• Shopify should become the legal or evidential owner of every fact
• a spreadsheet is inherently ungoverned
• putting documents in one folder makes the underlying facts governed
• one source-of-truth label can replace fact-by-fact authority decisions.

Sources & legal basis

• ActivateDigital Product Evidence + SME Original Research Programme v1.1: SME Method v1.1 and Research Data Model v1.1.
• ActivateDigital Knowledge: Which System Should Own Each Product Fact?
• ActivateDigital Knowledge: Model vs Variant vs SKU.
• ActivateDigital Knowledge: Technical File to Governed Product Data.
• ActivateDigital Knowledge: Digital Product Passports from a Shopify Catalogue.

Last verified: 2 September 2026.