Configurable products
Some products do not have a price until somebody has specified them. A welding torch exists in 14 lengths, 6 current ratings and 3 cooling variants. That is 252 combinations, and your PDF catalogue shows one photo and "Preis auf Anfrage". This article is about the three different ways to sell that torch, and how to tell which one you actually need.
The scenario you recognise
Your Innendienst gets a call. The buyer wants the 450 A torch, 4 metres, water cooled, with the bayonet connection. Somebody opens a spreadsheet, adds the base price, the length surcharge, the water-cooling package, subtracts the customer's contract discount, and quotes a price. Twenty minutes, and the same twenty minutes again next week for a nearly identical request.
That is not a configurator problem yet. It becomes one only when the number of combinations is genuinely too large to list, and the price is genuinely built up rather than looked up. Most companies reach for a configurator before either of those is true, and then spend a year maintaining rules for a catalogue that would have fitted in a variant table.
Configurator, variant, or bundle
These three look similar on a product page and behave completely differently underneath. Pick wrong and you will find out at the point where the order has to reach your ERP.
| Variants | Bundle / kit | Configurator | |
|---|---|---|---|
| What it is | One product model that varies along fixed axes | Several existing articles sold together as one line | A specification built from options, evaluated by rules |
| Combinations | Tens to a few hundred, all enumerable | A handful, curated by you | Hundreds to effectively unlimited |
| Does each combination have its own SKU? | Yes, one per variant | The bundle has one; components keep theirs | No — the SKU is the model, the spec is the line |
| Price | Looked up per variant | Bundle price or sum of components | Built up: base + option deltas + surcharges |
| Stock | Real, per variant | Depends on the scarcest component | Not stockable; it is made to order |
| What the ERP gets | An article number it already knows | A line per component, or one bundle article | An article number plus a specification payload |
| Maintenance cost | Low. A table. | Low. A list. | High. Rules rot, and nobody notices. |
| Use it when | Every combination is a real, orderable article | You want to sell the machine with its consumables | The article does not exist until it is ordered |
If you are on the variant side of that line, stop here and read Variants and family variants. If you want several distinct articles on one line, read Bundles and kits. The rest of this article is for the genuine configurator case.
Option groups and options
A configurator is a set of option groups, each holding options, plus rules about which combinations are allowed.
- An option group is one decision the buyer makes:
torch_length,cooling,connection_type,cable_package. - An option is one answer inside it:
4m,water,bayonet. - A group has a default — the answer chosen when the buyer changes nothing. Defaults are not cosmetic. They are the configuration your storefront shows first, they set the price the buyer sees before touching anything, and in practice a large share of orders never move off them. Make your defaults the variant you actually want to build.
- A group is required or optional. Required with no default means the buyer cannot see a price until they choose. Use that only where you genuinely must not guess — a thread size, a voltage.
Groups have an order, and the order carries meaning. Put the decision that constrains everything else first. If the current rating rules out half the cooling options, ask for the current rating first, so the buyer never sees a choice they are about to lose.
Constraint rules
Rules are what stop the configurator from selling something you cannot build. Four shapes cover nearly everything:
| Rule | Reads as | Example |
|---|---|---|
| Requires | If A, then B must be chosen | Water cooling requires the coolant hose package |
| Excludes | If A, then B is not available | 300 A excludes the 8 m torch neck |
| Implies (auto-set) | If A, then B is chosen for the buyer | The bayonet connection sets the adapter automatically |
| Only-if (visibility) | Show group C only when A | The gas lens options appear only for gas-cooled torches |
Two practical rules about rules.
Write them as a table before you build them. One row per rule, in the language of the person who knows the product. A rule set that lives only in the configurator is a rule set nobody can review, and the people who can review it are in production, not in e-commerce.
Beware of rules that fight each other. If A requires B and B excludes A, the configurator has a state it can enter and never leave, and the buyer sees "no valid configuration" with no way forward. That is the single most common configurator support ticket, and it is covered in Configurator problems.
How a configuration becomes a price
The price of a configured product is built, not looked up. In practice it is four layers:
- The base price of the model — the list price of the torch with all defaults. This comes from your normal price list; see How pricing works.
- Option deltas — a surcharge or a discount per chosen option. Absolute
(
+ 85.00for water cooling) or relative (+ 4 %for the special coating). - Quantity-driven surcharges — the ones that are a function of a number the buyer entered rather than an option they picked. Cable at €12.40 per metre, coating at €38.00 per m². These are where rounding errors hide.
- Customer conditions — the buyer's contract price or discount, applied to the built-up price. Which layer it applies to is a decision, not a detail: a discount on the base price only, and a discount on the whole configuration, are different numbers, and your Innendienst already knows which one is right. See Contract prices for a customer.
Decide the order of these four and write it down. Every disagreement about a configured price you will ever have is a disagreement about the order.
The configuration on the order line
This is the part that decides whether the configurator is a toy or a working sales channel. A configured line is not an article number. It is an article number plus the specification, and both have to survive the whole way to production.
A configured order line carries three things:
- A reference to the model — the SKU that identifies which configurator was used.
- A human-readable description — the specification written out, so that the order confirmation, the delivery note and the invoice all say "WT-450, 4 m, water-cooled, bayonet" and not "WT-450".
- A machine-readable payload — the chosen options as structured data, so your ERP can turn them into its own characteristics rather than parse a sentence.
In the Revenue Cloud this is real today: a cart line and an order line both have
a type of product, configuration or custom, and lines of type
configuration carry a configuration payload alongside the SKU, quantity
and price. The line also has a position text field for the description that
belongs on the printed document. What that means for you is that a configured
line is a first-class order line — it can be partially delivered, cancelled and
returned like any other, and it appears in
the order lifecycle exactly where you
expect it.
configuration line type and its payload are part of the order model now.
The configurator itself — option groups, rules and price build-up maintained
from a Cockpit screen — is a planned capability. A product today is simple,
model or variant; there is no configurable kind. If you are planning a
configurator project, the work you can do now is the modelling work in
Build a configurator, and it is
most of the work either way.Where quotes come in
Not every configuration should end in a cart. In special-purpose machinery and in anything where the specification needs engineering sign-off, the configurator produces a request, not an order. The buyer configures, saves, and submits; somebody checks feasibility and price; the answer comes back as a quote.
That is not a failure of the configurator. It is the correct flow for a class of product, and it is far better than a "Preis auf Anfrage" button, because the request arrives fully specified instead of as three sentences in an email. See RFQ in B2B and Handle a quote request.
Next
- Build a configurator — turn this into an option matrix and a rule table.
- The buyer's path: configure and order — what the buyer sees, and what your ERP receives.