CPQ (Configure, Price, Quote): What It Does, Where Its Limits Are and How to Choose

CPQ connects three steps that tend to drift apart when companies sell variant-rich products: the technically valid configuration, a defensible price and a quote ready to send. For manufacturers of variant-rich machines, plants or vehicle components, that means a valid quote in minutes where manual processes often take days. The more useful question, though, is not what CPQ can do. It is where the category ends, what data quality it silently assumes, and why the vendor market currently carries a selection risk that did not exist two years ago.

What is CPQ?

CPQ stands for configure, price, quote: putting the product together, working out the price and producing the quote. These are the three steps between a customer enquiry and a binding offer. If you sell variant-rich products, you first assemble the right variant, then price exactly that variant and finally send out a quote with all the technical details. CPQ handles this in one rule-based pass, for your own sales team, for partners or directly for end customers.

Gartner’s market definition for CPQ applications lists automatic pricing, the selection of product options and features, proposal generation including the negotiation of terms, and order placement among the mandatory features (Gartner Peer Insights). The heart of it is the rule set: it decides which features can be combined at all. Everything else builds on that.

Configure, Price, Quote: the three steps in detail

There is a technical reason why the rule set so often becomes the bottleneck. Many configurators implement their rules imperatively, as a hard-coded sequence of checks. Knowledge about how things fit together then lives in the code. Once the original developers or product engineers have left, it is very hard to reconstruct. A declarative rule set, by contrast, describes only the constraints themselves, in a defined form and without program logic. It stays readable, domain experts can maintain and extend it without programmers, and it does not depend on whether the configuration later runs on the web, on the desktop or on mobile.

Which companies benefit from CPQ?

A usable selection grid is the product-process class, meaning how much of an order is already fixed before the order arrives. It says more about CPQ fit than revenue or headcount. The breakdown below follows the systematics commonly used in order fulfilment, as applied for instance by Dr. Wüpping Consulting for CPQ system selection.

The most common selection mistake in this table concerns expectations. A company with a high ETO share introduces CPQ assuming it will automate almost all of its quote output, and ends up automating only the standardisable fraction. The project is then written off as a failure even though the result matches the product programme. Establish upfront what share of your incoming orders can be represented by rules at all, and derive the project target from that.

Selecting CPQ: seven steps

Sequence matters, because the first three steps decide the outcome and the last four only decide the vendor.

1. Determine your product-process classes. What share of incoming orders is ATO, CTO, CTO+ or ETO? That defines the realistic degree of automation.
2. Audit the data model. Do standardised feature sets and value lists exist? If not, that is your first project, not the CPQ. New configuration projects almost always start with master data consolidation. A CPQ solution can bring together information from several spreadsheets or from SAP, but that does not replace consolidation.
3. Fix data ownership. Exactly one leading system and one accountable role per data class, in writing. How that distributes across PLM, ERP, PIM and MDM is covered in the article on variant management.
4. Delimit system roles. Who produces which bill-of-materials view (sales, engineering, manufacturing), where the pricing logic sits, where costing sits, where the rule set lives.
5. Clarify integration depth. Bidirectional to ERP and CRM, with concrete objects and triggers, not as a connector logo on a slide.
6. Assess vendor stability. Product roadmap, portfolio overlaps after acquisitions, and whether the configuration model can be exported.
7. Define the operating model. Roles, effort and approval paths for maintenance after go-live, with names and capacity.

CPQ, product configurators, guided selling and ERP variant configuration: where are the boundaries?

These four terms are used almost interchangeably in the market, and that is precisely where bad investments come from. The distinctions, one by one:

What is the difference between CPQ and a product configurator?

In practice the boundaries blur, but in the narrower sense they can be drawn clearly. A product configurator offers an interface where users select feature values and arrive at a valid product variant. It usually ends with a configuration code the customer passes on to sales, or a summary as a PDF. That is where its job stops. Everything after that runs manually or through a custom-built follow-on solution, and that is its weakness.

CPQ carries the process further. At its centre are price calculation based on the individual configuration and the quote that follows. On top of that come functions that are easily overlooked during selection: discount logic, approval workflows, quote versioning, validity periods, management of quotes and opportunities, and handover to CRM and ERP. The dividing line therefore sits not in the C but in the P and the Q.

The opportunity in particular is underrated in many comparisons. A CPQ process often starts when a sales rep creates an opportunity for a specific customer based on CRM data. Configuration and quote are then attached to that opportunity, which gives an overview of all of that customer’s enquiries. In an industrial setting with frequent repeat orders that is especially valuable, because earlier configurations stay easy to find.

CPQ solutions for variant-rich industrial products typically include a configuration capability. That does not mean each one ships a full technical product configurator, and conversely, far from every configurator is CPQ. How a configurator works technically, and what the high-level configuration approach means, is explained in our article on the product configurator.

