What a Configurator Project Needs to Start

Configurator projects stall in a small number of repeated ways, and almost none of them are technical. They stall because the product has never been described as a system, because nobody can state the rules with authority, or because the engineering dimensions and the marketing catalogue disagree and somebody has to decide which is true.

This guide lists what has to exist before production starts, ordered by how much damage its absence causes, and what a producer does when it is missing.

The product logic, written down

This is the document that determines everything downstream and it almost never exists in a usable form, because no other business process has required it.

It states what the components are, which ones are interchangeable, which combinations are valid, which are physically impossible, what varies at the surface and what varies in geometry, and where a choice cascades so that selecting one thing requires or eliminates another.

Without it, a studio models what appears in the brochure, which is a set of finished products rather than a set of parts that recombine. Those assets look correct and cannot be reassembled, and discovering that is a rebuild rather than a revision.

Producing this document usually falls to product or engineering rather than to marketing, and it is the single most common reason a configurator project has a slow start.

Dimensions from engineering, not from marketing

Configurator assets carry a constraint that marketing assets do not: a customer will act on what they see, so the dimensions have to be manufacturing dimensions.

That matters because the two sources frequently disagree. Marketing dimensions are rounded, sometimes nominal, occasionally aspirational. Engineering dimensions are what the part actually is.

When a configurator built on marketing figures produces a configuration that does not assemble, the error surfaces at installation rather than at review, in front of a customer, after shipping.

Establishing which source governs, in writing, before modelling begins, prevents the most consequential class of defect in this category.

Physical material references

Materials cannot be authored from a photograph on a datasheet, and this input is consistently supplied late because nobody thinks of it as a deliverable.

What is needed is a physical sample, a scan, or at minimum a controlled photograph with a colour reference, for every finish that will appear.

The reason is that a finish has properties a catalogue image does not carry: how reflective it is, how the grain scales across a large surface, how it behaves under different light, whether it is uniform or varies.

A manufacturer whose finishes have only ever existed as physical samples has a real task here, and it is worth starting it in parallel with everything else rather than discovering it mid project.

A rules owner who can decide in a day

Rules questions arrive continuously during a configurator build and each one blocks work until somebody answers it authoritatively.

Can this panel take that worksurface at that height. Is this finish available on that component or only on the family. Does selecting this option force that one, or merely permit it.

Those questions cannot be answered by the studio and frequently cannot be answered from documentation, because the knowledge lives in experienced people. What the project needs is one person with the authority to settle each question quickly and the standing to make the answer stick.

Without that person the questions queue, and a configurator project with a queue of unanswered rules questions does not slow down, it stops.

The decision about what customers are offered

A product line has every option it has. A configurator should present the options that matter, and deciding which is an editorial judgement about the product rather than a technical one.

Presenting everything is the default and it reliably reduces conversion, because a customer offered two hundred fabrics chooses none of them and leaves.

It also has a direct production cost, since every option presented is an asset that has to exist, be correct and be maintained for the life of the catalogue.

Making this decision before production, rather than presenting everything and pruning later, saves the modelling of options nobody was going to choose.

Customer facing names for internal things

Internal product vocabulary is precise and opaque, and configurators built directly on it lose customers who cannot tell what they are being asked to choose.

Finish codes, series names, component designations and family abbreviations all mean something to the business and nothing to somebody deciding whether to buy.

The project needs a translation layer: what each thing is called in plain language, decided by whoever knows how customers talk rather than by whoever maintains the part numbers.

It also means the system carries two vocabularies mapped to each other, one shown and one sent to the order system, and building that mapping late is considerably harder than building it in.

The target system for the configured output

A configured object has to become something the business can act on, and the destination has to be named before the build rather than after it.

A quoting system, an order system, a CRM, or at minimum a structured email to a named person. Any of those is legitimate. What is not legitimate is leaving it undecided, because the answer determines the output format and the integration work.

This is also the item with the longest external dependency, since the other system has its own owners and priorities, which is why it should start as a parallel workstream rather than as a final step.

A configurator that works and is not connected to anything is a common and avoidable outcome.

A decision about what happens when a rule is violated

This sounds like an interface detail and it is one of the most consequential experience decisions in the whole project, because it happens to every customer who explores properly.

A customer selects something the rules do not permit. There are three possible behaviours and they produce very different outcomes. The option can be hidden, so it never appears once it becomes invalid. It can be shown and disabled, so the customer sees it exists and cannot pick it. Or it can be selectable, with something else automatically changing to accommodate it.

Hiding is cleanest and leaves customers confused about why options vanished. Disabling is honest and requires explaining why. Auto adjusting feels magical and quietly changes something the customer had already chosen, which is the behaviour most likely to produce an order nobody intended.

There is no universally correct answer and there is a correct answer for a given product, and it has to be decided before the rules are implemented rather than discovered during testing.

