· By Erik Svedin
What a PIM system is, how it differs from the till, the webshop and the ERP, and when a bike shop with several suppliers actually needs one.
A PIM system, Product Information Management, is a system that keeps the shop's product information in one place: article number, EAN code, name, brand, category, technical specifications, images and product texts. From there the information is passed on to the till, the webshop, Google Shopping, Blocket and the benefit-bike portals that require structured data. A bike shop with one supplier and one channel manages without one. A shop with ten suppliers, a till, a webshop and a couple of portals needs either a PIM or a person who does the PIM system's job by hand, and it is that person's hours that decide whether it pays off. We run a bike shop ourselves and write this from how it looks at our own counter.
A PIM is a database with one rule: every product exists exactly once, and everything that is to be said about it is said there. The difference from a spreadsheet is that the PIM system also knows where the information is going, in which format, and keeps track of what has changed since last time. The difference from the webshop is that the PIM system does not sell anything; it describes. A PIM receives data from the suppliers, lets the shop complete and correct it, and then publishes the same data to every channel without anyone copying it out. Price and stock level usually do not live in the PIM system but in the till or the ERP, and the PIM system fetches them from there when needed.
The four systems answer different questions, and the problems arise when one of them is forced to answer a question it was not built for.
| System | The question it answers | Normally owns | Examples in the bike trade |
|---|---|---|---|
| Till (POS) | What was sold, at what price, and how many are left? | Price, stock level, sales | Nutid (now Vendolink), Specter, Crona, Lightspeed |
| Webshop | What does the product look like to the customer online? | Presentation, cart, payment | Abicart, WooCommerce, Shopify, Starweb |
| ERP | What have we bought, invoiced and booked? | Purchasing, invoices, finance | Specter, Fortnox with the stock module |
| PIM | What is the product, and what should be said about it everywhere? | Article data, EAN, specifications, images, texts | An industry-specific PIM or a general one such as Akeneo or Plytix |
A till can store one image and one text per article, but it cannot receive a supplier's price list with 20,000 rows and match them against the range. A webshop can handle variants, but it does not know what was sold in the shop this afternoon. It is in the gaps between the systems that the PIM system earns its keep.
A bike that is to be sold online, in the shop and through a benefit portal needs roughly twenty fields to be complete, and that is more than most tills have room for. Model, model year, frame size, colour, EAN per variant, manufacturer's part number, weight, frame type, drivetrain, brakes, motor and battery capacity on e-bikes, recommended price, category, at least two images and a product text. Parts and accessories manage with fewer fields but have a different problem instead: compatibility. A derailleur hanger, a chain or a brake pad is only right for certain bikes, and that information is rarely in the supplier's file but has to be added by the shop. That is typical PIM data: it exists nowhere else and it needs to show in every channel.
The rule of thumb is that the need arises when the shop has more than three suppliers sending price lists and more than one channel to publish in. Below that line, the till as the main source and the webshop as a mirror is perfectly sufficient. Above it, the signals arrive one at a time: the bike has been in the shop for three weeks but is not up on the web, the same article exists twice in the till with different names, the season's price list sits in a spreadsheet nobody dares to import, and the benefit portal sends the file back because EAN is missing on half the rows. The benefit bike is a reason in itself: the portals require structured product data per variant, and a shop that cannot deliver it is invisible where a large share of bike purchases are now made.
Partly, and that is how most shops actually do it. The till as the main source works as long as the article register is tidy, every article has an EAN and the number of suppliers is small. The webshop as the main source works for shops that sell mostly online and have few variants. Both solutions fail in the same three places: they cannot import the suppliers' files without manual work, they have limited support for variants and images, and they have no room for compatibility data. A shop that chooses the till as its main source should at least make sure the register is cleaned up properly once and that new articles are always created with EAN from the start; that is the cheapest way to postpone the need for a PIM.
From the suppliers, in whatever format each supplier happens to use. Some bike suppliers offer an API where data is fetched automatically, others put files on an FTP server, and many still send Excel or CSV files by email ahead of the season. The PIM system's first job is to read all the formats and match the rows against the shop's range, primarily on EAN code and secondarily on the manufacturer's part number. What does not match is reported instead of silently dropping out, and that is where the shop finds new products, discontinued articles and things that have changed name since the last list. Only then does the shop add what the supplier does not deliver: category in the shop's own tree, compatibility, its own texts.
Three things, and none of them is technical. An article register that can be trusted, which in practice means a review of duplicates, names and missing EAN codes before any system is connected. A person who owns the product data, that is someone who decides what an article is called and which category it belongs in when the supplier and the webshop say different things. And time at the change of season, when new price lists arrive and old models have to go; the PIM system makes the work smaller, not zero. Shops that skip the first point get a PIM full of the same duplicates the till had, only now in more channels.
A general PIM is built for any trade and requires the shop to build the supplier connections itself, define the fields for a bike and set up the channels. A PIM built for the bike trade has the suppliers' formats, the bike's fields and channels such as Blocket and benefit portals ready from the start, and can contain things a general PIM never gets: which derailleur hanger fits which frame, which brake pads fit which brake. For a shop with five to fifteen employees the difference in practice is whether setup takes weeks or months. Central PIM in BikeOffice is one such industry-specific system; anyone comparing should ask each vendor how many bike suppliers' formats are already imported.