Product Data for Furniture Manufacturing

Landscape map

Product truth does not live in one system

PIM manages product cards and variants, 1C and the warehouse handle accounting, and sales channels receive prepared data through integrations.

Product Data for Furniture Manufacturing

01

PIM

Master cards, materials, colors, media, and data completeness.

02

1C and warehouse

Prices, documents, stock, and movements remain in the accounting system.

03

Channels

The site, Kaspi, Wildberries, Ozon, Yandex Market, dealers, and the marketplace receive their own card formats.

04

Support

Exchange errors, SLA, access, and training are designed before launch.

First, data owners
Pilot on one channel
Loosely coupled integrations

When a furniture manufacturer grows, product data is no longer just a content team's task.
One chair turns into dozens of variants by fabric, color, legs, hardware, and configuration. 1C handles accounting, the site and marketplaces expect ready-made cards, production works with materials and specifications, the warehouse needs to understand stock, and the sales manager cannot check availability by phone every time. In this situation, PIM looks like the natural solution.
But the project rarely fails because the wrong boxed product was chosen.
More often, it stalls earlier: the company has not agreed on which data are master data, where prices and stock live, who is responsible for card quality, which channels should be connected first, and what support to expect after launch.

Key point

What to decide before a PIM project

PIM should not replace 1C, the warehouse system, or ERP. Its role is to become the single source of truth for product information: attributes, variants, materials, descriptions, media, and publishing rules.
For furniture, the master card and reference data model is critical. Otherwise the assortment explodes: every fabric, handle, and leg creates a separate card that cannot be maintained manually.
Stock and prices should be designed separately from PIM. In most setups, they remain in accounting systems, while PIM receives them through integrations and prepares data for sales channels.
Before choosing Pimcore, Akeneo, Brandquad, or another system, you need to describe the workflow: from the appearance of a new model to publication on the site, Kaspi, Wildberries, Ozon, Yandex Market, or a future marketplace.
The first launch is better limited to one or two flows: for example, PIM for the site and one marketplace. This reveals real risks faster than trying to automate production, warehouse, all channels, and an industry platform at once.

Why furniture data quickly becomes unmanageable

In furniture, a product rarely equals one SKU.

One model can have dozens of fabrics, several colors, leg options, armrest types, size restrictions, and delivery and assembly services.

If every combination is created as a separate product, the catalog quickly turns into a mass of cards that almost nobody buys, but each one still has to be maintained.

The problem gets worse when data is spread across Excel, Google Sheets, 1C, the site, Bitrix24, marketplace account portals, and the knowledge of individual managers. In such a setup, the business loses more than just content managers' time: the buyer sees an incomplete assortment, the manager is unsure about color availability, the marketplace card is assembled manually, and production receives clarifications after the order.

For a furniture manufacturer, it is useful to split data into three layers.

Product logic describes the model, variants, materials, allowed combinations, photos, and instructions.

Accounting logic is responsible for prices, cost, warehouse stock, documents, and material movements.

Channel logic determines which attributes and texts the site, marketplaces, dealers, a B2B portal, or a future industry platform need.

If these layers are mixed together, the PIM project turns into an attempt to make one system for everything.

At the start this seems simpler, but later any change in a sales channel or production requires reworking the entire setup.

What PIM should do and what is better left to other systems

PIM is needed to manage product information: attributes, descriptions, media, reference data, variants, card completeness, and publishing rules. For a furniture manufacturer, this is especially important: PIM can store the master card for a sofa or armchair and the rules for which fabrics, colors, and components are allowed for that model. 1C or ERP usually remain the source of prices, accounting, procurement, warehouse documents, and financial logic. The warehouse system is responsible for actual stock and movements.

The site and marketplaces show the card to the buyer in the required format. The integration layer connects these systems so that PIM does not become another monolith. The right question before starting is not "which PIM system to buy," but "which data types each system is responsible for." For example:

Data type	Where ownership should sit	Why it matters
Name, description, attributes, materials, photos	PIM/DAM	This is product content that needs to be reused across sales channels.
Allowed fabric, color, and hardware options	PIM	These rules determine which product card can be assembled and shown to the buyer.
Price, discount, cost	1C/ERP/pricing layer	Price depends on accounting, procurement, margin, and commercial rules.
Warehouse stock	WMS/1C/warehouse system	Stock is an operational fact that must be updated based on product movements.
Requirements of the site, Kaspi, Wildberries, Ozon, Yandex Market, and dealers	PIM + integration layer	One product should turn into different cards without manual copying.

This analysis immediately shows the project boundaries. PIM does not need to know everything about the warehouse, but it must understand which product attributes are needed so that stock can be matched correctly with the variant the buyer sees.

Risks to review before launch

Card explosion

If every combination is created as a separate product, the system quickly becomes expensive to maintain. For furniture, it is better to start with master cards, reference data, and rules for allowed combinations.

Prices and stock in PIM

PIM can receive prices and stock, but it should not become the owner of accounting data. Otherwise, discrepancies will appear with 1C, the warehouse, and financial reporting.

Raw reference data

Fabrics, colors, materials, hardware, services, and packaging must have consistent names, codes, statuses, and owners. Otherwise PIM will move the chaos from Excel into the new system.

Channels without mapping

The site, Kaspi, Wildberries, Ozon, Yandex Market, and the dealer portal have different requirements. Without transformation rules, cards will continue to be assembled manually.

Support without SLA

