Product Data Readiness Decides When a 3D Configurator Can Launch
A configurator reads every variant in your catalogue, every hour. The launch date follows the state of those records: SKU, price, a unique identifier and your official naming. Here is what to check before the build starts.
A configurator launch date is usually set from the visible side of the project: 3D assets, interaction rules, front-end integration. The date that holds is set somewhere quieter, in the product records the configurator reads every hour.
One prospect described the expectation plainly: "In my eyes if a product is active on the website, it should be able to be built within the configurator and then the delivery information pulled accordingly as we do anyway when added to basket." That is a fair description of how a configurator behaves once the data is in order. Getting the catalogue into that order is the part that moves launch dates.
What product data readiness means
A configurator reads your product catalogue. It pulls the same records your storefront pulls and applies your rules on top: which modules combine, which fabrics belong to which frame, what a configuration costs, and what the buyer is told about delivery. Readiness is the state where every record the configurator touches carries the fields it needs, in the naming your own teams already use.
Three things separate this from an ordinary catalogue tidy-up. The configurator reads every variant, so a field that is optional for merchandising becomes required. It reads them continuously, so one incomplete record affects the whole import. And it reads them against a rule set that already exists inside the company, usually in someone's head and in a few email threads.
What the configurator reads from every product record
On Shopify the requirements are specific and documented. Before a product carries the PLANNER tag, every variant needs a unique SKU, a price, a unique Planner ID metafield and a configured Planner Features metafield, and the product status has to be Active. Those five conditions are the entry ticket into the configurator.
The same shape of requirement applies on other platforms. We integrate with Shopify Plus, SAP Commerce, Salesforce Commerce and custom back ends, and each integration needs a stable identifier per variant, a price it can read, and a structured description of what the variant is. Where those three exist, add-to-cart flows, inventory checks and pricing run inside your existing checkout. The same records feed the item overview, total dimensions and lead time the buyer sees while configuring, which is one of the places a 3D configurator overlaps with CPQ software.
Alongside the commerce record sits the geometry. Most brands arrive with part of it in place: "We do have 3D files for our products, some revit as well" is a common answer at the start of a project. Asset quality sets the visual result. The product record sets whether the asset can be reached at all.
Where the weeks actually go
The delay pattern is documented across our own onboardings. A developer checks the shop, finds variants with an empty field, reports it to the project manager, the project manager relays it to the customer, the customer fixes part of the list, and a new round begins. On one Shopify onboarding that loop ran to 26 comments over three months for tables and chairs alone. Ten onboardings show the same shape.
The work inside a round is small: add a SKU, set a price, fill a metafield. Each round still costs a week or more, because it crosses three people and two systems before the next check runs.
This is why a launch plan built on 3D delivery alone tends to slip. The 3D work is scheduled from day one and tracked against a date. The data rounds are discovered one at a time, and each discovery restarts the loop. Planning both streams together is the practical difference between a 13-week configurator timeline and an open-ended one.
What incomplete data does to a live configurator
After launch the same requirements stay live. When a product receives the PLANNER tag while a SKU, a price or an identifier metafield is still empty, the importer fails on its next cycle and keeps failing every hour until the tag comes off. The failure covers the whole catalogue, so one new product can take the configurator's data out of sync for every buyer using it.
Naming produces a quieter version of the same effect. "Polished Aluminium" in the configurator and "Chrome" in the ERP describe one finish, and a buyer who meets both will ask which one is arriving. A colour code written 0114 in one system and 114 in the other raises the same question. British and American spellings and capitalisation differences reach us the same way, as customer feedback after launch. Each correction takes 15 to 30 minutes per batch once someone has traced which system holds the original name.
Both cases describe the product record as the interface between your systems and the configurator, and it holds that role for the life of the integration.
Getting the data ready before the build starts
Four steps cover most of the ground, and all four can run before a single asset is delivered.
- Run the field check yourself. Export the catalogue and confirm that every variant intended for the configurator has a unique SKU, a price and a unique identifier. Duplicate identifiers are the most common single finding, and they surface fastest in a spreadsheet.
- Send the official naming sheet. An ERP export of product, colour and material names, in the exact form your organisation uses, becomes the source of truth for the configurator. It settles the naming questions before they reach a buyer.
- Write the rules down. The combination logic already exists. One prospect described a modular system in a single sentence: start from a base module with a gable on both sides, then add one module at a time to the left or the right. Putting that on paper early lets the build start on your own logic.
- Scope the assets separately. Asset availability and format drive timeline and cost on their own track. Raise what exists, and in which format, early enough that the two streams can run side by side.
Product data readiness has the longest lead time on a configurator project and the least visibility. Brands that run the field check and send the naming sheet before the build starts move from asset delivery straight into integration. The same hours get spent either way. The difference is whether they arrive as one block of work or as a round every week.