Why Manufacturing Industries Need Smart Configuration – Not Just AI

Manufacturing Companies Still Rely on Legacy Quoting Solutions

Despite the hype around connected data, AI and process automation, many – if not the majority – of manufacturing companies still rely on quoting processes built more than a decade ago. A “simple” customer quote often requires a lot of manual steps, data transfer between frontend and backend systems by hand, and tacit knowledge. Engineers validate configurations manually, product managers email Excel files back and forth, and sales teams try to guess which technical features best fit the customer’s needs.

Many of these setups are powered by legacy configurators — complex, legacy engines built in e.g. ERP systems, originally designed for engineers rather than salespeople. Others depend on homegrown Excel tools or custom applications nobody can support anymore. In both cases, the result is the same:

• slow quoting lead time and inconsistent configurations & pricing
• high dependency on individual experts’ knowledge
• limited visibility between product, pricing, and customer data & high MDM efforts

And while AI promises to revolutionise how companies sell and deliver, these rule-heavy legacy environments are nearly impossible to enhance with AI. Without structured logic, actions & APIs, and standardised data, AI models have nothing consistent to learn from or act on. In other words, trying to “add AI” on top of a legacy quoting tools only adds more steps to the chaos – not providing consistent results aligned with the company’s offering.

How Modern Product-to-Cash Accelerates Business

Fortunately, new technologies — like Salesforce Revenue Cloud’s Advanced Configurator, guided selling, and composable omni-channel solutions — are changing what’s possible. Specifically, Revenue Cloud Advanced configurator allows manufacturers to move from legacy tools and rule-based configurators to constraint-driven logic – and what’s even better, connecting configuration logic, pricing, assets, and all the customer 360 data to enhance quoting experiences.

And it’s not only about better user experience and the beauty on the surface — it’s potentially a rebuild of how products are sold:

• Product and pricing changes flow automatically across systems from product management via sales to order processing and beyond
• Salespeople are guided through the configuration process, answering questions on customer needs instead of selecting the technical details
• Customers’ assets (both tangible and intangible) and entitlements are tracked in the system and connected to the sales process to allow upgrades, renewals, self-service, etc.

And there will be no article without highlighting the possibilities with AI – after these building blocks are in place, there are countless possibilities to further enhance the experiences with AI: for example, we might cut the lead time by 50 % and improve the customer need match of the quote by 75 % by building the basics right, then by incorporating AI, we can expect further improvements on the same magnitude, effectively decreasing the workload to just ~25 %. However, the key point here is that to achieve the full benefits of AI-based solutions, the basics and data must be in shape.

Accuracy and Scalability to Complex Configuration with Constraint-Based Engine

There are two generic types of configurators available on the market today: rule-based configurators are the most used by tools like previous generations of Salesforce CPQ, Epicor, and Logik.ai. Constraint-based configurators, such as the new Revenue Cloud Advanced Configurator and Tacton, work differently. While constraints are technically a form of rules, the philosophy behind them is very different.

Rule-based configurators typically follow an IF → THEN → ELSE logic. For example:

• If engine = V8, then exhaust = dual pipes.
• If engine = electric, then exhaust = none.

This model is simple to understand and easy to start with. You define a condition, an outcome, and the system follows it. However, as product complexity increases, rule-based logic becomes difficult to maintain. Each new product option or dependency introduces more rules — and those rules must be executed in a certain order. If two rules contradict each other, the configurator must know which one wins. Without careful design, the “last rule” might silently override others.

Constraint-based configurators work differently. Instead of running through a list of rules, they evaluate constraints recursively — continuously checking which combinations are valid and which are not. Think of it as the difference between giving a long set of instructions versus setting boundaries and letting the system figure out the rest.

A constraint could say:

• The total number of axles must be between 2 and 5.
•  If drive type = 6×4, then at least two axles must be driven.
•  If the lifting axle is selected, total axles must be ≥ 3.

The configurator then ensures that all constraints are satisfied simultaneously, not one by one.

If a user changes a component that violates another constraint, the system automatically suggests valid alternatives — or blocks the choice. Constraints can also be bi-directional. This means if the user selects a certain lifting axle, the configurator can automatically infer which drive type is required — without writing a separate reverse rule.

This recursive and balanced approach makes constraint-based configurators both more accurate and more scalable as product complexity grows. The same logic can be implemented with considerably less rules. However, a downside of constraint engines is that the configurations are more abstract – it is harder to get started with them, but when up to speed, constraint-based engines are typically superior.

Building a Configurator with Revenue Cloud

So how does it work in practice in Revenue Cloud? Let’s dig a bit on the surface of advanced configuration engine by going through an example configuration – a Karhu Truck which in the imaginary universe competes with a couple of known brands in the industry (Karhu is Finnish and means Bear). Why truck? Well, since I was a kid, I’ve always liked big machines.

