How to succeed with your PIM implementation

You’re about to send a quote, but the product’s dimensions differ between the sales material and the website. The reseller has an older image. No one knows whether the document in the shared folder is still valid.

Meanwhile, new items are waiting to be published. A PIM implementation needs to start with the decisions that are holding them back: who owns the information, which values apply and when the information may leave the building.

The PIM implementation starts in your day-to-day work

A salesperson finds a technical specification in a spreadsheet. Marketing uses the copy from the last launch. The person responsible for the customer portal fetches a document from the product department. Everyone is trying to do the right thing, but they’re working with different versions of the same item.

When the customer notices the difference, someone has to work out which information applies. Meanwhile the quote or the publication waits. The product manager has to check the material again, even though the information has already been handled in several places.

This can happen even when every department does its job well. A change of material can affect the specification, the image and the assembly instructions at the same time. If no one holds the change together, one channel may get the right document while another keeps the old one.

A new or changed product requires more decisions than a new item number. Attributes, specifications, images, documents and translations need to match. Someone also needs to decide what each channel should show and when the information is approved.

A typical example is a product that gets a new connection. Sales need the right compatibility in the quote. The web manager needs to be able to filter on the connection. The reseller needs to know which older variant is being replaced and which accessories still fit.

Product information therefore needs to be managed as ongoing business work. PIM gives you a shared place to manage the information, but you still have to make the decisions. The capability becomes useful when product changes can be followed all the way to what the customer sees.

Map your sources before you model

Start by following one item through today’s work. Pull up the record in the business system, the spreadsheet that supplements it, and the supplier’s documentation. Then compare that with what is actually shown on the website and in the portal.

Note where each piece of information is created, who changes it and who approves it. A field can exist in several systems without anyone having decided which source applies. That uncertainty is exactly what you need to resolve before the integration starts moving values.

Also map product families, languages and receiving channels. A product website may need technical filters, while a reseller channel requires a specific file format. Local spreadsheets may hold information that has never reached the central organisation.

Start from your actual sales. According to Statistics Sweden’s data on web sales in 2024, 30 percent of companies in the industries reported sold via their own website, app or e-commerce platform. The share was 21 percent in manufacturing and 54 percent in motor vehicle trade and repair.

Your channel structure needs to be assessed based on which information customers and resellers actually use. A channel that requires a lot of manual work may be worth prioritising even if it handles only a small part of the range.

Then assign decisions clearly. The product owner decides on business definitions. Domain owners own attributes and classification within their product areas. IT is responsible for integration and operations, while marketing and sales approve channel and language requirements.

One person can hold several roles, but the roles need to be explicit. Otherwise a simple question about a unit of measure risks getting stuck between departments. The supplier can help you document responsibilities, but the mandate has to come from you.

The mapping is done when you can follow a critical field from origin to publication. You should know its source, its owner and its recipients. Information that still has no owner needs a clear decision before you model it.

A data model you can reuse

A product’s length might be free text in one document and a number in another. To the customer, both may look understandable. For filtering, comparison and channel export, you need to decide on one shared way of storing the value.

A canonical data model is your agreed structure for product information. It describes attributes, data types and permitted values. It also covers variants, product relationships and packaging hierarchies, so that, for example, a single unit, a pack and a pallet can be told apart.

Define which properties a variant may inherit from the main product. A shared description can work for the whole family, while dimensions and compatibility need to follow the individual variant. Unclear inheritance rules make it hard to see where an error needs to be fixed.

Product relationships also need a defined meaning. An accessory, a spare part and a replacement product describe different relationships. If everything is stored as “related products”, receiving channels will struggle to show the right recommendation.

Then decide what “ready to publish” means for each channel. Missing compatibility may need to block a technical item. A supplementary inspiration image can be added later. That difference needs to be built into the validation rules, so editors don’t have to interpret every product from scratch.

Multiple languages and units require explicit rules. An approved Swedish field says nothing about the Norwegian translation. Also document the source, changes and approval, so you can check how a value came about.

Life-cycle data needs a place in the model from the moment you decide the structure. GS1 Sweden describes digital product passports as a product identity linked to one or more data sources under the EU’s Ecodesign for Sustainable Products Regulation. The information can include sustainability performance, origin, warranty, recycling, and assembly and repair instructions.

That doesn’t mean all information has to be collected before the first publication. Identifiers and relationships should, however, be able to link the right material to the right product version. Mark which information is waiting on the supplier or product development, and who will verify it.

Work on structured PIM data is closely tied to these decisions. The first delivery might cover the website and the customer portal. The model should also be extendable with new information without existing fields changing meaning.

Separate the business system’s fields from the PIM

