A sales rep at a software company closes a deal by picking a tier, setting a seat count, and hitting send. The whole thing takes ten minutes. A sales rep at a discrete manufacturer quotes a custom assembly that might involve 40 component combinations, three engineering sign-offs, a check against current inventory, and a materials cost that shifted since last week. The same category of software, "CPQ," gets applied to both scenarios. That's where the mismatch starts.
Generic CPQ tools aren't poorly built. They're built for the problem their original customers had. The five realities below are the places where that design shows up as friction on a manufacturing floor.
A SaaS pricing page has three tiers. A custom assembly has a bill of materials with dozens of line items, component dependencies, and compatibility constraints. Subassembly A requires Bracket Type 2 when combined with Motor Option C. That's not a pricing rule. That's engineering logic.
Most general-purpose CPQ tools handle product configuration through a rules engine designed around option selection: pick Feature A or Feature B, apply a price modifier. That works for subscription software. It doesn't work when the configuration determines whether the end product is physically manufacturable. Manufacturers need a configurator that understands parent-child component relationships, not just pricing tiers.
Steel moves. Aluminum moves. Specialty components with long lead times get repriced by suppliers with less notice than a manufacturer gets. A quote that was accurate on Monday may be underwater by Thursday if the rep built it against a static price table that hasn't been updated since last quarter.
SaaS-built CPQ tools treat the price book as stable by design. That assumption holds in software sales. In discrete manufacturing, input cost volatility is a baseline condition. Pricing logic has to accommodate cost-driven repricing without forcing someone to manually touch every in-flight quote when a material price changes.
What a manufacturer can promise to deliver depends on two things: what's already in inventory and what the shop floor can produce by a given date. A generic CPQ tool treats availability as a data field to fill in. A manufacturing-credible CPQ uses that data as a constraint on what can be quoted in the first place.
One manufacturer described the current state like this: "We've got one guy in the company that controls all the bolts." That single person holds the institutional knowledge about what's actually available and what the lead time will be. When he's out, quoting stops. Embedding lead-time logic into the quoting system is the only way to distribute that knowledge without depending on one person to carry it.
In a software sale, the approval workflow is usually about price. Does this deal need VP sign-off because the discount exceeds 20%? That's the question most CPQ approval engines are built to answer.
In manufacturing, a second category of approval exists before the price conversation even starts: technical feasibility. Engineering has to confirm that what the rep quoted can actually be built to spec. Sales can't finalize a price until engineering signs off on the design. A CPQ tool that only models price-based approvals has no mechanism for routing a quote to an engineering reviewer. That step gets handled by email, by phone, or not at all. The result is quotes going out that can't be built as specified, which is a much more expensive problem than a delayed approval.
The price book for most discrete manufacturers lives in the ERP. That's where the part numbers are maintained, where costs are tracked, and where inventory is visible. The ERP is the source of truth by default, whether or not anyone made a deliberate decision about that.
A SaaS-built CPQ tool typically ships with its own product catalog and pricing layer. The implementation team builds the catalog in the CPQ, which immediately creates two sources of truth. Keeping them synchronized requires ongoing manual effort, and they will drift. When they drift, the quotes don't match the ERP, and someone downstream catches the error. For a system designed to eliminate quoting errors, this architecture introduces one of the most common ones.
A manufacturing-credible CPQ treats the ERP as the source and reads from it directly, rather than maintaining a parallel catalog that needs to be managed separately. That distinction is operational, not cosmetic. It's the difference between a quoting tool that reduces errors and one that moves them to a different part of the process.
If you're evaluating CPQ tools, the right question isn't whether a platform has the features on your checklist. It's whether the underlying data model was designed for how manufacturers actually build a quote.
See how Quotivity approaches cpq for manufacturing, or get a demo.