CPQ software: definition, how it works, and how to choose

What is CPQ software?

CPQ stands for Configure, Price, Quote.

The concept is simple:

• Configure: determine what can be sold together and under what conditions;

• Price: calculate the price based on rates, volumes, options, discounts, or other rules;

• Quote: generate a consistent proposal from this configuration.

The difference from a simple quote generator is significant.

Generating a PDF from opportunity details is relatively easy. The difficulty arises when the system must first determine what the sales representative can sell and at what price.

Let's take a service company that markets three levels of support.

If each offer has a fixed price and a few options, a CRM with a quote template may be more than enough.

If the price depends on the number of sites, the volume processed, the selected options, the commitment duration, and a discount subject to approval, the quote becomes the result of a set of rules.

It is this logic that a CPQ structures.

What problem does a CPQ actually solve?

A CPQ is not primarily used to make prettier quotes.

It is used to make the way the offer is constructed reliable before the quote is generated.

In many companies, this logic is gradually scattered:

• pricing grid in Excel;

• sales information in the CRM;

• discount rules in a document;

• approvals requested via email or Slack;

• exceptions known only to a few people.

This way of working can be perfectly acceptable as long as the volume and complexity remain low.

The problem appears when exceptions become the norm.

A sales representative applies an old rate. A mandatory option is forgotten. A discount exceeds the authorized threshold. Two incompatible services appear in the same quote.

At this point, the problem is no longer document-related.

It has become a commercial system problem.

Quote complexity is not the right criterion

A ten-page quote can be very simple to produce if it relies on fixed rates.

Conversely, a one-page proposal may require:

• several compatibility rules;

• a calculation based on volume;

• a conditional discount;

• a minimum margin;

• manager validation.

It is this decision-making complexity that a CPQ seeks to absorb.

CRM, automations, or CPQ: what do you actually need?

Not all companies that produce quotes need a CPQ.

The right level of architecture depends mainly on the complexity that the system actually needs to manage.

CRM + quote template

This is often the best starting point.

The CRM contains the company, contacts, opportunity, and necessary sales information.

Based on this data, the system generates the quote.

An agency selling a fixed-price audit, monthly support, and a few clearly priced options probably has no reason to add a CPQ.

Simplicity is an advantage here.

CRM + automations

A few additional rules do not automatically justify new software.

For example:

• volume discounts starting from a certain quantity;

• additional fees based on an option;

• maximum discount based on the sales representative's role;

• validation required beyond a threshold.

If these rules remain few in number and easy to test, they can sometimes be managed directly within the CRM.

CRM + business costing tool

Then there is an intermediate zone.

The CRM remains responsible for the commercial relationship and pipeline, while a dedicated tool calculates the pricing.

For a service company, the price might, for example, depend on:

• the estimated number of days;

• the profiles mobilized;

• external costs;

• the target margin;

• delivery options.

An Airtable base or a small internal application can sometimes absorb this logic very well.

But only as long as the system remains understandable and maintainable.

CRM + CPQ

A CPQ becomes interesting when the rules themselves constitute a real system.

The sales representative should no longer have to memorize all dependencies, manually check combinations, or recalculate the price.

The CPQ carries this logic.

The new technological layer therefore absorbs a complexity that is already present in the business.

Adding a CPQ to manage five simple rules probably creates complexity. Adding a CPQ to centralize a logic that has become difficult to maintain can, on the contrary, eliminate it.

What signs show that a CPQ is becoming necessary?

There is no specific number of products, sales representatives, or quotes at which a CPQ becomes mandatory.

However, certain signals are telling.

Offers have many dependencies

Some options require other components.

Others are incompatible.

The configuration sometimes depends on the segment, contract, or customer context.

If the sales representative must know all these rules by heart, the system becomes fragile.

Pricing depends on many variables

The rate is no longer simply:

quantity × unit price

It depends, for example, on volume, duration, different tiers, bundles, options, or service levels.

The problem appears especially when these rules interact with each other.

Discounts and exceptions require validations

A one-time discount is easy to manage.

Multiple levels of discount based on margin, product, contract amount, or sales representative role are much less so.

The system must then distinguish what can be approved automatically from what constitutes a true exception.

Pricing knowledge depends on a few people

If producing a complex proposal always requires the intervention of the person who "knows all the rules," the company already has a configuration and pricing logic.

It is simply not yet formalized in a system.

Errors have a real financial impact

When contracts become large, a poor configuration or wrong price can cost more than the time required to produce the quote.

The reliability of the process then becomes an architectural criterion in its own right.

How does a CPQ integrate into your sales architecture?

A CPQ generally does not replace the CRM.

The two have different responsibilities.

A simplified architecture may look like:

