The buyer paths

The buyer's path: configure and order

What a configured order looks like end to end.

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 typeproduct, 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 lineContainsUsed by
skuThe model, WT-450Everything that indexes by article
name and position_textThe written specification: "WT-450, 4 m, wassergekühlt, Bajonett"Order confirmation, delivery note, invoice
configurationThe chosen options as structured dataYour 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.

Never let the specification live only in a comment field. A configured line whose spec is a free-text note in the order header will be retyped by somebody in your Innendienst, and retyping a 12-option specification has a defect rate you do not want to measure. If the payload does not reach production as data, you have automated the quoting and kept the error.

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