How to decide whether Litium suits your e-commerce and PIM

Platform discussions often start with the feature list. You compare features, licences and launch dates. Meanwhile, your teams are dealing with product data in several systems, customer-specific prices in the business system and content that has to be published in several markets.

It is everyday work that decides whether Litium’s platform suits your business. The question is about data ownership, responsibility after go-live and cost over time. We walk through the mechanics behind the platform and what it requires of your organisation.

Why a unified commerce platform has become a strategic choice

Many of you have built your channels step by step. First came a website, then e-commerce, then a customer portal. Each solution got its own product data, its own login and its own integrations with the business system.

That works until the range grows. A wrong stock level in one channel leads to calls to sales and support. A price change missing from the portal leads to credit notes and manual work. The cost rarely shows in the project budget, but it comes back every week.

A unified platform changes the starting point. Product information, content and commerce logic are handled in the same architecture. You can publish the same base data to the website, e-commerce and portal with different rules per channel.

That reduces the number of syncs between separate systems. At the same time, the data model becomes a management issue. Someone has to decide which attributes are required for publishing, who approves changes and how markets may deviate from a shared structure.

Litium’s position gives a picture of its target group. Litium describes its target group as mid-sized and large corporate customers, mainly in the Nordics, with customers selling both to businesses and to consumers, according to the company’s reporting for 2025.

The mix is relevant for those of you selling through several channels with essentially the same range.

We recommend assessing the platform against your order flows and your product structure. A quick launch of a standard shop says little about how the solution works with customer-specific terms, several languages and several companies. That is where the strategic choice is made, channel by channel, year after year.

The core functions of Litium’s platform

Litium Commerce Cloud brings together e-commerce, CMS, PIM and campaign management in one solution, as stated in the company’s stock exchange information on Litium Commerce Cloud. The platform is therefore one system for commerce and content, with product information in the same data core.

The e-commerce part handles the cart, checkout and order flows. The CMS part governs pages, publishing and editors’ work with content. The PIM part handles enrichment, product relationships and variants. The campaign part links offers to the range and customer groups.

In practice, the parts fit together around the product. A product card pulls images and technical specifications from the PIM. The same product gets price and stock status from the business system. The content page around the product is governed in the CMS without the editor having to touch the product data.

In the PIM, variants, product relationships, images and documents are maintained in one place and published per channel and market. In the CMS, editors build pages and campaign areas with products already in the platform. In the commerce part, the order is created with the customer’s terms and passed on to the business system for delivery and invoicing.

The platform doesn’t replace the business system. Transactional data such as prices, stock levels and order status belongs there. Litium presents and sells; the business system delivers and books.

That boundary must be written down before implementation. Otherwise you build logic in two places and get discrepancies no one owns. Our experience is that a clear boundary early on saves the most time later, especially when several channels use the same pricing logic.

How the platform differs from standalone e-commerce or PIM

The alternative to a unified platform is separate systems. You choose an e-commerce platform, a standalone PIM and a CMS. Each system can be strong in its own area, but you own the connections between them.

With Litium, the PIM sits in the same solution as commerce. That reduces the number of integrations to build, test and upgrade. Product data enriched in the PIM is directly available to the website and portal. You avoid a sync that can fail between enrichment and publishing.

A built-in PIM doesn’t resolve semantic conflicts for you. If two companies in the group use the same attribute name for different things, no architecture will help. You need shared definitions, quality rules and decisions about what is common to the group and what is company-specific.

The cost of errors is more visible with separate systems, but it exists in both models. Wrong prices lead to credits. Wrong stock status leads to backorders and disappointed customers. Incomplete products lead to questions for the sales team. Include those items when comparing architectures, as we develop in our article on how a PIM steers product data to the right channel.

Our recommendation is clear. If you have a range sold through several channels on the same product foundation, a lot speaks for the unified model. If you have very different businesses with separate data models, standalone systems may be more reasonable, but then budget for the integrations and their management over time.

ERP integrations and ownership per data domain

The integrations decide whether the platform works in your operations. Litium describes support for real-time data from systems including Monitor, Jeeves, Microsoft Business Central, SAP, Infor and Visma on its solution page for B2B commerce. For those of you with mixed system landscapes, that is a concrete starting point.

The model we recommend is simple. The business system owns transactional data. The PIM owns enrichment and presentation. The web channel owns the publishing rules. When an ERP sync runs, it should never overwrite sales-facing product data that your staff have enriched.

The business system is the primary system for item numbers and base data, with the PIM as secondary; unclear ownership can lead to duplicates and broken relationships. For prices and customer terms, as well as stock levels and order status, the business system is primary and Litium secondary. Otherwise you risk wrong prices at checkout and credits, or backorders and wrong information to customers. The PIM is the primary system for images, copy, specifications and translations, with the web channel as secondary. Unclear ownership can lead to incomplete products being published or languages being mixed in the same market.

Litium Connect offers domain-specific APIs as well as a REST API and webhooks, according to Litium’s information via MFN. REST suits controlled calls, such as price requests. Webhooks suit events, such as an order having been created and needing further processing.

