Before You Open a Product Card in Nebim: Where Should Product Data Be Born?
Start of season, Tuesday evening. Two people from the e-commerce team are moving the new season's 600 variants from Excel into Nebim, line by line. Color codes come from design's list, the size range from purchasing's file, composition from the pattern maker's notes. Close to midnight a color code slips one cell in a single row. Nobody notices. A week later the stock of the navy product shows up on the black product's page, and the team is chasing orders that landed in the wrong channel.
Neither Nebim nor the team working that night is to blame. The problem is that product data was born in the wrong place. In this article we answer a question for brands running Nebim: before a product card is opened in Nebim, where and how should product data be created?
Running Nebim? We will show you in 30 minutes. See, with your own data, how a product is defined once in Pimland and written to Nebim with its variants. Book a demo
Key takeaways
- The product card in Nebim is the commercial record of every variant sold and stocked. Its accuracy depends on the accuracy of the data that exists before the card is opened.
- Product data should be entered once, where it is born: during the collection, sampling and tech pack process, in other words in product development.
- In a Nebim + Pimland setup, products and variants are created in Pimland and written to Nebim; Pimland also reads data back from Nebim. Nobody enters the same product twice.
- A measurement from the field: the time for a new product to be ready on all channels fell from 8 working days to 4, and channel data entry from 45 to 15 minutes per product.
- At the end of the article you will find a 10-field checklist for a good product card.
Why are product cards in Nebim opened late and incomplete?
Opening a product card in Nebim is not technically hard. Nebim is built for apparel brands that work with color and size structures; its variant, barcode and stock logic is well established. Cards are opened late and incomplete not because of Nebim's screen, but because the information that should go into the card is scattered.
The information needed for an apparel product card comes from at least four teams:
- Design: style name, color options, color codes, visual references
- Product development and pattern making: size range, size chart, composition, care instructions
- Purchasing and costing: supplier, cost, target retail price
- E-commerce and marketing: title, description, category, product attributes
When these teams work in different files, the card waits until all the information is gathered. When time runs short at the start of a season, the shortest path wins: the card is opened with missing information and “we will complete it later”. That “later” often comes after the product is already on sale.
The risk is even greater with bulk product creation. A single shift in an Excel file with hundreds of rows can tie dozens of variants to the wrong code. The error is not born in the card, but in the spreadsheet that feeds it.
Why should product data be entered once, where it is born?
A product's composition is known on the day the sample is approved. Color codes are settled with the design decision and the size range with the pattern. If this information is recorded the moment it is born, nobody needs to type it again.
Entering data where it is born has three results:
- One source of truth. Whatever composition the tech pack says, the card in Nebim and the e-commerce page say the same.
- Less manual moving. Copy and paste from Excel to Nebim, and from Nebim to marketplace files, shrinks; shifts and typos shrink with it.
- Early readiness. When the product is approved, the card's information is already there. Opening a card becomes an approval step, not a project.
In apparel, the product is born in product development. PLM keeps the record of that process, and fashion PIM turns the same record into channel-ready content. Nebim is the commercial link in this chain.
The Nebim + Pimland flow: how are products and variants written?
Pimland is 100% integrated with Nebim across all modules. The flow runs both ways, step by step:
- The product is created in Pimland. Style, color and size structure, composition, size chart and cost enter the record during product development.
- The variant structure is settled. Which color will be produced in which sizes is approved; color and size codes are defined once, following the brand's coding rule.
- The approved product is written to Nebim. Product and variant information is transferred to Nebim. No separate Excel file is prepared to open the product card in Nebim.
- Data comes back from Nebim. Pimland reads data from Nebim; commercial information such as stock and sales is reflected in the record product teams see.
- Content is prepared for channels. The same product record is enriched in PIM with titles, descriptions and images, and the product goes through Draft, Review, Approve and Publish.
Nobody enters the same product twice. A product born in Pimland starts its commercial life in Nebim, and movement in Nebim flows back to the record in Pimland.
What Nebim does, what Pimland adds
| Area | What Nebim does | What Pimland adds |
|---|---|---|
| Product card | The commercial record, barcode and stock structure of every variant sold and stocked | Gathers the card's information during product development and writes it to Nebim after approval |
| Variants | Stock, sales and price by color and size | Defines the color and size structure once, together with the design and pattern decision |
| Composition and care | Information stored on the product record | Consistent information from the same source as the tech pack and sample |
| Product content | Product information on the sales and stock side | Channel-ready titles, descriptions, attributes and images, with an approval flow |
| Bulk product creation | Takes products into the commercial record | Sends all approved products of the season in one flow, without Excel |
How are variants (color and size) matched?
In apparel, most errors happen at variant level. For the same style, the color design calls “anthracite” may be “smoke” for purchasing and “dark grey” for e-commerce. The size range may be S–XL in one file and 36–44 in another.
In Pimland, color and size lists are set up once with the brand's own coding rule and matched to the structure in Nebim. Matching is done once at setup; every new product in later seasons uses it. Each variant's counterpart in Nebim is clear, and stock lands on the right variant and the right channel.
This structure matters not only for Nebim but for marketplaces as well. We look at how marketplace product content is prepared in the next article in the series.
What happens to existing Nebim cards?
Moving to Pimland does not reset your product history in Nebim. During setup, existing product data is imported into Pimland and matched with the records in Nebim. Sales data from past seasons stays in Nebim and keeps feeding new season decisions.
Matching usually brings inconsistencies in older records to light as well: the same color opened under two names, cards with empty composition, products with an unclear place in the category tree. This is a side benefit of setup; cleaned data pays off both in Nebim and on the channels.
The new season is usually where the new flow begins: new products are born in Pimland, older products sit in matched form. A typical brand goes live within a few weeks.
From the field: what changed?
When product data is entered where it is born, the most visible change is speed. At a brand using Pimland, the time for a new product to be ready on all channels fell from 8 working days to 4.
The second change is effort and errors. In the same field, channel data entry went from 45 minutes to 15 minutes per product, and data errors per 100 products fell from 12 to 8. The team could spend its time describing the product well instead of moving rows.
Checklist: the 10 fields of a good product card
Having these ten fields ready on the product record before the card is opened in Nebim shortens the road to the channels:
- Style code: unique, following the brand's coding rule
- Product name: internal name and channel-facing name defined separately
- Color: color name and code, from a list every team shares
- Size range: sizes produced and the size chart
- Barcode: unique for every variant
- Composition: identical to the value in the tech pack
- Care instructions: consistent with the label
- Category and season: matching store and channel classification
- Price and cost: the link between target retail price and cost
- Image and content status: which channel the product goes to, and when
The secret of this list is not the fields themselves but that each field comes from a single source. If the same information sits in two places in two versions, the checklist stays on paper.
One step further: decision intelligence
Once the product card is ready, a new question appears: which product should go to which channel first, and where should it sit in the catalog? Pimland puts product data in order; SONROY joins it with sales and stock data from Nebim and recommends the decision.
SONROY S0 Ecom ranks the catalog with sales and stock data, scores product data quality and recommends a category ranking with its reasoning. The decision stays with the team, but ranking work that used to take days gets shorter. You can start with a single module through a suitable SONROY package.
When variant data is in order, new decisions become possible on the stock side too. The SONROY blog covers that in Store-to-store transfer decisions with Nebim stock data.
Frequently asked questions
Is the product card opened from Pimland or from Nebim?
The product is created in Pimland during product development, and when it is approved, product and variant information is written to Nebim. The card in Nebim lives on as the commercial record, so the card's information is not entered by hand a second time.
How are variants (color and size) matched?
Color and size lists are defined once in Pimland with the brand's coding rule and matched to the structure in Nebim at setup. Every later product uses that match, so each variant's counterpart in Nebim is clear.
What happens to existing Nebim cards?
Existing product data is imported into Pimland and matched with the records in Nebim. Historical sales and stock data stays in Nebim. New season products are born in Pimland and written to Nebim.
How is bulk product creation done?
The season's approved products are sent from Pimland to Nebim in one flow. There is no need to prepare a separate upload file or check rows by hand.
Do we need every module to move to Pimland?
No. There is a starting point for every budget: start with the module you need and expand as you grow. Brands struggling with product cards usually start with PLM, where product data is born, or PIM, where it is prepared for channels.
See it with your Nebim in 30 minutes
A season start without Excel is possible. In a 30-minute live demo, we will show how products and variants are written to Nebim, using one of your own products. Book a demo or message us on WhatsApp.
Integration details are on the Nebim integration page. Previous article in the series: Nebim PLM: collection, sample and cost management without replacing Nebim. Next: Nebim and e-commerce: why is marketplace product content incomplete?
