CPQ in the Lead-to-Cash Stack

CPQ (Configure, Price, Quote) is the discipline that turns a governed catalog and a specific customer intent into a priced, approved, fulfillable quote. It sits between the sales motion and the order stack: upstream of CPQ, sellers and customers are still exploring what is possible; downstream of CPQ, an accepted quote becomes a commercial order that the fulfilment chain must actually deliver. CPQ does not decide what can be sold — the catalog does that. CPQ decides how a specific, valid, priced combination gets assembled and put in front of a customer for approval.

How CPQ Works in the Flow

CPQ is not a single system decision — it is a loop that pulls from several systems of record and produces one artifact: a quote the customer can accept. Each step below has a distinct owner, and CPQ's job is to orchestrate the loop, not to own every input.

What CPQ Owns — and What It Doesn't

Confusion about CPQ almost always comes down to ownership boundaries. CPQ consumes product truth, customer truth, and pricing rules — it does not create any of them. The table below states the boundary explicitly, because "CPQ can do that" is a different claim from "CPQ should own that."

Source-of-Record Boundaries

What CPQ Does Not Solve

CPQ is frequently procured as a fix for problems that actually live upstream or downstream of it. A configurator can only be as correct as the catalog it configures against, and a quote is only as useful as the order stack that can consume it. Being explicit about what CPQ cannot do prevents it from being asked to compensate for gaps elsewhere in the stack.

• Does not fix a badly modelled catalog — if the underlying Product Offering / Product Specification structure is inconsistent, CPQ will faithfully configure inconsistent products
• Does not orchestrate fulfilment — CPQ stops at the accepted quote; delivery, activation, and provisioning are COM/SOM/ROM concerns
• Does not own billing truth — pricing shown on a quote is an estimate of commercial intent, not a rated, invoiced charge
• Does not create demand or qualify a lead — CPQ starts once a sales opportunity already has a specific configuration to price, not before

When It Becomes an Anti-Pattern

This pattern recurs because CPQ is visible and sales-facing, so it is easy to fund and easy to demonstrate in isolation. A configurator with hardcoded product logic and a spreadsheet-fed price list can produce an impressive-looking quote in a sales demo. What it cannot do is guarantee that the same offering, at the same price, can be ordered and delivered — because that guarantee depends on integration work (catalog governance, order handoff, feasibility checks) that a standalone CPQ pilot typically defers.

What Breaks First

Under scale or in a legacy environment, the CPQ→COM handoff and catalog drift break first. Quotes reference offerings that the order stack cannot consume because the catalog was extended or reused inconsistently between CPQ and COM. Negotiated prices captured on the quote do not survive the handoff when the order and billing systems have no field to carry a contract-specific override. Feasibility answers go stale — a site checked as deliverable at quote time may no longer be deliverable weeks later when the order is actually placed, because CPQ has no mechanism to revalidate feasibility at acceptance. Each of these failure modes is invisible in a controlled pilot and becomes visible only under real order volume and real catalog change velocity.

TMF Mapping

• TMF620 Product Catalog Management — supplies the governed offerings and configuration rules CPQ configures against
• TMF648 Quote Management — the API surface for the quote CPQ produces, versions, and tracks through approval
• TMF622 Product Ordering — the handoff contract used to convert an accepted quote into a commercial order
• TMF679 Product Order Qualification — the feasibility check CPQ relies on to confirm a configuration is actually deliverable