The price in the customer portal should follow the business system’s pricing logic. The product description needs to be editable by whoever is responsible for content. If the same field can be changed freely in both systems, the next sync can overwrite an approved value.

Let the business system carry item numbers, base data, prices, stock and order-related information. The PIM handles enriched copy, attributes, images and documents. Every field still needs an explicit decision about which system is the authoritative source.

Describe each flow’s direction and frequency. State what happens when a value is missing, when the recipient rejects a record and when the systems disagree. Errors need a responsible recipient and an understandable cause, so that someone can fix them.

Also require idempotency. That means re-running the same message doesn’t create duplicates or repeat a change incorrectly. An interrupted run should be able to resume without anyone having to guess which records have already been processed.

The connection between e-commerce and the business system needs to be tested with real item data. Choose a pilot range that includes simple products, variants, spare parts and incomplete supplier data. A selection of only well-cleaned items hides the problems you need to find.

Normalise the pilot’s values and run the whole flow against an actual publishing channel. Check that the item’s content is shown correctly and that a rejected piece of information can be traced back. Decide the acceptance criteria before testing, so the assessment doesn’t shift when problems appear.

Test the data schema, transformations and integrations. Permissions, performance and user acceptance also need to be included. A technically successful transfer can still lead to wrong filtering or make documents visible to the wrong recipients.

Measure your own baseline before you start. Track completeness, import errors, time to publication, manual corrections and approvals without rework.

The number of imported items says too little about quality. Also track the share of items ready to publish and which rules are blocking the rest. If you use a combined quality score, blocking errors still need to stop publication, even when all other fields are complete.

What a PIM implementation requires of you

The product owner needs to be able to make decisions when departments use different definitions. That time has to be in the calendar. If every question is pushed to the next meeting, the work keeps waiting, even once the system is fully configured.

You also need to accept shared definitions. A local term may be familiar and work well within a department. When several channels reuse the same field, the organisation needs to agree on what the value means and which exceptions are allowed.

A blocking rule has to have consequences even when a launch is close. If someone can always publish anyway, the rule becomes hard to trust. Any exceptions need a named decision-maker, a documented reason and a plan for fixing them.

A separate PIM system doesn’t suit every business. If you have a small, stable range and a single channel, clear routines in the business system may be enough. A new system then adds administration that needs to be weighed against the actual benefit.

Several languages, resellers and recurring variant changes create different conditions. Assess how much work you spend checking, completing and sending the same information. Choose the scope based on the tasks that need to change and the people who can take responsibility for them.

AI requires further decisions about permitted changes. According to Statistics Sweden’s statistics on companies’ use of AI, use rose from 25.2 percent in 2024 to 35.0 percent in 2025. Among companies using AI, 41.7 percent use it for marketing and sales.

As a cautious start, let AI suggest summaries and keywords based on approved material. Technical attributes need a verifiable source or the product owner’s approval. Log the suggestion, the change and who approved the result.

Even a summary can contain a false promise. Measure errors per published product before automating more fields. More copy production can mean more information needs reviewing, especially when the same content is used in several channels.

Three questions before you choose a path

Ask the supplier to answer with your own item data in front of them. Who owns each field when the business system and the PIM show different values? The answer needs to state which system applies and who in your organisation may decide on an exception.

How is an item stopped when a blocking rule fails? A walkthrough needs to show that the item is actually held back, that the error is understandable and that the right person can fix it. A warning icon without clear handling leaves a lot of work for the editor.

Who takes responsibility for functionality and compatibility when the platform or business system gets a new version? The answer needs to cover the whole flow, including dependencies between systems. Together, the answers reveal which responsibilities remain with you after go-live.

Ask for the division of responsibility to be written into the scope and the management agreement. Phrases like “help when needed” say little about who investigates an error. It needs to be clear who drives the case when several parts of the solution are involved.

At Glanser, enriched content is gathered in the PIM for management and distribution to websites, customer portals and reseller channels. The business system carries item numbers, base data, pricing logic and transaction-related information. That keeps content work separate from the business rules that govern the customer’s purchase.

Glanser Care means we take responsibility for functionality and compatibility across the whole solution, even when the platform or business system gets a new version. It covers version tracking, compatibility through upgrades and bug fixing at an agreed fixed monthly cost. Upgrades don’t require a new quote.

When you assess a Litium platform, responsibility after launch therefore needs to be part of the assessment. The platform’s capabilities and the supplier’s commitment need to be assessable separately. Your organisation remains responsible for the accuracy of product information and for who may approve it.

Finally, a working handover needs to be tested by the people who will work in the solution. They should be able to find a stopped field, understand why and know who makes the next decision. That’s where it becomes clear whether the way of working holds up after the project team has left.

On the PIM page, you can see how we govern, enrich and distribute product information to websites, customer portals and reseller channels.