When cards affect sales, you need to define in advance who handles export errors, who checks a failed exchange, and who is responsible for a critical incident on a weekend.

Publishing without a decision

On-premise or on-site deployment needs to be planned in advance: servers, updates, backups, access, monitoring, and integrations.

What the right data model makes possible

When PIM is designed as a product hub, the company gets more than just nice-looking cards. It lowers the cost of change.

A new furniture model is created through reference data and templates, not by manually copying dozens of cards. The content manager can see which fields are missing before publication.

Production receives an allowed material combination, not free text from a manager's comment.

The site and marketplaces receive the card in their own format.

When channel requirements change, the export rule changes, not every card individually. In the Askona case, the PIM approach made it possible to represent a large set of variants through master cards and reference data: the buyer can see customization options without overloading the catalog with millions of separate pages. In the Relyef-Center case, automating publication from PIM reduced collection publishing to the marketplace from 10 days to 1 day.

In the Polaris case, one product became one manageable card, and changes on the marketplace side did not require new development for every edit.

These examples matter not as “take the same system.”

They show the principle: first the product data model is built, then sales channels and integrations start working from it.

How we recommend approaching the project

The first stage is not installing a boxed product, but a short assessment of data and processes. It should trace the product journey from idea to sale:

Who creates the new model and which data appears first.

Where materials, fabrics, hardware, and combination constraints are stored.

What data production, sales, warehouse, accounting, and marketing need.

What is currently the source of price and stock.

Which sales channels need to be connected first.

What requirements exist for hosting, access, backups, and support. After that, you can compare options: Pimcore, Akeneo, Brandquad, industry solutions, or a custom layer around existing systems. For some manufacturers, Pimcore in their own environment makes sense, especially if PIM, DAM, and a flexible data model are important. For other companies, Akeneo or another PIM system will get started faster if their processes are closer to a standard product model. We usually recommend not debating the vendor in a vacuum.

It is better to choose one pilot flow: for example, set up a chair or armchair category, describe the variants, connect it to 1C for prices and stock, and publish it to the site and one marketplace. This kind of pilot shows the real questions: reference data quality, team speed, export errors, support requirements, and the amount of custom development.

Map out your integration landscape

clients@kt.team Telegram @kt_team_it

Architecture: loose coupling instead of a new monolith

A PIM project in furniture manufacturing almost always involves several systems.

That is why it is important not to turn PIM into a central monolith that tries to store all company data.

A practical architecture is built as a loosely coupled setup: PIM/DAM manages product content, media, variants, and card readiness rules; 1C/ERP handles accounting, prices, purchasing, documents, and financial processes; WMS or the warehouse layer handles actual stock and movements; API/ESB/events connect the systems and record exchange errors; the site, marketplace, and B2B portal receive ready-made cards.

This approach gives portability: the system can be maintained by an internal team or handed over to another contractor because the boundaries are clear, the exchanges are documented, and the business logic is not hidden in random Excel files. In our cases, similar logic was used in integrations with 200+ 1C systems, in an eCommerce integration with a marketplace through WSO2 ESB, and in a furniture holding project where point-to-point exchanges were replaced by a loosely coupled Kafka-based setup.

What to prepare before the first meeting with the integrator

To avoid spending the first week just searching for source data, it helps to prepare a small package in advance. It does not replace analysis, but it sharply reduces uncertainty: the team will more quickly see where standard PIM functionality is needed, where configuration is enough, and where integration or a process change will be required.

Initial data package

10-20 real cards from different categories: simple products, customizable products, products with services and components.
List of attributes by category: materials, colors, sizes, hardware, packaging, services, constraints.
Examples of the current Excel/Google Sheets files and the rules by which data flows from them to the site.
1C description: configuration, what data is maintained there, who is responsible for prices, stock, and specifications.
List of sales channels and priority: site, Kaspi, Wildberries, Ozon, Yandex Market, dealers, B2B, future marketplace.
Hosting requirements: on-premise, local servers, access, backups, information security procedures.
Support expectations: working hours, critical channels, acceptable response time, who handles incidents.

Minimum roadmap

01
1-2 weeks: assessment
A map of processes, systems, reference data, roles, channels, and constraints.
02
2-4 weeks: PIM pilot
Master cards, reference data, variant rules, user permissions, initial data model.
03
2-4 weeks: first channel
Publishing to a site or one marketplace, card completeness checks, exchange errors, team training.
04
Next stage: integrations
1C for prices and stock, DAM for media, API/ESB/events, monitoring, and support procedures.
05
Scaling
New categories, dealer channels, suppliers, a B2B portal, or a separate marketplace initiative.

Where KT.Team can help

We get involved where the PIM project affects not only the product card, but also the architecture around it: 1C, site, marketplaces, DAM, integration layer, support, and team training. Our public cases show different sides of this task.

Relevant cases

PIM transformation for Askona - master cards, variants, and furniture assortment customization.
Publishing products from PIM to marketplaces for Relyef-Center - collection publishing sped up from 10 days to 1 day.
PIM for Polaris marketplaces - one product as one manageable card.
Pimcore DAM for a furniture manufacturer - management of media files, rights, and usage restrictions.
A single API for 200+ 1C systems - an example of loosely coupled integration logic around accounting systems.
eCommerce integration with marketplaces via WSO2 ESB - how a Pimcore item card can flow across channels without manual copying.

How a Furniture Manufacturer Can Manage Product Data Before PIM Implementation

Product truth does not live in one system