Sell configurable products

A configurable product has no price until somebody specifies it. A hose assembly is 2.4 metres long, carries a BSP fitting at one end and a JIC at the other, has a stainless braid and a protective sleeve, and the price follows from those five answers. Today those answers arrive by telephone: the buyer describes the application, someone in the Innendienst decides whether it is buildable, looks up the surcharges and quotes it back. That conversation is the product's only ordering interface, and it runs at the speed of one person's working day.

Why this is harder than it sounds

The first mistake is made before anything is modelled, and it is a modelling mistake: treating three different mechanisms as one thing. They behave differently in the catalogue, in search, in the order line and in your ERP, and the cost of picking the wrong one is a rebuild.

Most technical assortments need all three, family by family. A range of 14 lengths × 6 pressure ratings × 3 coatings is 252 variants: large, but finite. If each already has an article number in the ERP, it is a variant problem, and modelling it as a configurator makes your catalogue harder to search and your stock figures meaningless. A cut-to-length product is the opposite: no list of SKUs can express it.

The second obstacle is that the rules are not written down anywhere. They live in the heads of two or three people who have quoted this product for fifteen years: this connection is not available above 250 bar, that coating requires a minimum length, this motor and that gearbox need an adapter that nobody remembers to add. Extracting those rules, writing them down and agreeing which of them are hard constraints and which are habits is the bulk of the project. It is not a software task and you cannot outsource it.

Then the price. A configured price is built up rather than looked up: a base price, surcharges per option, something per metre or per kilogram, a minimum charge for short lengths, a scale on quantity, and on top of all that the customer's own contract condition. Deciding where that calculation lives, in your ERP's variant configurator or in the platform, is a decision to take once. Splitting it, so that some surcharges are maintained in one system and some in the other, produces the failure mode where the shop and the order confirmation show different numbers.

Finally, the order line. A configured line is more than a SKU with a description. Production needs the specification as structured data: every chosen option, in a form the ERP can resolve to a bill of material and a routing. In the platform the configuration travels on the order line alongside the article. If your integration flattens it into free text, someone in work preparation retypes it, and you have moved the manual step rather than removed it.

One expectation to reset early: configured goods are made to order, so there is no stock figure. What the buyer needs instead is a credible lead time, and one that ignores option-driven procurement is a promise you will break.

The levers

Decide, per product family, which mechanism it needs

What good looks like: each family in your range is assigned to variants, configurator or bundle for a stated reason, and the families that are finite stay finite.

What it depends on: knowing whether the combinations already exist as article numbers in your ERP. That single question decides most cases.

1. Configurable products
2. The catalog data model
3. Plan your data model
4. Families
5. Variants and family variants

Get the rules out of people's heads and into the model

What good looks like: option groups, options and the constraints between them are written down and testable. A combination that cannot be built cannot be selected, and the buyer is told why rather than being left with a greyed-out list.

What it depends on: time from the two or three people who know the product, booked in advance. This is the longest lead time in the project and it does not compress.

1. Build a configurator
2. Compatibility and fits-with
3. Attributes and attribute groups
4. Measurements and units
5. Configurator problems

Make the price appear while the buyer is still choosing

What good looks like: the price updates as options are selected, includes the customer's contract condition, and matches the order confirmation to the cent. Where a configuration needs a human (an unusual material, a project quantity), the path to a quote is one click and not a dead end.

What it depends on: settling where the price build-up is calculated, and reading customer conditions from the system that maintains them.

1. How pricing works
2. Price models in B2B
3. Prices and your ERP
4. Pricing rules
5. Contract prices for a customer
6. Check which price a buyer sees

Carry the configuration through checkout into production

What good looks like: the order line carries every chosen option as data, your ERP resolves it to a bill of material without anyone retyping it, and the buyer can reopen last year's configuration and order it again.

What it depends on: field mapping that preserves structure, and a bill-of-material model on the other side that the configuration can resolve against.

1. The buyer's path: configure and order
2. Bills of material and assemblies
3. Request for quote in B2B
4. Handle a quote request
5. The order lifecycle
6. Field mapping

A sensible order

Phase 1: one family, every rule. Choose the family that generates the most specification calls, not the one with the largest revenue. Model its options completely, including the constraints that are currently tribal knowledge, and validate every configuration the model allows against what production will accept. Depends on rule extraction, which starts on day one. The deliverable is a working model for a narrow range and, of equal value, a written method for extracting rules from the next family.

Phase 2: price build-up and the quote fallback. Extend to two or three more families and connect the price: surcharges, length-based components, scales, contract conditions. At the same time, build the exit. The configurations you will not price automatically go to a quote with the specification attached, instead of showing a wrong number or nothing. Depends on Phase 1 proving that the rules hold; pricing an unreliable configuration is pricing a defect.

