A product configurator that gets price and item number right

A buyer needs to order a product with several variants. The motor, material and connection all have to fit together. Without a product configurator, emails go back and forth and the salesperson checks every combination by hand.

What most often breaks is the price and the item number. A polished selection interface does not help if the discount comes from the wrong list or the order cannot be created. The configurator is only as accurate as the rules, prices and item numbers behind it.

That makes it a transactional part of the purchase. It has to decide which choices are valid, which price applies and which details move on to a quote or an order.

What a product configurator does for your sales

Think of an order form with a built-in check. Anyone who fills in a field that does not fit with the others is stopped before the form is sent. A product configurator does the same thing digitally. The customer chooses properties, variants and options. The system only lets through combinations that can be manufactured and delivered.

Statistics Sweden's regulation SCB-FS 2024:27 includes companies' ability to let visitors customise or design goods or services on a website when it measures digital sales. The definition is clear. A product configurator gathers the customer's choices around a product or service. It is more than an image viewer.

The same regulation separates web sales from EDI sales. In web sales, the customer orders through a website or app. EDI is based on order messages from the customer's business system. The configurator can be the step before a quote, an order or that flow. It sits between product data and the business transaction.

A configurator that only swaps images removes no manual step. The salesperson still has to interpret the choice, calculate the price and create the item. The error is found late, often after the order has already been promised.

Write down the three decisions the configurator should make for you: which choices are valid, which price applies and which item number is created. Those three lines guide the type, the data and the ongoing management later on.

Four types of product configurator and when each one fits

The type depends on which decision the customer has to make. How it looks in a demo is a weak basis for the choice.

A rule-based configurator fits when the components have hard dependencies. A motor of a certain size only works with certain gearboxes. The rule hides or blocks the invalid choice. The pitfall is ownership. If no named person approves changes, the rules drift apart after the next product launch.

Guided selling fits when the buyer lacks the technical map. One question at a time leads to a product or a package. That takes simple cases off the salesperson's desk. The risk is that the question flow promises a solution that production or the warehouse cannot deliver. The questions therefore have to point to the same rules as the technical model.

A visual configurator fits when appearance drives the purchase, for example colour, shape or placement. The customer chooses in an image or a preview. The image has to follow the rules. Otherwise the customer can save a combination that looks good in the drawing and is then rejected by the workshop.

A CPQ-style configurator turns the choice into a quote. Price, terms and delivery date come with it. It fits projects and deals with customer-specific prices. The pitfall is a pricing rule that has not been checked against the business system before the quote goes out.

Pure types are rare. Say a pump manufacturer has technical dependencies between the pump housing, motor and connection. The reseller needs questions that lead to the right choice. Then the rules carry the technical blocks and guided selling carries the dialogue. Choose the type based on the customer's decision.

How the price is set when the configuration becomes a quote

Price is the layer that most often breaks. Every choice can change the price. Some choices also change the discount, shipping terms and lead time. Three layers need to be kept apart.

The list price is the base price for the variant. The customer-specific price applies to a particular customer or agreement. The discount applies to an agreement or a period and is added on top of the right base. If the layers get mixed up, the configurator can show an amount that finance cannot invoice.

A miscalculated price damages trust in the whole supplier, even when the product itself is right.

Automation needs three answers before the build starts. Is there a price list per variant? How is an option without its own price handled, for example through a surcharge or a fixed fee? Who approves an exception when the customer wants a price outside the list?

A quote tool that receives the configuration needs the same pricing logic. Otherwise the quote recalculates the amount and the customer sees two figures.

Map the three price layers before anyone starts building. Mark every choice that lacks a price. The empty lines are the work that remains.

Who owns which data in PIM and ERP

The configurator reads from two places. Every piece of data needs a master. Otherwise the same product gets two descriptions and the customer gets a price that cannot be invoiced.

PIM is the master for copy, attributes, images and documents. They are enriched once and then sent to the website, portal and resellers. The business system is the master for item numbers and core data, because finance, stock and orders need the same source. Customer-specific prices and pricing logic also sit there, so the price in the configuration is the same price that gets invoiced. Stock levels and lead times come from the same place, so the configurator does not promise more than production can deliver. The configuration rules belong in a versioned rule file with a named owner, so no rule can be changed without anyone noticing.

This is what the error looks like when ownership is unclear. A dimension is updated in PIM, but the same field remains in the business system's item register. The website shows the new value, the quote reads the old one and the order takes a third figure from an older export. Item numbers and prices should therefore sit in the business system, for example Business Central or Monitor, and that split has to be decided before the integration is built.

Every choice in the configurator should map to item numbers, components, price terms, stock logic and the details for the quote or order. Then the website's product logic does not drift away from order handling.