A position on price visibility

Whether the configurator shows a price, and how live that price is, is a commercial decision that changes the whole integration and it gets deferred constantly.

Showing nothing is simplest and leaves the customer with the one question that determines whether they proceed. Showing an indicative range is honest and cheap. Showing an exact live price is the most persuasive and requires a real time connection to whatever holds pricing.

That third option is where most of the integration cost lives, and it also creates an obligation: a price shown is a price expected, and a configurator quoting stale figures produces a conversation nobody wants to have.

Deciding this at the start determines whether this is a visualization project with a light integration or a commerce project with a substantial one.

A named internal owner for the catalogue

This is an operating commitment rather than a project input, and it is the item most often absent from a business case.

The catalogue will change: new products, discontinued finishes, revised prices, reorganised families. Every change has to reach the configurator, because one showing a discontinued finish lets a customer configure something that cannot be bought.

That person has to exist before launch. Brands that assigned somebody first have configurators that stay accurate. Brands that did not discover the need through a customer complaint.

A decision about scope for the first phase

Launching with the full catalogue is the instinct and it is usually the wrong call, because a partial catalogue that is complete beats a full one that is partially wrong.

The workable first phase is one product family, chosen because customers ask about it most, modelled completely and correctly, with everything else clearly presented as available through the normal channel.

That ships faster, produces real engagement data, and reveals which products customers actually configure, which is reliably not what the business expected.

It also means the expensive shared work, the material system and the connection conventions, is built once and inherited by every later phase.

Evidence that customers want to configure

The central assumption of every configurator project is that configuration changes behaviour, and it is worth testing before committing rather than after.

A fast deployment on a small subset produces that evidence for a fraction of the full cost: how many visitors engage, how long they stay, whether configured sessions convert differently.

When the answer is yes, the larger investment is justified with data rather than with conviction. When it is no, the business has avoided the larger investment, which is the best possible outcome of a cheap test.

An honest account of the existing 3D assets

Most manufacturers have some 3D data and it is rarely what a configurator needs, so establishing what exists and in what state is a short task that changes the estimate substantially.

CAD models built for manufacturing are dimensionally perfect and far too heavy, and they carry internal geometry no customer will ever see.

Marketing models built for renders are visually good and frequently dimensionally approximate, and they were built as finished products rather than as components.

Either can be a useful starting point and neither is a finished input. Saying which exists, honestly, prevents a quote built on the assumption that the modelling is mostly done.

Agreement on who owns the assets

The models outlive the platform, and platforms in this category get replaced, so ownership determines what the business has in five years.

Owning the source assets in a usable format means the library can move to another platform, feed marketing imagery, and support the next product line.

Owning only access to models inside a vendor system means the library disappears with the contract, and rebuilding it is the largest cost in the project repeated.

The leverage to secure that clause exists before the work is delivered and not afterwards.

A realistic sequence

Write the product logic and decide the first phase scope, which together take longer than anybody expects because they require decisions rather than work.

Confirm the dimension source and start gathering material references in parallel, since those are the inputs most likely to be late.

Name the rules owner and the catalogue owner before production begins.

Start the integration conversation with the other system immediately, because it is the longest external dependency.

Then build the component library, then the materials, then the rules, then optimise, then test combinations rather than reviewing images.

What each missing item costs

No product logic: assets that look correct and cannot be recombined, which is a rebuild.

Marketing dimensions instead of engineering: configurations that do not assemble, discovered at installation.

No material references: finishes authored from catalogue images that do not match the physical product.

No rules owner: the project stops rather than slows.

No target system: a working configurator connected to nothing.

No catalogue owner: accuracy decays until the configurator misinforms customers.

No ownership clause: the library disappears with the contract.

Frequently asked questions

What is the first document a configurator project needs?

A structural description of the product: components, which are interchangeable, which combinations are valid or impossible, what varies at the surface and what in geometry, and where choices cascade. Without it a studio models finished products that cannot be recombined.

Why do dimensions have to come from engineering?

Because a customer acts on what they see. Marketing dimensions are rounded and sometimes nominal, engineering dimensions are what the part is. A configurator built on the former produces configurations that fail at installation rather than at review.

Why are physical material samples needed?

Because a finish has properties a catalogue image does not carry: reflectivity, how grain scales across a large surface, behaviour under different light, and whether it is uniform. Authoring from a datasheet photograph produces materials that do not match the product.

What stops a configurator project outright?

Rules questions with no authoritative answer. They arrive continuously, cannot be answered by the studio, and frequently are not documented because the knowledge lives in experienced people. Without one person empowered to settle them quickly, work queues and stops.

Should the first phase cover the full catalogue?

No. One product family modelled completely beats a full catalogue that is partially wrong, because gaps are found by customers. It also ships faster, produces engagement data, and builds the shared material system every later phase inherits.