Example of implementing an online configurator in sales

A customer doesn't want to send three emails, wait for a quote, and guess whether a particular combination is even feasible. They want to see the options, pick the right solution, and get a clear next step. That's exactly why a case study on rolling out a web configurator is most relevant for businesses selling products or services with multiple variants, add-ons, dimensions, or pricing rules.

A web configurator isn't just a nice add-on to a product page. When properly designed, it becomes a sales tool that guides the customer to the right product, saves the sales team repetitive work, and gives production more useful and accurate data. When poorly designed, it can create confusion, wrong expectations, and extra administrative work. The difference lies in preparing the business logic before development even starts.

A case study: rolling out a web configurator for a custom product

Picture a business making custom outdoor shading systems. Their offer includes several types of shades, different widths and heights, colors, control types, additional mesh screens, motors, and mounting options. Up to now, a customer submits a general inquiry on the website, and a salesperson then gathers basic details by phone and manually puts together a quote.

A process like this works fine as long as inquiries are few. As the business grows, predictable problems show up: responses take too long, data is incomplete, salespeople repeatedly explain the same constraints, the final price surprises the customer, and transcription errors can carry all the way through to production.

A configurator changes this journey. The customer first selects the type of shade, then enters dimensions, picks a color, a control method, and add-ons. As they make selections, the system only shows them options that are technically compatible with the chosen product. If a particular width requires a different mechanism, or if a chosen color isn't available for a specific model, the configurator says so immediately — clearly and without technical jargon.

At the end, the customer doesn't necessarily get a final online price. For more complex products, it's often more sensible for them to submit a structured inquiry with a precise specification instead. That way, the sales team doesn't start from a blank form — they receive a ready-made configuration: dimensions, selected options, an estimated price, notes, and contact details.

What a business needs to sort out before development

The biggest mistake is starting a project with the question of what the configurator should look like. Appearance matters, but it's only the final layer. First, you need to sort out the rules by which the product is actually made and sold.

A business needs to be able to clearly answer which choices a customer can actually make, which combinations aren't allowed, and what the consequences of each choice are. Does width affect price? Does choosing a motor change the delivery time? Are certain colors only available for a specific model? Does a size above a certain threshold require an extra bracket? If rules like these only exist in salespeople's heads or in disorganized spreadsheets, they need to be written down and confirmed first.

A good starting document isn't a fifty-page technical specification. A clear matrix of products, options, constraints, and pricing rules is often enough. What matters is that sales, production, and whoever's responsible for quoting all contribute to it. Each department sees a different part of the problem, and the configurator needs to connect all three.

Price isn't always the first number a customer needs to see

Businesses often expect a configurator to automatically calculate a final price for every product. That's an excellent solution for a standardized offer with clear rules. For project-based sales, complex installation, or products where the final cost also depends on a site visit, transport, and special requirements, though, a publicly displayed price can do more harm than good.

In cases like this, a middle-ground solution makes sense: the configurator shows a starting price, a price range, or simply tells the customer the configuration is ready for an individual quote. What matters is that the system doesn't promise something the business can't later deliver on. Clearly set expectations build more trust than a seemingly precise number.

The user journey needs to be short and confident

A customer doesn't think in product codes, manufacturing steps, or internal material labels. The configurator needs to speak their language. Instead of "select drive mechanism," a question like "How would you like to control your shade?" may be clearer. With every choice, they should see a brief explanation and, when it helps with the decision, a visual preview too.

A good journey doesn't mean showing the customer every option at once. Quite the opposite. The system should ask questions in a logical order, with each next step building on the previous choice. That leaves less room for error, keeps the interface clear, and doesn't leave the customer feeling like they're filling out a demanding technical form.

Mobile users deserve particular attention. A large share of inquiries start on a phone, even if the purchase is completed later on a computer. Selectors, price tables, and visual previews need to work well on a smaller screen. If a customer can't comfortably enter dimensions or compare two options, the configurator loses its main purpose.

Where a configurator delivers the most business value

The most obvious benefit is faster inquiry collection, but that's not the only advantage. Structured input means the business receives comparable data. A sales manager can more easily see which combinations generate the most interest, production can spot frequently chosen materials sooner, and marketing gets better insight into what customers are actually looking for.

With a well-connected system, data from the configurator also transfers into a CRM, accounting software, an ERP, or a production system. This matters especially when a business receives a large volume of configurations. Manually retyping data is slow and introduces errors exactly where the customer expects precision.

This connection doesn't need to exist in the first version. If a business is still testing market interest, a thoughtfully built initial configurator that ends in an inquiry submission can be a better decision than a large integration project. Once the tool proves it delivers quality sales leads, it can be upgraded with automated data transfer and more advanced rules. This approach limits upfront risk without limiting future development.

Custom development is an advantage when the offer isn't generic

Pre-built plugins can work well for simple products with a handful of attributes, such as color, size, and quantity. The problem arises when the rules have many exceptions, when pricing isn't linear, or when the configurator needs to communicate with an external business system. At that point, a generic solution quickly turns into a patchwork of workarounds, add-ons, and limitations.

Custom development lets the user experience adapt to the actual sales process, not the other way around. A configurator can include special pricing rules, separate paths for B2B and retail customers, saved configurations, generating a PDF specification, or an approval process before an order is submitted. It also matters that the admin panel stays simple: the team needs to be able to change a color, a price, or availability without needing a developer for every minor change.

At Moxy Web, we build projects like this around the client's business process. That means we first determine what the configurator needs to solve for the customer, for sales, and for the internal team, and only then choose the scope, integrations, and technology that make business sense.

How to know whether a project succeeded

Don't measure success by click count alone. More useful questions are: Is the sales team receiving more complete inquiries? Has the time to a first quote shortened? Are there fewer revisions? Have more submitted configurations converted into orders? Also track where users give up. If a lot of customers abandon the process at entering dimensions, the instructions might be unclear, or it might be asking for too much data too soon.

A configurator isn't a project you publish and forget about. The offer changes, customers ask new questions, and internal processes evolve. That's why it needs reliable maintenance, security updates, and occasional content or functional adjustments. The best configurators get better over time, because the business genuinely learns something from how it's used.

Start with one product or one product group, where manual work is heaviest and the rules are clear enough. If you make the decision easier for the customer and remove repetitive steps for your team, the configurator won't just be a feature on your website. It will become a more organized way of selling.