The practical consequence: if quotes are calculated in spreadsheets and discount approvals travel by email, CPQ is a serious candidate. Whether it takes a full CPQ system depends on product complexity, pricing logic, approval depth and integration needs. Many solutions on the market can only be used as a complete system. Modular solutions, on the other hand, let you integrate individual functions, for example configuration and price calculation inside an existing web shop that already handles ordering and customer accounts. In simpler cases proposal automation, CRM workflows or a pricing solution will do. If your prices are fixed, your discounts rule-based and your quotes a single page, a configurator is enough, and you save yourself a multi-year project.

Is guided selling the same as CPQ?

No. Guided selling is an interaction pattern, not a system category. It describes leading a user to a suitable solution through needs-based questions instead of making them work through a technical feature list. That can happen inside CPQ, but equally in a web shop, in a product finder or in an advisory tool with no configuration logic whatsoever. Vendors like to list guided selling as a CPQ feature. The more important question sits behind it: which questions can a customer answer, what must sales add, and where is engineering expertise unavoidable? Leave that split unresolved and the result is a questionnaire nobody completes.

Where does the web shop end and CPQ begin?

A shop sells what is unambiguous in price and logistics. CPQ produces what only becomes unambiguous after rule evaluation. As soon as discount approvals, framework agreements, delivery commitments or technical clarifications enter the process, the checkout is the wrong place.

That does not make them opposites, because the two combine well. Internal sales works with the full CPQ solution, with extended rules for experts where needed. The web shop runs a subset tailored to end customers. That does not necessarily mean two separate rule sets: usually both share a large common rule base and differ in only a few points. For the architecture that leaves one relevant question: do shop and CPQ share the same rule model, or do you maintain two? The answer determines your operating cost for years. A product configurator run headless can serve both interfaces from one rule set.

Orientation does not necessarily need a separate dialogue up front. A configurator can already provide a lot of it, for example through sensible default selections. How far that goes, and when a dedicated needs-based dialogue makes sense, is covered in the article on guided selling in sales.

Two deployment models, two very different projects

In practice CPQ is run in one of two ways, and that choice determines effort and risk more than the product selection does.

The order is rarely a matter of taste. Start internally and you test the rule set and the pricing logic in an environment where a mistake costs nothing beyond a follow-up question. Start externally and you test the same things in front of customers. Two models do not mean two systems, incidentally. There is often an internal and an external configurator that share most of the rule set. Ideally only the interface changes, but usually a few role-specific rules are added.

What each party gets out of it

• Sales mainly gains speed. For a highly complex product with a datasheet of more than 600 pages, a valid configuration takes a great deal of expertise, and even experienced specialists keep looking things up. Mistakes still happen, so rounds of clarification with engineering or production follow. From a verified rule set, the valid quote is ready in minutes. That time saving is the easiest metric to evidence and therefore the best basis for a business case.
• Certainty comes on top. A quote produced from a verified rule set does not have to be checked by engineering, and the discount stays inside an approved range.
• The company can sell more. At one Viamedici customer, certain product functions had not been offered at all, because configuring them by hand was too complex and too error-prone. With the rule set they could be configured reliably, sales sold higher-priced units, and revenue rose noticeably.
• The customer gains reliability. A configured quote with a bill of materials, drawing and certificates can be verified. Without accompanying content from a PIM system it stays a price.
• Engineering gains quiet, but only after the rules have been captured. Before that the project costs them time, and that belongs in the plan.

Where CPQ projects fail at the handover

A bill of materials (BOM) is the structured list of all assemblies, components and quantities a product consists of. With variant-rich products, every configuration generates its own BOM, and sales, engineering and production each need it in a different form.

So a configuration does not produce one result but three views of the same product. Skip that distinction and you will notice it with the first order that gets stuck between sales and production.

• The sales BOM describes what the customer ordered, in the customer’s language and structure. It is the basis of the quote.
• The engineering BOM describes how the product is built technically, with design logic and assembly structure.
• The manufacturing BOM describes in what sequence and at which site the product is produced and assembled.

Translation work sits between these views, and it is the reason a CPQ project fails at the interface rather than at the configurator. For selection, exactly one question therefore matters: which of the three views does your CPQ produce, which does it receive, and who is accountable for the translation in between? How the underlying bill-of-materials logic is built, and how to spot a missing rule set, is covered in the article on variant management.

Five patterns behind failed CPQ projects

Five patterns recur across the case descriptions and consulting analyses reviewed during research:

• Unconsolidated master data. When the same product information sits in several sources at different states, the project models the contradiction instead of the product. Consolidated master data is a prerequisite, not a project outcome.
• Unresolved data ownership. Four departments maintain the same feature, often independently in their own systems, for example in several spreadsheets with different states and scope. Nobody decides which value applies. After go-live the systems drift apart within months.
• Product rules in program code. An individually designed configuration application is not a problem. A configurator can be as individual as the product it represents, from corporate identity to user guidance. It becomes critical when product rules are coded directly into the application. Interface and rule set belong strictly apart, otherwise every extension becomes a development project and every release gets expensive.
• Missing user adoption. Field sales keeps calculating in spreadsheets because the tool is slower than their experience. Response times in a configurator are not a comfort topic; they decide whether it gets used. User guidance matters just as much: people moving from the freedom of a spreadsheet to an application with fixed steps will only adopt it if those steps fit the way they work.
• No operating model. After the project nobody asks who maintains rules, features and prices. That is exactly where good systems turn bad.

The last point is solvable organisationally. The role permanently responsible for structure, rules and approvals is usually the data steward. Without it, the rule set becomes a museum.

Why CPQ fails without clean product data

CPQ calculates with features, values and relationships. It does not create them. If the same technical feature carries three different names across three systems, if units are mixed, or if feature values exist as free text, no rule set can be modelled that survives longer than one release. That is why CPQ projects surprisingly often fail not at the configurator but at the data quality of the underlying product data. Viamedici has seen several projects fail for exactly this reason, because master data could not be consolidated sufficiently. What helps is project leadership that brings everyone involved together, makes the importance of product data quality clear and settles the next steps bindingly.

In practice this means the data model comes before the rule set. Which system leads for which data depends on the target architecture: a PIM system often supplies the sales- and channel-specific product data, meaning feature sets, value lists, translations, media and approved states that feed both the quote document and the configuration interface. Technical configuration attributes and rule models, by contrast, may originate in PLM, ERP or Master Data Management. Only after that does the question of which rule engine sits on top become meaningful. Postponing data cleansing and modelling into the implementation phase does not move the risk, only the moment it becomes visible.

In Viamedici projects our PIM system often provides the data foundation, because much of the required information already lives there. It is not a mandatory prerequisite. Our CPQ software builds on the existing data foundation, and missing information can be added in the PIM or directly in the CPQ platform. The rule set itself rarely lives in the PIM. Product relationships are often already stored there, though, and they are imported automatically and used as the basis of the rule set. The CPQ solution then adds technical rules from engineering, for example.

Pricing is not costing

Practically every market article treats the P in CPQ as discount logic. In machinery and plant engineering the harder task is a different one: what does this specific configuration cost us? Pricing is a commercial decision with room to negotiate. Costing is a calculation across material, production time, bought-in parts and overheads, and it depends on data that lives in the ERP and changes continuously.

CPQ that only handles prices produces quotes with an unknown margin. During selection, clarify explicitly whether a contribution-margin view per configuration is possible, and where the cost rates come from.

Metrics: how do you measure success?

Almost every vendor promises faster and error-free quotes. That only becomes verifiable with figures you collect before the project. A workable set:

The CPQ market in 2025 and 2026: consolidation as a selection risk

Anyone building a longlist right now should know that the vendor market has shifted considerably over the past eighteen months. Three developments matter for selection:

• Salesforce CPQ is end of sale, according to consistent market reporting since 19 March 2025. Salesforce itself confirms the status on its product page as end of sale and explicitly not end of life: new customers can no longer license it, existing customers continue to receive support, and new functionality is built on Revenue Cloud Advanced. Salesforce names no end-of-life date (Salesforce).
• Conga completed its acquisition of the PROS B2B business on 2 February 2026. Conga states its own customer base at more than 10,000, which the PROS business now builds on (Conga).
• ServiceNow announced the acquisition of AI CPQ vendor Logik.ai in April 2025, with the stated aim of embedding configuration and quoting into its own workflows. For companies on a ServiceNow landscape that changes the options. For everyone else it shows the direction of travel, with CPQ increasingly becoming part of larger suites rather than a standalone product.

For practical purposes that adds one uncomfortable but sensible question to every shortlisted vendor: which product in your portfolio will you still be selling in three years, and what happens to my configuration model if you stop selling it?

Market-size forecasts vary widely between research houses. More useful for an investment decision than any absolute figure: Mordor Intelligence identifies manufacturing as the largest adopter segment, at around 32 percent of 2025 revenue (Mordor Intelligence).

Conclusion

CPQ is not a tool that tidies up an unstructured sales process. It is the commercial layer on top of consolidated master data and a robust data model. In that sequence, quote turnaround shortens substantially and transparency over what is actually being sold comes with it. Reversed, the exercise automates your own data problems. The three questions that belong at the start have nothing to do with software: how consolidated is our master data, who owns which data class, and who maintains the rule set in five years? How to get the underlying variant complexity structurally under control is covered in our article on variant management.