We recently hosted a webinar on product data – what it costs a business when product information is spread across spreadsheets, inboxes, the ERP, and the eCommerce backend, and what the fix looks like on real projects.
One story from the session shows the problem better than any definition. A retailer’s eCommerce team kept learning about new products from customers tagging them on Instagram. The products were already on the shelves and the data was already in the ERP, but nobody told the eCommerce team. Three to five days later someone retyped the details by hand into a spreadsheet, then waited for copy and images from a third party. About 40% of that retailer’s range was not for sale online. We’ll recap the main points of what this means in this article, or you can watch the recording here:
How many places is your product data in
Two to five, for most webinar attendees, according to the poll result when Ana asked how many places they store or manage product information today. When you need a product detail, how many places do you go to get it? Usually more than one.
Product data arrives from suppliers, factories, the ERP, content teams, and translators. It lands in spreadsheets, inboxes, shared drives, and the eCommerce backend. Every copy drifts a little from the others, and after a while nobody is sure which version is right. Each new sales channel adds one more place to keep updated.
Where the cost shows up
Manual work
There are usually teams of one to five people whose only job is managing product data by hand. That is a payroll cost before anything else, and it grows with every new market and channel.
Late launches
During the webinar, hosts used an example of a North American manufacturer with a large store network. One full-time employee creates products in the eCommerce system. For each product he contacts roughly nine departments. He asks marketing for photos, content for descriptions, and the product team for ingredients and manufacturing data, then goes back to marketing to turn those ingredients into language a shopper understands. The company adds few products a season, and launching one is still a project.
Often the information exists. It is in a manufacturing format that cannot go straight onto a product page, and the enrichment step gets stuck between approvals, marketing, legal, and translation.
Lost sales
The retailer above was missing 40% of its range online. A US distributor of packaging and industrial supplies had only 10% of a large catalog on its site before its PIM project, with descriptions and images missing on part of that. Its full range is online now. Every day a product is on the shelf and not on the site is a day of revenue the business does not get.
Returns
Wrong or missing product information means customers get something they did not expect, and they send it back. The return is a lost sale plus the cost of handling it.
The reverse holds too. For Sportland, user research showed product pages were short on descriptions. scandiweb redesigned the pages, expanded the attribute sets in the PIM, reworked the size guides, and A/B tested the result. The new product page, which the team calls the super PDP, lifted sales by 39%.
Growth and AI
Every new market, channel, or product multiplies the places that need updating, so a setup that works today becomes a brake as the catalog grows. AI has the same problem. It handles messy data better than it used to, but with three versions of the same product it cannot tell which one is true.
What the fix looks like
One record per product, with the descriptions, images, documents, translations, and approval workflows attached to it. Every channel reads from that record.
It’s like a spreadsheet row with anywhere from 20 to several hundred fields, where each department owns its own cells. The photographer uploads images in their own view. The designer assigns images to products. The content team writes the descriptions. Teams can work inside the PIM or keep the tools they already use and connect them through an API, as long as the PIM holds the master copy.
Companies are organized by function, and product information does not belong to any one function. It is between several teams, so it needs a shared place where each team adds its part without making a mess somewhere else.
A product’s journey through a PIM
Here are the four stages a product passes on its way from a supplier file to a customer’s screen, with screens from live projects.
Getting data in
One client takes product data from many suppliers, each in a different format, and did not want to change how those suppliers work. So each supplier got an SFTP folder. They drop in their XML files, the client’s team runs the import, and the products appear in the PIM.
Not every supplier sends XML or has an API. Some send PDFs. Maris said AI extraction now pulls product data from those with good accuracy.
The PIM then normalizes what came in. A US packaging distributor sells box tape that suppliers list as either 5 centimeter or 2 inch. Its customers search in inches, so every tape now shows as 2 inch and sits in the same results. The same applies to shoe sizes or clothing sizes, and to any attribute that arrives in more than one standard.
Attribute sets define which fields every product of a type needs, with validation, so a new team member creates a product the same way as everyone else. Variants inherit everything from the parent product except what makes them different, such as color and size.
A food, drink, and restaurant equipment supplier in Latvia and Estonia ran several domains on two platforms, with ERP data moved between them by hand. scandiweb consolidated the domains into one store, added a Pimcore PIM with a two-way sync to SAP, and gave suppliers a file upload with automated product creation behind it. Over 20,000 products moved into the new setup, and the suppliers kept working the way they were used to.
Enriching it
In Pimcore, the asset management and the PIM are linked, so a size guide or spec sheet is dragged in once and connected to its product. Nobody hunts for the right file later.
Descriptions can be generated from the product’s attributes and images with AI, at least as a draft, and editing a draft is faster than starting from a blank page.
Translations run per language, get reviewed and approved, and update the main product and every variant that inherits the text. scandiweb has also built scheduled AI translation across an entire catalog for some clients.
Controlling it
Once data is in and enriched, user roles, permissions, and workflows decide what goes out. If a product is not approved, it does not reach the customer.
A Lithuanian cosmetics retailer had product data in its eCommerce platform and ERP, plus a few spreadsheets, with several teams needing to sign off before anything went live. In Pimcore, scandiweb set up roles for supplier managers, product data managers, the eCommerce team, and the translation team. A new product arrives from the ERP with its SKU, price, and stock level, and the right person gets notified. They fill in the attribute set, the supplier manager adds what they know about the brand, translations are reviewed and approved, and the product goes live. Price and stock changes from the ERP update the record on their own.
Reports show what is pending approval and which products are missing which fields in which language, so the person responsible opens the right product straight from the list.
Distributing it
The record feeds the website, marketplaces, print catalogs, distributors, and franchisees. For external partners, a brand or partner portal is safer than a backend login. They see the data and assets you choose, download what they need, and build collections for their own team.
One school photography company used the same approach for more than product data. Student and staff records and the photos themselves lived in different repositories and went out by email. scandiweb built a master data backbone in Pimcore with single sign-on, plus a portal where each school logs in, downloads its photos, and edits or uploads student and staff records without seeing anyone else’s.
What a PIM project takes
Discovery first. Every team has different data, workflows, stakeholders, and output channels, so scandiweb starts by mapping how the business works today and how it wants to work. Only then come the data model, the data cleanup, the system connections, and the training and rollout. scandiweb uses Pimcore for many of these projects because it bends to the way a team already works.
Our rule is to find the gap the PIM fills and shape the PIM around the existing teams. If the goal is only to put product data in one place, the project can be fairly simple. If the content has to be created inside the system, as with a fashion brand where photo shoots and image approvals need defined roles at each stage, it is more involved. Most projects land somewhere between the two.
If you want to see how a PIM would handle your own catalog, request a free PIM prototype. Upload a sample spreadsheet if you have one, and our team will build the prototype on your data and walk you through it, including how different roles see different parts of the catalog.
