Configure one quote with pricing every approver can trace.

CPQ means configure, price, quote. The software helps a seller choose a valid product or bundle, calculate a price from approved rules, route exceptions or discounts, and generate a consistent quote. A complete system also preserves rule versions, effective dates, approvals, document inputs, and data passed to CRM, contract, billing, ERP, or finance systems.

Buy when a standard platform supports the product catalog, pricing, approvals, CRM, billing, document, and administration needs with maintainable configuration. Build when proprietary compatibility, matrix pricing, usage tiers, multi-entity rules, complex effective dates, or downstream integrations create a durable gap. Custom code should not recreate commodity quoting without that advantage.

No. CPQ determines valid configuration, price, discount, and approval inputs. Proposal automation formats commercial content, while contract automation manages clauses, negotiation, signature, and obligations. The systems can connect, but each needs a clear source of truth. A generated document should not silently recalculate pricing or override approved CPQ terms.

No. Software can apply approved rules consistently and expose mismatches, but accuracy depends on catalog, price-book, tax, currency, customer, usage, and effective-date inputs. RaftLabs builds the rules approved by client owners and tests representative cases. It does not provide tax, legal, accounting, or pricing advice or guarantee commercial outcomes.

Where does the price come from at the moment of quoting: your price book or a live ERP call? If it is the CPQ price book, ask who keeps it in sync and how often. What does the buyer see if the ERP price changed after the quote went out? Create a quote and show it become a sales order in your ERP, with the same ID in both systems. It reveals whether the connector is vendor-built, iPaaS, or partner-provided. And the maintenance question: who maintains the rules after go-live, sales ops or engineering? A rules engine only the vendor's consultants can edit becomes a recurring invoice.

Salesforce moved from CPQ to Revenue Cloud, so buyers on the older product should check the vendor's current migration terms. Weigh a rebuild against an ERP-native path when items, BOMs, and prices already live in the ERP. You may not need CPQ at all when configuration means quantity, price, and payment terms on catalog SKUs; for product-led companies it can create two billing systems that hurt UX and internal processes.

Decide between two approaches: prevent invalid configurations from being entered at all, or allow exceptions with traceable review. The biggest risk is underestimating data-model complexity: the catalog must mirror actual pricing logic, not marketing bundles. Attribute-based configuration with dozens of product rules, price rules, and custom code becomes unwieldy, so know your complexity ceiling before choosing.

Ask the price-source question: at the moment of quoting, where does the price come from, and who keeps it in sync? Ask the order question: does the quote become a sales order with the same ID in both systems? Ask the rules question: who maintains the rules after go-live, your team or the vendor's consultants? Ask the catalog question: does it mirror your actual pricing logic or your marketing bundles? And the size question: are you big enough to need CPQ, or does configuration mean quantity, price, and payment terms on catalog SKUs? The spreadsheet produces a price. Nobody can reproduce the approval path. That is what the system must fix.

A focused release for one product family, price book, approval path, quote output, and core integrations. Multiple entities, currencies, channels, usage pricing, legacy catalog repair, complex documents, tax, billing, and ERP integrations increase scope. Vendor charges remain separate. Request a 30-min call to get a number for your specific project.