The buyer's path: configure and order
A configured order looks like an ordinary order until you look at the line. This article follows one from the buyer's first click to what lands in your ERP, and names the four places it usually goes wrong.
The buyer's path
1. They open the model. WT-450, one product page, with the configurator
rather than an add-to-cart button. The page opens on the
defaults and shows a price
immediately. A configurator that shows "Preis auf Anfrage" until every group is
answered has thrown away its main advantage.
2. They answer the groups in order. Each answer narrows the next. Options excluded by a rule are shown as unavailable with a reason — "not available with 300 A" — rather than silently removed. Buyers who see options disappear assume the site is broken; buyers who see a reason learn your product.
3. The price updates as they go. Base, option deltas, quantity surcharges, and their own conditions, recalculated on every change. Show the build-up, not just the total: a buyer who can see that water cooling costs €85 can make a commercial decision. A buyer who sees only a total that moved by €85 phones to ask why.
4. They save it. A configuration is worth naming and keeping — "Brenner Linie 3, wassergekühlt". Saved configurations are reordered, sent to a colleague for approval, and quoted against. In practice this is what turns a configurator from a novelty into a channel, because the second order of the same specification takes ten seconds.
5. They add it to the cart, or request a quote. Which of the two depends on the product and sometimes on the configuration. A specification that needs engineering sign-off should route to a quote request, fully specified, rather than being blocked with a contact form.
6. They check out. From here it is an ordinary order — addresses, payment terms, the buyer's own order number, approval if the customer runs one. See The order lifecycle.
What the order line carries
This is the part that matters operationally. A configured line is not just a SKU.
In the Revenue Cloud, a cart line and an order line each have a type —
product, configuration or custom — and a line of type configuration
carries a configuration payload alongside the usual SKU, name, quantity,
unit price and totals. Three pieces of information travel together:
| On the line | Contains | Used by |
|---|---|---|
sku | The model, WT-450 | Everything that indexes by article |
name and position_text | The written specification: "WT-450, 4 m, wassergekühlt, Bajonett" | Order confirmation, delivery note, invoice |
configuration | The chosen options as structured data | Your ERP, production, and any reorder of the same spec |
The line also carries its own unit_price and line_total, computed from the
build-up at the moment of ordering. That is deliberate: the price of a
configuration is a fact about this order, not a lookup that should be redone
later when the surcharge table has moved on.
Because it is an ordinary order line in every other respect, it behaves normally: it can be partially delivered, cancelled or returned, and it appears in Process an order alongside everything else.
What your ERP receives
Your ERP has its own way of expressing a configured article — SAP calls them characteristics and values, other systems call them features or variant codes. The integration's job is to translate your option codes into theirs.
- Agree the mapping per option group, before launch, as a two-column list. See Field mapping.
- Send the specification as data, not as a sentence. The written description travels too, for the documents, but it is not what production works from.
- Decide what happens to an option the ERP does not know. Rejecting the order is honest; silently dropping the option is a wrong machine. Make it an error you can see — see Monitor your syncs.
- Decide who owns the price. If the ERP recalculates a configured price on receipt and disagrees with the shop, you have two prices on one order and a conversation with the customer. Settle which one is authoritative in Deciding your system of record.
Configured products and quotes
A large share of configured business goes through a quote, and that is correct rather than a shortfall. The buyer configures, saves and submits; sales checks feasibility, adjusts the price, and returns a quote; the buyer accepts and it becomes an order.
Two things make this work:
- The quote line keeps the configuration. Converting a quote to an order must carry the specification across intact, not re-enter it. See Convert a quote to an order.
- Sales can change the configuration on the quote, within the same rules the buyer had. An Innendienst that has to reject and re-request because the buyer chose the wrong connection is slower than the phone call it replaced.
See RFQ in B2B for the shape of that process.
What to check
- A configured order end to end, on a real customer account. Configure,
cart, check out, and then read the order in Order Management › Orders: the line type
is
configuration, the description is complete, and the payload holds every chosen option. - The document says the specification. Open the order confirmation. If it says only "WT-450", the position text is not being filled and your customer cannot check their own order.
- The ERP received the options. Look at the record on their side, not at the success message on yours.
- The price the buyer saw is the price on the order. Compare the total shown at the last step of the configurator with the order line.
- A second order of the same saved configuration is identical. Different price, same options, is a surcharge table that changed; different options is a bug.
Next
- Configurator problems — when it does not work.
- Check which price a buyer sees — for price disputes on configured lines.