CPQ Software: What It Does, Where Its Limits Are and How to Choose One

CPQ software connects three steps that tend to drift apart in variant-rich sales processes: the technically valid configuration, a defensible price and a quote ready to send. For manufacturers selling configurable machines, plants or vehicle components, that is the difference between quoting in hours and quoting in 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 software?

CPQ stands for Configure, Price, Quote. CPQ software guides sales teams, partners or end customers through assembling a configurable product against a rule set, calculates a valid price from that selection and produces a quote together with the technical specification. Gartner describes CPQ application suites as an integrated set of applications supporting configuration, pricing and quote generation in solution and negotiated selling, typically combining a pricing engine, proposal generator, quoting system and a rules or constraint engine (Gartner IT glossary).

The rule engine is the actual core. It decides which combination of features is technically permissible at all. Everything else sits on top of that.

Configure, Price, Quote: the three steps in detail

Which companies benefit from CPQ software?

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 buys CPQ software 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 software: 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.
3. Fix data ownership. Exactly one leading system and one accountable role per data object, 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 software, 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 software and a product configurator?

A product configurator ends at the valid specification, often with a list price attached. CPQ software also runs the commercial process: discount logic, approval workflows, quote versioning, validity periods, handover to CRM and ERP. The dividing line therefore sits not in the C but in the P and the Q. 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. 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 software, 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. 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.

Where buyers need help before they configure anything, that is the job of guided selling in sales.

Two deployment models, two very different projects

In practice CPQ software 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: what works is one rule set with two roles and two interfaces.

What each party gets out of it

• Sales mainly gains certainty. A quote produced from a verified rule set does not have to be checked by engineering, and the discount stays inside an approved range.
• Internal sales gains time, because follow-up questions and rework disappear. This is the easiest metric to evidence and therefore the best basis for a business case.
• 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 configurable 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:

• Missing modularisation. Making an unstructured product programme configurable simply models the chaos. Modularisation is a prerequisite, not a project outcome.
• Unresolved data ownership. Four departments maintain the same feature and nobody decides. After go-live the systems drift apart within months.
• Customising instead of configuring. Every special requirement gets coded. By the next release the project is no longer release-capable, and that becomes 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.
• 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 software fails without clean product data

CPQ software 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.

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. At Viamedici, configuration logic and product data model therefore sit on one platform: our CPQ works directly on the same data model as our PIM system, which removes the duplicate maintenance of features and value lists that is otherwise standard.

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 software 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 software is not a tool that tidies up an unstructured sales process. It is the commercial layer on top of an ordered product programme 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 modular is our product programme, who owns which data object, 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.