Product data and PIM readiness: when an ecommerce catalogue outgrows spreadsheets
Spreadsheets are often the first product information system because they are familiar, flexible and easy to share. For a stable catalogue with one channel and a small group of careful owners, that can be entirely appropriate.
The problem begins when the file becomes a fragile integration layer. Marketing copies specifications into ecommerce. Sales maintains a separate price sheet. Suppliers email updates. Images are named differently from products. Marketplace fields use another taxonomy. Nobody can tell which version is approved.
A product information management platform, or PIM, may help govern enrichment and distribution. It does not create product truth by itself. The organisation must first define identifiers, attributes, sources, owners, workflows and channel rules.
The short answer
A catalogue has outgrown spreadsheets when repeated product-data work, conflict and risk can no longer be governed reliably through the current people and controls. That is a reason to assess the operating model, not automatic proof that a PIM is required.
- Assess complexity across channels, attributes, owners, change and quality, not only SKU count.
- Define products, variants, bundles, assets and relationships before selecting software.
- Assign an authoritative source and owner for each material data domain.
- Set completeness, accuracy, consistency and freshness rules by channel and product type.
- Compare a governed spreadsheet, platform-native tools, database, PIM and integration changes proportionately.
- Clean and map priority data before migration; software does not repair ambiguity automatically.
- Use paid Full Website Discovery when catalogue, ERP, integration, migration, multi-market or governance uncertainty is consequential.
Look for repeated operational cost and risk across several signals, then compare the smallest credible remedies.
What a PIM is, and what it is not
A PIM is a system and operating workflow for collecting, structuring, enriching, governing and distributing product information. It commonly sits between source systems and sales or communication channels. It can help teams manage descriptions, attributes, relationships, localisation, completeness and approval.
A PIM is not necessarily the source for price, stock, cost, orders or financial truth. Those domains may remain in ERP, POS, warehouse or commerce systems. A digital asset management system may own master images and usage rights. The ecommerce platform may own channel presentation and transaction-specific configuration.
The architecture should define authority by data domain. “Single source of truth” is useful shorthand only when it does not imply that one application owns everything. The objective is one governed source for each fact and a reliable rule for distributing it.
There is no universal SKU threshold
A catalogue with fifty technical products can have thousands of meaningful attributes, documents and compatibility relationships. A catalogue with many simple products may use a consistent supplier feed and require little enrichment. Product and variant counts alone do not reveal operational complexity.
Assess the number of owners, source systems, channels, languages, markets, product families, relationship types, assets, regulatory fields, change events and approval stages. Assess how often products launch and how much rework each channel creates.
The business case strengthens when complexity is repeated. If one annual catalogue import requires manual cleanup, targeted process improvement may be sufficient. If every product change is copied across five channels and several teams, governed central enrichment can create recurring value.
Signal 1: channels require repeated reformatting
The website, marketplaces, distributors, sales tools, print and advertising feeds may need the same core facts in different structures, lengths, classifications and image formats. Teams often solve this by creating a spreadsheet per destination. Consistent product truth is also a foundation for unified commerce.
Copies drift. A safety claim changes in one channel but not another. A product is retired on the website but remains in a partner feed. The team spends more time reconciling than enriching.
A PIM can support channel-specific transformations and completeness rules, but only after the organisation defines what is universal, what varies by market or channel and which owner approves each variation.
Signal 2: product identity and relationships are inconsistent
A SKU, supplier code, GTIN, model number and ecommerce handle may all identify aspects of a product. Problems arise when teams use them interchangeably or when variants and packs are not represented consistently.
Define the product model. Distinguish a sellable item from a parent product, variant, bundle, pack, spare part, accessory and replacement. Define how compatibility, substitution, upsell and category relationships work. Use stable identifiers and preserve source-system keys through integration.
GS1 standards provide globally used identifiers and classifications for relevant industries. They do not replace the organisation’s complete product model or local regulatory and commercial decisions. Validate which standards apply to the products and trading relationships involved.
Signal 3: attributes cannot support discovery and comparison
Customers search and filter through attributes. If colour is recorded as charcoal, dark grey and graphite without a controlled relationship, filtering becomes inconsistent. If dimensions are stored inside descriptions, the website cannot compare or validate them reliably. Attribute design also shapes ecommerce site search, navigation and filtering.
Build an attribute dictionary by product family. Define name, meaning, type, unit, allowed values, repeatability, source, owner, requirement, localisation and channel use. Separate internal technical facts from customer-facing labels.
Do not create hundreds of attributes simply because a PIM can hold them. Include information that supports a customer decision, operational process, partner requirement, compliance need or credible future channel.
Signal 4: ownership and approval are unclear
Product information can involve procurement, product, engineering, marketing, legal, ecommerce, sales and suppliers. A shared file gives everyone access but rarely defines decision rights.
Assign owners by data domain and product family. Define who creates, enriches, reviews, approves, publishes and retires information. Include deputies and service expectations. Make exceptions visible rather than resolving them through private messages and untracked copies.
A PIM workflow can enforce states and permissions, but the software cannot decide the governance model. If nobody agrees who owns a field, digitising the dispute will not resolve it.
Signal 5: quality cannot be demonstrated
A filled cell is not necessarily accurate. Data quality is contextual: a field must be correct, complete and current enough for its use. A technically valid weight can still be the wrong unit. A description can be complete for an internal system but inadequate for a marketplace.
GS1 Australia’s Data Quality Framework emphasises sustainable quality and accurate classification in data synchronisation. Useful quality dimensions include accuracy, completeness, consistency and timeliness. Define measurable rules by product family and destination.
Examples include: required dimensions present for freight calculation; approved imagery available before publication; category attributes drawn from controlled values; claims reviewed within an agreed period; destination feeds accepted without unresolved errors. Report exceptions to owners rather than hiding them in an export log.
Signal 6: launch and change are too dependent on manual coordination
A new-product launch can stall while teams chase copy, imagery, price, compliance and channel files. Changes may be applied in the wrong order. Products can go live before supporting documents or remain unavailable after stock arrives.
Map lifecycle states from proposed through active, paused, superseded and retired. Define which facts are required at each stage and which events trigger distribution. Separate product readiness from inventory availability and marketing launch where the operation requires different controls.
Measure time spent waiting for information, first-pass acceptance, channel rejection and post-publication correction. These measures create a more defensible PIM business case than a claim that centralisation will automatically accelerate time to market.
Understand what spreadsheets still do well
Spreadsheets are transparent, portable and flexible. They can work for controlled bulk entry, supplier templates, one-off migration and smaller catalogues with clear owners. Platform-native CSV and bulk-edit tools can also be appropriate.
Shopify and WooCommerce publish official product CSV guidance. These tools have defined fields, behaviours and limitations that can change. A CSV moves data; it does not provide complete workflow, approval, relationship, quality or syndication governance.
Improve the current process before replacing it. Use one controlled template, stable identifiers, validation, permissions, version discipline and an exception log. This can reduce immediate risk and reveal which requirements a future system must meet.
Separate the roles of adjacent systems
A PIM governs product information for reuse across channels. An ERP commonly owns operational records such as inventory, purchasing or finance. A DAM manages approved media assets and rights. The ecommerce platform presents and transacts the offer. Master-data management may govern shared enterprise entities more broadly. One system does not need to own every field.
Run a readiness scorecard before a vendor shortlist
Assess repeated channel reuse, attribute complexity, source conflicts, number of owners, approval stages, data-quality failures, launch frequency and integration needs. The result may point to better governed spreadsheets, integration repair, a DAM, PIM assessment or Full Website Discovery; it should not be treated as an automatic platform recommendation.
Prepare for PIM before selecting a product
Define outcomes and priority channels
State the operational and customer problem. Examples include reducing repeated enrichment, improving filter completeness, supporting a distributor feed or governing market-specific content. Prioritise the channels that create enough value to justify the first phase.
Model products, attributes and assets
Document representative product families, variants, bundles, relationships, units, controlled values, documents and images. Include difficult products, not only clean examples. Define what belongs in PIM, DAM, ERP and the commerce platform.
Map sources and integrations
For each domain, identify the authoritative system, key, update event, direction, frequency, transformation, error handling and owner. Determine how suppliers contribute information and how channel errors return to the team. Use website integration decisions before development to expose ownership and failure paths.
Define governance and quality
Assign roles, states, approvals, completeness rules, retention and review triggers. Identify which legal, technical or market claims need specialist approval. Define audit evidence appropriate to risk.
Create selection and acceptance criteria
Evaluate representative workflows, not a feature checklist. Test modelling flexibility, bulk operations, validation, preview, localisation, channel mapping, APIs, permissions, audit, performance, environments, export, support and complete lifecycle cost.
A shortlist is useful only after the organisation can explain what information must be governed and how it should flow.
Choose the smallest credible pathway
A governed spreadsheet and platform bulk tools may be sufficient when there is one channel, a stable model and clear ownership. A database or integration improvement may solve a source-of-truth problem without a full PIM. A DAM may be the priority when media, rights and renditions are the main constraint.
A PIM becomes more credible when several teams enrich structured information, several destinations reuse it, quality rules need enforcement and product change is frequent. Enterprise scope is not a reason to implement every channel and product family at once. Pilot a representative, valuable domain and prove the operating model.
Plan migration as a data and people programme
Inventory sources and profile data quality before mapping. Decide what to cleanse, enrich, archive or exclude. Preserve identifiers. Create controlled transformations and exception reports. Rehearse imports and downstream distribution with representative volumes.
Run ownership and workflow in parallel with technical implementation. Train creators, reviewers and administrators on real tasks. Define the cutover, freeze, delta updates, rollback and support period. Do not switch off old sources before records and downstream channels are reconciled.
PIM implementation does not end at go-live. Data models evolve, channels add fields, suppliers change and ownership moves. Budget for governance, support, platform maintenance, integration monitoring and continuous quality improvement as separate lifecycle responsibilities.
Measure whether the operating model improves
Establish a baseline before implementation. Useful measures can include time from product approval to channel readiness, first-pass feed acceptance, percentage of priority products meeting completeness rules, duplicate correction effort, channel rejection, post-publication data defects and time spent assembling recurring exports.
Choose measures connected to the approved outcome. A higher completeness score is useful only when the required fields support customer choice or channel operation. Faster publication is not success if inaccurate products reach market sooner. Balance speed with accuracy, approval and correction.
Review adoption as well as system output. If teams continue to maintain shadow spreadsheets, investigate whether workflow, access, training or capability does not fit their work. Prohibit uncontrolled sources where necessary, but fix the reason they reappear.
Report quality by product family, owner and destination so a high catalogue average does not hide a weak priority range. Use trends to direct stewardship work rather than presenting the score as proof that every field is correct.
Use paid Full Website Discovery where the unknowns are material
A high-level conversation can establish symptoms and likely fit. A site-specific catalogue inventory, attribute model, source-of-truth map, integration architecture, migration specification and vendor shortlist are substantive outputs, not free proposal work.
Where ecommerce, ERP, PIM, DAM, suppliers, multi-market data and governance interact, Full Website Discovery is normally the responsible pathway before implementation is scoped. It should resolve the decisions needed for a credible phased solution and estimate without pretending that every future data issue is predictable.
The objective is not one system for everything. It is one governed owner for each material data domain and a reliable distribution rule.
Frequently asked questions
How many products do we need before buying a PIM?
There is no universal threshold. Assess channels, attributes, relationships, owners, source systems, quality and change frequency. A small complex catalogue may justify stronger governance before a large simple one.
Can a PIM replace our ERP?
Usually the systems have different primary roles. ERP may own commercial and operational master data, while PIM owns enrichment and channel-ready information. Define authority by domain for the actual architecture.
Is a PIM the same as a DAM?
No. A DAM focuses on digital assets, metadata, rights and renditions. A PIM focuses on structured product information and enrichment. Products can integrate both, but capability boundaries vary by provider.
Will a PIM clean our existing product data?
It can validate and expose problems according to configured rules, but people must define truth, resolve conflicts and enrich missing information. Include data remediation and ownership in the programme.
Can we keep using spreadsheets with a PIM?
Often spreadsheets remain useful for controlled supplier input, bulk work and migration. Define which uses are authorised and how data returns to the governed system so parallel sources do not reappear.
Should PIM be implemented before a new ecommerce website?
Sequence depends on data condition, platform scope and dependencies. Some programmes need product governance first; others can establish a phased model alongside the website. Resolve the roadmap through paid Full Website Discovery rather than assuming one universal order.
Can Emote recommend a PIM from our product count?
No responsible recommendation follows product count alone. An initial meeting can establish context, but product modelling, workflow, integration, data and vendor assessment require an agreed paid engagement.
How Emote can help
Emote can help map product data, ownership, catalogue workflows and system dependencies before a business selects or implements a PIM solution.
The smallest credible first step is a focused readiness assessment using representative data and real publishing workflows. Proportionate paid Full Website Discovery is appropriate when migration, governance or multi-system integration must be defined.
To determine whether your catalogue needs process repair, platform configuration or a PIM pathway, book a meeting with Emote.