Split the integration work by domain and event type. Describe what happens when the business system is down, when the same event arrives twice and when a product lacks mandatory attributes. Queue handling, re-runs and error monitoring need named owners, which we describe in more detail in our article on ERP integration in practice.

With several companies and markets, the requirements get tougher. Shared products need to be able to inherit data, while local teams need their own copy and ranges. Solve that in the data model from the start. Rebuilding the model after launch is the most expensive integration work you can order.

Concrete use cases in Nordic commerce

Take an industrial wholesaler with thousands of items. Customers log in and see their own prices, their own range and current stock status per warehouse. The order goes straight to the business system. Salespeople spend their time on larger deals and advice.

In the same platform, resellers can have their own portal. They see campaigns, documents and spare parts linked to the right product generation. The relationship between main product and spare part is maintained once in the PIM and used in every channel.

A brand selling directly to consumers works differently with the same tools. Campaigns and content are governed in the CMS. Product enrichment happens in the PIM with images and copy per market. Prices and stock come from the business system without manual handling.

The scale of existing customers shows the range. Litium’s annual report for 2023 states that Litium’s customers Lindex, Tingstad and Jollyroom together turned over more than SEK 20 billion a year online, according to Litium’s annual report for 2023. Lindex and Jollyroom are consumer-focused, while Tingstad sells mainly to business customers.

Customer portals take care of recurring questions. Invoice copies, order history, delivery updates and complaints move from email to logged-in self-service. Support gets fewer routine calls, and customers get answers immediately, even outside office hours.

In a customer portal, customers can see order status and invoices and reorder on their own terms. A reseller portal shows the range, documents and campaigns per reseller tier. In a spare parts portal, exploded views and parts are linked to the right machine and model year.

The pattern is the same in every flow. You start with one channel and build on the same product data and the same integrations. Each new channel reuses the same foundation.

TCO, ongoing management and responsibility after go-live

Glanser is a Litium Premium Solution Partner and takes long-term product ownership of solutions built on the platform.

A platform budget usually rests on licence and implementation. A large part of the cost arises after go-live.

A complete TCO for Litium’s platform includes more items. ERP adjustments, product data enrichment, testing, support and version upgrades recur every year. Add the cost of wrong prices, wrong stock status and wrong order data. Those items are paid for in credits, express shipping and working hours.

A low-priced implementation often pushes integration work into the future. Syncs are built without error handling. Product data is migrated without quality rules. The first year works, then the business system is upgraded and no one knows who owns the connection.

The platform’s development also affects the budget. According to Litium, the platform has more than 300 customers, of which more than 50 joined in 2025, according to Litium’s website. A growing customer base brings continuous platform development, but it also means new versions you need to take a position on and test against your customisations.

Put responsibility in writing. Who follows the release notes, who tests your integrations against new versions and who fixes errors that arise at an upgrade? Glanser Care is how we take that responsibility at a fixed monthly cost, with version tracking and bug fixing and no new quote for each upgrade. Whatever supplier you choose, you should demand the same clarity, in line with the reasoning in three items missing from your TCO calculation.

What the approach requires of you, and when it doesn’t fit

Litium requires more of you than a simple web shop. You need a data model that someone owns and defends. Someone in your organisation has to decide which attributes are mandatory, how variants are built and when a product is ready to publish.

Product data enrichment is ongoing work that continues as long as the range changes. New products, new markets and new channel requirements arrive every quarter. Set aside time in the product and marketing teams from the start. Without that time, the PIM becomes a database no one trusts.

If you have a small range, a single channel and no customer-specific terms, the platform is probably more than you need. A simpler solution gives lower costs and a faster start. The same applies if you have no connection to a business system and aren’t planning one.

If you want to separate commerce completely from content, with different teams and different system choices for each, a unified platform fits less well. The architecture then works against how you operate. In that case, choose standalone systems and accept the integration cost knowingly.

Ask three questions before you sign. Who is responsible for your integrations working after the next platform upgrade, and is that included in the price? Who owns the product data model in two years’ time, and who approves changes to it? What does it cost when the business system changes version or is replaced entirely?

The answers reveal the supplier’s management model straight away. Concrete answers with names, processes and prices suggest well-thought-out product ownership. Answers that point to future quotes suggest you are buying a project and inheriting the risk yourselves.

Our way of working is built on the Function Library: pre-built, tested functions at fixed scope and fixed price. Customer-specific parts are isolated so they aren’t affected by upgrades. You can start with one solution and build on the same foundation as your needs grow.

Finally, assess the platform against your own day-to-day reality. Your prices, your products, your channels and your business system decide the choice.

If you’re facing a platform decision or want your current Litium solution reviewed, we offer an analysis where you set aside two hours and, within 72 hours, receive an inventory of functionality and integrations, a functional specification, a prototype and a complete cost picture with a timeline, free of charge and with the material yours to keep. Read more about the 72-hour analysis.