Phase 3: the hard cases. Options that depend on another family's choices, drawing or CAD output for the configured item, lead times that reflect option-driven procurement, and alignment with your ERP's own variant configurator so that both agree on what is buildable. Each of these is a project. They belong after the straightforward families are earning.

Common mistakes

• Modelling a finite range as a configurator. If every combination already has an article number, they are variants. A configurator over them costs you stock figures, search and reorder.
• Building the configurator before the rules exist. The model becomes the place where nobody's assumptions are written down, and it will produce unbuildable orders.
• Splitting the price build-up across two systems. The shop and the order confirmation will disagree, and the customer will find it first.
• Showing a stock figure for made-to-order goods. Show a lead time you can defend instead.
• No route to a human. Some configurations have to be quoted. A configurator without that exit sends the buyer back to the telephone, which is where they started.

How you know it is working

• Share of configurable-product orders specified by the customer, without an Innendienst call. The headline metric here.
• Configurations started against configurations ordered. A large gap means the model asks questions the buyer cannot answer, or ends without a price.
• Orders returned to production as unbuildable. Should be zero after Phase 1; any recurring cause is a missing rule, and belongs in the model rather than in a colleague's memory.
• Differences between the price shown and the price confirmed. Any at all means the build-up is split or stale.
• Time from request to quote for the configurations you still quote by hand. This is what Phase 2 is supposed to move.
• Specification calls per week, categorised by product family before you start, so Phase 2 has a priority list rather than an opinion.

Related goals

• Run quote-to-order, for everything the configurator does not price on purpose.
• Sell spare parts online, the other half of technical selling: identification instead of specification.
• Publish a digital product catalog, the catalogue work underneath all of it.

What you're building

A catalogue in which every technical family is either a set of real variants with their own article numbers, or a specification with written rules and a built-up price. The buyer chooses, sees their price, and the chosen options travel on the order line into your ERP as data, where they resolve to a bill of material. Configurations the rules cannot price go to a quote with the specification attached. The rules, prices and order path ship today; the guided configurator screen and the quote app are planned.

flowchart LR
  ERP["Your ERP: variant configurator, BOM"]
  subgraph CS["Commerce Studio"]
    F["Families and family variants"]
    A["Attributes with units"]
    ASSOC["Association types: compatible with"]
    PR["Prices: base, surcharges, scales, contract"]
    O["Orders: options on the line"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
    FRM["Forms: quote request"]
  end
  subgraph IS["Integration Studio"]
    WF["Workflows and mapping"]
  end
  CFG["Configurator UI (planned)"]:::planned
  QT["Quotes (planned)"]:::planned
  ERP -- "article numbers, conditions" --> WF
  WF --> F
  WF --> PR
  SF -- "specified order" --> O
  O -- "line with options" --> WF
  WF -- "order, options as data" --> ERP
  SF -- "unpriceable configuration" --> FRM
  CFG -.-> SF
  FRM -.-> QT
  classDef planned stroke-dasharray: 5 5

What you need

• Every technical family assigned to variants, configurator or bundle, with the reason written down — Configurable products
• The finite families modelled as family variants with real article numbers — Variants and family variants
• The rules for the first configurable family written down and agreed with production — Build a configurator
• Attributes with units for every option that is a measurement — Measurements and units
• A decision on where the price build-up is calculated, ERP or platform — Prices and your ERP
• Contract conditions readable for the pilot customers — Contract prices for a customer
• A field mapping that carries options on the order line into the ERP as data — Field mapping
• A route to a human for what the rules cannot price — Handle a quote request

Build it

1. List the technical families and mark each as variants, configurator or bundle, by whether the combinations already have article numbers — Configurable products
2. Pick the family with the most specification calls and book the two people who know its rules — Build a configurator
3. Model the finite families first: family, family variant, variant axes — Family variants
4. Create the option attributes with units and option lists — Attributes
5. Write the constraints down as a table and have production sign it — Compatibility and fits-with
6. Decide where the price build-up lives and record it in the ownership table — Deciding your system of record
7. Set up the base price, surcharges and scales as pricing rules or price lists — Pricing rules
8. Load contract conditions for three pilot customers and check one configured price against the ERP to the cent — Check which price a buyer sees
9. Map the order line so options reach the ERP as fields, not as position text — Field mapping
10. Place a test order and confirm the ERP resolves it to a bill of material without retyping — Test an integration end to end
11. Add a quote-request form for configurations outside the rules — Forms
12. Replace the stock figure with a lead-time statement for made-to-order families — Edit pages and blocks
13. Run the pilot, count unbuildable orders weekly, and add each cause as a rule — Configurator problems
14. Extend family by family using the written rule-extraction method — Plan your data model

Decisions you'll need to make

Related product areas

• Commerce Studio — Families · Family variants · Attributes · Measurements · Association types · Price lists · Price entries · Orders
• Experience Studio — Sites · Pages · Forms
• Integration Studio — Credentials · Field mapping · Workflows