Configure. Price. Quote. End-to-End.
Configure correctly. Price profitably. Quote with confidence.
From customer needs and Guided Selling to quotation and order.
We connect product logic, pricing, approvals, documents and result objects in one consistent end-to-end CPQ process.
IMPACT
Speed
Move faster from enquiry to a valid, priced solution.
Pricing quality
Manage pricing logic, margins, discounts and approvals transparently.
End-to-end consistency
Derive quotations, orders, documents and bills of materials consistently.
CPQ is more than a configurator.
CPQ is more than a configurator and more than a quotation generator. A robust CPQ process brings three disciplines together on an equal footing: Configure translates customer needs into a valid technical solution, Price turns that solution into a transparent and commercially viable price, and Quote combines the solution, price, visualization and documents into a reliable quotation.
For highly configurable industrial products, Configure, Price and Quote must all build on the same approved product logic. Guided Selling and configuration open up the solution space; pricing connects pricing strategy, configuration-dependent price components, costing integration, conditions and approvals; Quote makes the selected solution understandable and transfers it consistently into the quotation, documents, order and downstream processes. Typical triggers include long quotation lead times, early engineering involvement, inconsistent pricing and document versions, or missing result objects for order and BOM creation.
Configure – Price – Quote as one end-to-end chain
The three disciplines use the same approved product logic and together extend through to the order, documents and bill of materials.
Customer Need → Guided Selling → Configure → Price → Quote → Approval → Order → 100% BOM
Guided Selling – from customer needs to the right solution
Product configuration does not begin with a tool. It begins with the question of how customer requirements can be translated into the right solution. Guided Selling uses clear market-oriented language: application, required performance, operating conditions and preferences. The technical product logic translates this input into characteristics, options, modules and rules.
For experts, detailed technical configuration may be appropriate; other users need guided questions, recommendations, meaningful defaults and, where useful, step-by-step visualization of the solution. Not every user needs to see the same configurator, but every path must access the same approved solution space.
Configure – create valid products and solutions
Product and data foundation
A structured portfolio, configurable product structure and clear product data model form the foundation. Characteristics and values must be named clearly, variant objects versioned and rules testable. Reusable technical solutions are modelled so that they retain the same business meaning across sales, engineering and production.
Process Classes and scope
Depending on the business and product model, we distinguish between MTS, PTO, ATO, MTO, CTO, CTO+ and ETO. These classes are not a linear maturity sequence; they describe different combinations of make-to-stock, selection, assembly, manufacturing, configuration and engineering. For the CPQ scope, the key questions are how much of the solution is generated through rules, when engineering becomes involved, which result objects are required and which systems participate.
System and multi-line-item configuration
For machines, plants and technical systems, configuration often extends beyond a single product. Multiple line items, assemblies, accessories, services or subsystems must be sized together and checked for cross-system dependencies. We clarify which relationships should be controlled by rules in the configurator, which calculations are required and how system-level result objects are generated.
CTO+, parameterization and ETO content
Not every customer requirement fits entirely within a predefined variant space. In CTO+ processes, rule-based configuration, technical calculation, parameterization and limited engineering content can work together. For ETO content, we define clear handover points, reference solutions and feedback mechanisms so that special solutions do not create uncontrolled, permanent complexity.
Technical calculation and result objects
Sizing, performance curves, performance data and derived parameters belong at the point in the process where they are needed for selection, validation or downstream use. We deliberately separate product logic, calculation and result objects, and define which values are displayed, stored, versioned and transferred to quotation, order, documents or bill of materials.
User views and configuration depth
Customers, sales, expert sales and engineering require different views and degrees of freedom. Not every user needs the same interface or the same technical detail, but all roles must access the same approved product and rule base. This allows guided selection, expert configuration and detailed technical work to be combined in one consistent process.
Rules, validity and testing
Rules must ensure technical validity while remaining understandable, maintainable and testable. We structure dependencies, constraints, derivations and defaults so that business functions can introduce changes in a controlled manner and test edge cases with regression safety.
- Characteristics, options and value ranges.
- Constraints, dependencies and derivations.
- Defaults and preferred solutions.
- Technical feasibility and process boundaries.
- 10–20 representative edge cases per product family, plus regression testing for changes.
Price – pricing logic, architecture and governance
Pricing is not a downstream calculation step. For complex products, price is shaped by product configuration, cost basis, market, customer value, contract, service scope and deal context. We therefore clarify the pricing logic first and only then define its technical distribution and implementation.
1. Pricing approaches and hybrid pricing logic
Industrial products are rarely priced using a single method. Cost-plus pricing derives prices from a defined cost basis plus mark-ups or target margins. Characteristic- and option-based pricing assigns prices to performance characteristics, options, capacities, software or services. Value-based pricing focuses more strongly on customer benefit, segment, application or the economic value of the solution. Hybrid models combine these approaches deliberately – for example, a cost basis plus characteristic-dependent price components, supplemented by market, segment and value elements.
2. Pricing architecture, data ownership and system roles
The pricing architecture is defined first: list or base prices, price books, regions, currencies, customer groups, contracts and validity periods. Each price type needs clear data ownership. ERP can maintain master prices, conditions and costs; CPQ can orchestrate configuration-dependent pricing, deal simulation, margin visibility and approvals; CRM can provide customer- and opportunity-related information. The actual distribution depends on the existing system landscape and must be decided and tested deliberately.
3. Configuration- and characteristic-dependent pricing
Options, characteristic values, performance classes, capacities, functions, software, services, accessories and technical surcharges can all influence price. The crucial point is that the same product logic must not be rebuilt independently in configuration and pricing. Pricing rules must be based on approved configuration results and stable product objects.
4. Mark-ups, discounting, margins and approvals
Mark-ups and discounting are different control mechanisms and should not be mixed. Mark-ups increase reference or list prices, for example on the basis of region, market, application, customer segment, technical configuration, risk or service content. Discounting reduces prices based on customer conditions, quantities or the project and deal context. This requires clear discount corridors, roles, escalation levels and approvals. Margins should be visible where decisions are made, with clear handling of cost versions, surcharges, overrides and exceptional approvals.
5. Connect costing and pricing cleanly
Costing is not a configuration function. It uses the configuration result and adds material, manufacturing, procurement, project or service costs. The sales price, in turn, is not necessarily cost plus mark-up. Cost-plus, characteristic-based, value-based and hybrid pricing logic can operate in parallel. What matters is a clear separation of roles and a defined connection between configuration result, cost information, pricing logic and margin visibility.
6. Price waterfall and traceability
A transparent price waterfall shows how the net quoted price is built up. The exact structure varies, but typically brings together base price, option and performance surcharges, market and customer conditions, project or deal discounts and approvals. The objective is not a specific user interface, but traceability: who changed which price component, why, and with what effect on margin and outcome?
Quote – quotation, documents and visualization
Configuration and pricing together create a reliable quotation. This includes a transparent structure of line items and scope of supply, price components, alternatives, technical and commercial documents, terms, versions and approval status. Quote is more than document generation: the customer must be able to understand the selected solution, its scope, variants and commercial implications; internally, the quotation and configuration must remain reproducible.
Quotation structure, line items and alternatives
For multi-line-item or plant quotations, product configuration, prices, optional services and alternatives must be brought together in a consistent quotation structure. This includes main and secondary line items, variant comparisons, optional packages, scopes of supply, exclusions and technical and commercial dependencies between line items.
Visualization and configuration-driven representation
Depending on the product and sales process, visualization can make selected options, technical characteristics, scope of supply, performance limits and installation situations easier to understand. This may include 2D or 3D representations, configuration-driven drawings, layouts or schematic views. The key is not visual effect for its own sake, but consistent derivation from the approved configuration state and unambiguous assignment to the quotation.
Documents, variants and reproducible quotation versions
Quote logic includes country-, market- and customer-specific texts, technical data sheets, drawings, contractual annexes and digital quotation formats. Configuration, pricing status, visualization and documents must be versioned together and remain reproducible. When changes occur, it must be clear which product, rule and price versions formed the basis of a specific quotation and what changed between quotation versions. This logic does not end when the order is won: order changes, variations and change orders must remain connected to configuration, price, documents, approvals and BOM versions.
Order, result objects and bill of materials
A CPQ process is only truly end to end when its result can be used unambiguously downstream. CPQ does not need to generate the manufacturing-ready bill of materials itself in every architecture model. What matters are reproducible result objects – such as configuration ID, line items, characteristics, documents, price components and approval status – together with a defined transition for deriving an order-specific 100% BOM from 150% or maximum structures. Depending on the system landscape, this derivation may take place in CPQ, PLM, ERP or a coupled process; business responsibility and traceability must be clear. We explore the underlying structural, object and system architecture in greater depth under Product Structures · Data Models · System Architectures.
Integration and operations
PLM, CPQ, ERP and, where relevant, CRM and PIM need clear roles and interface principles. These include data flows, triggers, monitoring, error handling, versions, release calendars and regression testing. The architecture must work not only in the happy path, but also under changes and edge cases. We address the business allocation of product models, eBOM, mBOM, maximum structures and result objects in greater depth under Product Structures · Data Models · System Architectures.
Configuration Lifecycle – models, validity and releases
A configuration model is not a one-off implementation object. Products, options, rules, prices, documents, visualizations and interfaces change across releases and product generations. Modelling, testing, validity, release, regression and traceability must therefore be part of the CPQ concept from the outset. Historical configurations must remain reproducible; reconfiguration, order changes and change orders, retrofit, replacement and service quotations require transparent product, rule, price and BOM versions.
System selection, PoC and testing
Criteria lists alone do not determine a CPQ selection. We compare solutions using realistic use cases and edge cases: complex configurations, pricing, discounts, approvals, documents, BOM derivation, changes and integration. A PoC demonstrates technical feasibility; a pilot demonstrates operational viability.
Operating Model, KPIs and governance
- Roles for product models, rules, pricing, documents and integrations.
- Change, approval, testing and release processes.
- Monitoring and error handling.
- Training and business enablement.
- KPIs: quotation lead time, error rate, engineering content, hit rate, discount rate, margin, reuse and change effort.
Outcomes
- One consistent, approved solution space for Guided Selling, configuration and engineering.
- A transparent pricing architecture with clear data ownership, margin visibility and approvals.
- Reproducible quotations with consistent line items, documents, visualizations and versions.
- Defined result objects for order, downstream processes and derivation of the 100% BOM.
- A robust operating model for maintenance, testing, release, monitoring and continuous improvement.
Typical project pattern
Starting point
Quotations take too long, configuration, pricing and documents follow different logic, engineering is involved too early and margins become transparent only at a late stage.
Approach
Clarify scope and process classes, structure the product and rule model, define the pricing architecture and result objects, and build realistic end-to-end test cases and a pilot.
Impact
Faster and more reliable quotations, fewer errors and less engineering effort, transparent margins and a consistent handover to order, documents and bill of materials.
Frequently asked questions
How do we distinguish MTS, PTO, ATO, MTO, CTO, CTO+ and ETO for CPQ?
By defining clear process and scope boundaries for each product family. The classes describe different combinations of make-to-stock, selection, assembly, manufacturing, configuration and engineering. The key questions are which share is created through rules in the approved solution space, when engineering becomes involved, which result objects are required and which systems participate.
Where should configuration logic reside across CPQ, PLM and ERP?
That depends on the product structure, configuration depth and process pattern. Guided Selling and high-level sales logic may reside in CPQ, while PLM or ERP maintains logic closer to structures and bills of materials. What matters is shared semantics, unambiguous validity and no uncontrolled duplication of rules.
How can configuration and quotation be handed over reliably to order and bill of materials?
Through defined result objects and a reproducible configuration ID. Line items, characteristics, documents, price components and approval status are transferred so that the order and 100% BOM can be derived unambiguously in the intended target system or coupled process.
How do we verify that a CPQ solution fits both the business and technical requirements?
Not through criteria lists alone. What matters are realistic use cases and edge cases for Guided Selling, configuration, pricing, documents, changes, integrations and BOM derivation. A PoC proves feasibility; a pilot shows whether modelling, operations and governance are sustainable.
Assess your CPQ, configuration or end-to-end challenge
In an initial conversation, we clarify the current situation, product and process scope, configuration and pricing logic, result objects, system landscape and key risks. We then assess whether the right starting point is a focused review, a target model, a PoC or a pilot.