Attributes need stable IDs. A shared model for product information management lets copy and attributes be reused on the web, in quotes and in production.

Test the split on a real variant. Choose a product and follow every field from display to invoice. A field that can be changed in two places has no master, and a line without a named owner is a decision you have not made yet.

What this approach requires of you and when it does not fit

The configurator is only as good as the data it reads. You need to own three things before a supplier starts building: an appointed rule owner, a product model with clean attributes and an agreed route for exceptions, so that an exception does not become a silent rule.

The rule owner approves new combinations and saves the version. The product model states which attributes exist, which are mandatory and which exclude each other. The exception process states who may let through a choice the rules block, and how that choice is documented.

The Swedish Agency for Digital Government points to WCAG 2.1 as the central reference for digital accessibility. In a configurator, that means keyboard navigation, clear error messages linked to the right choice and a chance to review the result before the quote or order. If users do not understand why a choice is rejected, the load on sales and support grows. Accessibility then also becomes a check of the business logic.

A different way of working fits better in three situations. The product has few variants and a simple price list is enough. The rules change every week, so a rule file goes out of date too quickly. The business system cannot deliver stock data in time, and the configurator would promise stock it does not have. In those cases, a simpler quote form or a sales call can give the same result at a lower cost.

Write down the name of the rule owner, the list of attributes and the route for exceptions. If any of them is missing, it is too early to build.

Ongoing management after go-live decides the real cost

The cost does not stop at go-live. Rules, prices and integrations change when the range, the business system and the web platform are updated. Someone has to own that work every month.

Four items keep coming back. Rule maintenance covers changed rules, new variants and checks for invalid combinations, and is owned by your rule owner with support from the supplier. Price updates keep price lists, customer-specific prices and discounts in step with the business system, and need a fixed routine on your side. The integrations with PIM and the business system have to work after every change and sit with the supplier under the contract. Upgrades are about compatibility when the platform or the configurator gets a new version, and sit with the supplier when there is a management agreement.

A calculation that only includes the build cost will be wrong. Maintenance only shows when a new version breaks a rule, or when a price change does not reach the configurator. The same risk applies to an integration with the business system. The call can work on launch day and fail at the next release.

Put ongoing management in the budget as a recurring item, alongside the build cost.

Glanser Care is a contracted responsibility at a fixed monthly cost that covers version tracking, compatibility through upgrades, maintenance of the integrations with the business system and bug fixing. If your own IT team already handles ongoing management, that setup may be unnecessary. Work out the annual cost of the four items before the contract is signed.

How to roll out a configurator in stages

The value grows when the configurator follows the whole value chain, from the customer's choice to the production documents. When those documents are created directly from valid choices, fewer manual reinterpretations are needed further down the line.

Start with one product family or one market as a pilot, because errors hide in a full range. Then define the attribute model for filtering, variants and dimensions. The configurator can only choose from attributes that exist.

Next, connect PIM for the content and the business system for item numbers, prices and stock, and test three configurations against a real quote case. Then build the rule flow and let production or engineering review all invalid combinations before customers see them.

Launch first to a limited group, for example resellers, and measure how many quotes need correcting by hand. Expand the range and functions once the pilot's errors are under control.

Each step comes before the next because otherwise the error spreads. The attributes have to exist before the connection. The connection has to be right before the rules are reviewed. The rules have to hold before a larger group uses them.

List the product families that produce the most invalid combinations. That list is your pilot.

The supplier's answers show who maintains the rules

Ask for three answers in writing, and compare them with how you have split master data.

The first question is about rule ownership. Who approves a new rule, and how is the version saved when a rule changes after a product launch? A clear answer shows that the supplier expects ongoing management. A weak answer, for example that the rules sit in the configurator without versions, shows that the maintenance will land with you.

The second question is about pricing logic. How does a configuration produce a price that matches the business system when an option has no price of its own, and what happens to a quote created before a price change? The answer shows whether old quotes are protected or quietly recalculated.

The third question is about operational errors. How does the configurator behave when the business system does not respond, for example a fallback for stock data and a clear signal to the customer? The answer shows whether you risk promising stock you do not have.

Put the answers next to what you have decided about configuration rules and pricing. If the owner, version and source are missing from the answer, the setup is not ready to be built.

Check your current solution before you choose

Many companies already have a quote process, a PIM or a portal. Map which item numbers and pricing rules sit in the business system, where the enriched content lives and which integrations carry the flow today. Bring the person responsible for the business system and the person responsible for pricing, because both are needed to answer the questions about rules, price and operational errors.

In a 72-hour analysis, you set aside two hours, and within 72 hours you get an inventory of functions and integrations, a functional specification, a prototype and a complete cost picture with a timeline, free of charge.