Typical design and configuration process progresses as follows. In the following, we will go through a simplified product configuration journey – concentrating on the product creation and skipping for example product classification and attribute management.

Simplified Product Configuration Process

We’ll start the product configuration journey by building the sales bill of materials in the product catalogue – resembling what we want the sales to sell. This is the core structure of the product without any other logic than the hierarchy – if we had PLM integrations, this structure might come from PLM; however, it’s good to consider that in case the technical structure is not supporting sales, one should consider revising it in the configurator. In the Salesforce product catalogue, we could also define cardinality on this level, but I prefer to keep logic in one place and define that in the constraint model. The following example demonstrates our BOM for the Karhu Truck.

Modelling Sales BOM with Product Catalogue

After building the BOM, we connect product attributes to it – both technical attributes and customer facing guided selling attributes.

Now, our configuration is ready to be sold; however, it does not yet have any embedded intelligence, and sales will be responsible for the validity of the configurations created. Hence, let’s create a constraint model which is the heart of the product configuration. We’ll continue by importing the product structure with its variables to the constraint model – later when introducing changes, we can sync the product catalogue to constraint model.

Importing the Product BOM and Attributes to Constraint Model

After importing our product and the structure, it’s time to create our configuration logic. Here we have two options to build our logic:

• Visual builder – easy to use and relatively low learning curve solution to get quickly started building the constraints when you don’t yet command the syntax, or do this just occasionally anyway.
• CML Editor – pure code-based solution to write more advanced constraints – this is the editor I personally prefer, since when you know the commands, it’s a lot faster.

Envisioning the future, I would guess that there will be AI solutions available sooner than later to write constraints faster, which will greatly improve the efficiency of configuration process. While waiting for that, I’ve been building a personal MS Copilot based assistant by injecting instructions, documentations and examples of constraints to an AI agent. While it does not yet work perfectly since it’s not actually trained for the purpose, just instructed, it’ll already speed up writing the constraints.

The following examples demonstrate both approaches with the example of setting up the guided selling attribute constraints. Note that these simple examples could also be written by just explicit rules, and the power of constraint engine comes into play whit more complex scenarios.

Building Constraints with Visual Builder

Building Constraints with CML Editor

Modelling the full product configuration might be a time consuming process – for simple products, one might be able to create a constraint model in matter of minutes, but for complex configurations such as the example truck, it might take days to just come up with requirements and weeks to build the actual model – hence it is important to consider the complexities already in the planning phase of the project in order to be able to plan the budgets and timelines accordingly.

Some questions to consider during this process to make it faster and more consistent include, for example, the choices on:

• Should we first think of how we classify our products – then harmonise and categorise our product attributes so they can be easily reused across the offering?
• Should we build one large constraint model to incorporate our offering, or maybe one model for each of the products?

There’s a lot more questions, but often its better to get started and take them one buy one when they come. However, the answer to the harmonisation is definitely yes – and to the latter question the truth is somewhere in between.

Let’s fast forward to the end of this process where we get to explore and adjust the user experience. Following picture demonstrates our customer need based configuration for the Karhu Truck. At this point in time, our truck model is still missing the pricing logic – but when ready, we would naturally see the effects of each choice to the pricing of the solution on the fly.

Product Configuration User Experience

The ambitious goal of the Karhu truck company is to build a configurator which enables even inexperienced sales people to make customer need selections which will drive the whole configuration logic, setting the default configuration just with few clicks – then sales reps can naturally override the system selections.

Revenue Cloud comes with standard templates for the product configuration end-user experience, with some possibilities for adjustment. The great thing is, the standard experience is enough for most of the MVPs at least – however, when exposing the configurator to partners, or especially customers, one might want to consider using thecomposable APIs and a customer user experience.

Take Your Quoting to Today’s Standards and Beyond

The journey toward intelligent, AI-assisted sales doesn’t start with algorithms — it starts with structure. Manufacturers who still depend on legacy quoting tools can’t unlock the benefits of automation, AI, or connected data until their configuration models are solid, constraint logic is defined, and processes are unified end-to-end.

Salesforce Revenue Cloud’s Advanced Configurator represents more than a new feature — it’s a shift in how manufacturers can design, sell, and deliver complex products with accuracy and speed. When configuration logic, pricing, and customer data work seamlessly together, one can introduce more value adding capabilities with for example AI on top and take the efficiency on whole new level. However, even without AI we’re speaking potentially huge gains in efficiency and quality.

Those who start modernising their configuration now will not only shorten quoting cycles but also prepare their organisation for the next wave of intelligent automation. The best day to start was 5 years ago – second best is today.

If your company is exploring how to modernise quoting, harmonise configuration logic, or simply wants to understand where to begin, reach out to us. We’re happy to share our learnings from real manufacturing projects and help you build the foundation for smart configuration.