CPQ (configure, price, quote)

In practice

Industrial and B2B products are rarely a fixed SKU at a fixed price. A pump has options, a fabrication has specs, and the price depends on the customer's contract, volume, and configuration. CPQ encodes those rules so that when a rep or a buyer picks options, the software enforces valid combinations, calculates the correct price, and produces a quote in minutes rather than a day of back-and-forth.

The three letters map to three jobs. Configure: guided selling that only allows buildable combinations. Price: customer-specific, tiered, and rule-based pricing applied automatically. Quote: a clean, consistent document, and increasingly a live cart, that the buyer can act on. Done well, it removes the errors and delay that stall deals in complex sales.

CPQ sits at the seam between the CRM and the storefront. In a sales-led motion it lives alongside the CRM so reps quote from opportunity records. In self-serve B2B ecommerce, CPQ (or its lighter cousin, a quote-to-order flow tied to an RFQ) lets buyers configure and request pricing without a call. Many B2B ecommerce platforms bundle quoting; heavy configuration usually needs dedicated CPQ.

For an established manufacturer or distributor, the value shows up as fewer mispriced quotes, faster turnaround, and consistent margins, because discounting rules are enforced by software instead of negotiated ad hoc. The cost is the upfront work of modeling your products and pricing rules, which is real, but is also the thing that was slowing every quote down to begin with.

That modeling work is where most implementations stall, and it isn't a software problem. The rules usually live in one or two people's heads: which options can be combined, which combinations are technically possible but commercially discouraged, what the discount ladder looks like by volume and by customer tier, and who is allowed to approve an exception. Nobody's ever been forced to write them down. Expect the first phase of a CPQ project to be that exercise, and expect it to surface disagreements between sales and engineering that predate the software by years.

You don't always need it. If your catalog is a few hundred stable SKUs at list or contract pricing, a well-built RFQ page and a responsive inside-sales team will beat a half-configured CPQ deployment. The threshold is roughly this: when a quote regularly requires an engineer to confirm that what sales sold is actually buildable, or when two reps quoting the same job arrive at different numbers, the rules are complex enough that software should be holding them.

On the website side, CPQ rarely appears as itself. What the buyer sees is a configurator on a product page, a quote request that returns a real number instead of a promise to call back, or a logged-in portal showing their contract pricing. Those are the surfaces that matter for a B2B website, and they are worth designing deliberately: a configurator that exposes valid options clearly does more for conversion than any amount of copy about capability.