CRM → CPQ → quote / signature → contract → billing

Specifically, the CRM handles:

• the company;

• the contacts;

• the opportunity;

• the pipeline;

• the commercial context.

The CPQ handles:

• the catalog;

• authorized configurations;

• pricing rules;

• discounts;

• approvals;

• the final offer.

Once the offer is accepted, other systems can take over.

This is where CPQ connects to the broader Quote-to-Cash process.

Quote-to-Cash covers the transition from the sales proposal to collection: quote, contract, eventual delivery, billing, and payment.

CPQ represents only one part of it.

Define which data is the source of truth

Adding a CPQ quickly raises a question more important than the integration itself:

which system is responsible for which data?

For example:

• CRM → opportunity;

• CPQ → validated configuration and price;

• signature → signed contract;

• business tool → delivered or billable items;

• billing tool → invoice and payment.

Trying to copy all data into all tools rarely makes the system more reliable.

It is better to identify the information actually needed at each step and limit synchronization to what serves a decision or action.

This is also one of the principles of a maintainable RevOps architecture.

Can you build your own CPQ in Airtable or directly in your CRM?

Yes, sometimes.

But the right question is not:

"Is it technically possible?"

It is rather:

"Is it still the simplest architecture to understand, test, and maintain?"

When a light solution is still relevant

Airtable can, for example, serve as a costing tool when a company has:

• a limited catalog;

• a few calculation variables;

• a logic specific to its business;

• few approval levels;

• a volume that is still manageable.

In an architecture using Attio, Attio can remain the CRM while Airtable handles this costing logic.

The responsibilities are then distinct:

Attio → sales relationship and opportunity

Airtable → business costing

This architecture is not automatically preferable to a CPQ. It is simply sometimes sufficient.

The risk of the in-house CPQ

The problem arises as rules continue to accumulate.

One formula depends on another.

Several automations must execute in the correct order.

Each new exception requires an additional field or rule.

The system still works, but no one dares to modify it without asking the person who built it.

The cost is then no longer the license fee.

It is maintenance.

Building the logic yourself is therefore not necessarily simpler than choosing specialized software.

Use the simplest architecture capable of properly absorbing business complexity.

Not the most sophisticated solution.

But also not the light solution at any cost.

How to choose CPQ software?

Once the need is confirmed, the choice must stem from actual business rules rather than a list of features.

Start with the configuration of offers

Which products or services can be combined?

Which options are mandatory?

What dependencies or exclusions exist?

An advanced configuration engine brings little value if the catalog is simple.

Conversely, a tool that is too limited will simply push exceptions elsewhere.

Test the pricing engine on your real use cases

List the mechanisms that actually determine your prices:

• fixed rates;

• volumes;

• tiers;

• discounts;

• bundles;

• subscriptions;

• commitment durations;

• special terms.

A demonstration based on your real scenarios is much more useful than a fictional catalog prepared by the vendor.

Check the approvals

Not all proposals need to go through the same loop.

A 5% discount can be authorized while a much larger discount requires validation.

The right system streamlines standard cases and escalates true exceptions.

Clarify the integration with the CRM

The sales representative must be able to work from their opportunity without unnecessarily re-entering known information.

It is therefore necessary to define:

• what data leaves the CRM;

• what data comes back from the CPQ;

• at what moment;

• which system remains the source of truth.

Evaluate maintainability

Who will be able to:

• add a new offer?

• modify a rate?

• change a discount threshold?

• test a new rule?

• understand the system in six months?

A powerful CPQ that is constantly dependent on external expertise can become more restrictive than a slightly less sophisticated system managed internally by the team.

Look at implementation costs, not just the license

Setting it up may require:

• formalizing the catalog;

• modeling the rules;

• CRM integration;

• approval workflows;

• data migration;

• testing;

• user training.

This is often one of the main lessons of a CPQ project: you cannot properly automate business rules that are not yet clearly defined.

The work therefore sometimes begins before choosing the software.

For a definition more focused on the category itself, SAP also details how CPQ works in its dedicated documentation.

CPQ and Quote-to-Cash: what's the difference?

The two concepts are related, but their scope differs.

CPQ primarily answers:

How to build a valid offer and correctly determine its price?

Quote-to-Cash answers:

How to move this sale from the quote all the way to payment collection?

CPQ can therefore be a component of Quote-to-Cash:

Opportunity → CPQ → quote → contract → eventual delivery → invoice → payment

A company with simple offers can perfectly have a structured Quote-to-Cash process without CPQ.

Conversely, if a CPQ is required, its integration with the rest of the process must be planned from the start: the validated price and configuration must become reliable data for the subsequent steps.

Frequently asked questions about CPQ software