
Apr 22, 2026
CPQ Pricing: The Case for Building It Yourself in Salesforce or HubSpot
CPQ pricing starts at $200/user/month - before implementation. Here's when building your own configure, price, quote system inside Salesforce or HubSpot makes more financial sense than paying for a vendor tool.

Haris Odobasic
CPQ Pricing: The Case for Building It Yourself in Salesforce or HubSpot
How you can save $100k-$500k on CPQ - and why it’s the one build-vs-buy decision in RevOps worth making.
The question we get every week
"Why would you pay 200k-500k for a CPQ project?"
Exactly. That is the most asked question from our clients.
And it's a fair one.
The right CPQ question is not "Why does it cost that much?"
It's "Should we build our own instead?"
I argue that a custom CRM is overkill for most companies.
But a custom CPQ? Now we're talking business.
About half of our client base uses a custom CPQ. Two of them we built alongside. A few others came in with one already running.

A quick history lesson
CPQ did not start as sales software.
It started in the 1980s as something called a configurator - rules-based logic sitting next to ERP, making sure a customer's spec didn't conflict with what the factory could actually build. Think aircraft, heavy machinery, industrial equipment.
Fast forward to 2000. Two guys in Deerfield, Illinois - Godard Abel and Christopher Shutts - founded a company called BigMachines, designed to integrate with ERP, CRM, and other business systems to automate the sales process. The name was literal: the product was originally for configuring, pricing and quoting big machines in oil and gas. They put the configurator in a browser. That was the breakthrough.
Then the category got formalized. In 2010, Gartner published a report defining CPQ as systems that include "pricing engines, proposal generators, quoting systems and rules or constraint engines, complemented by approval and authorization workflows." That definition still holds today.
Then came the acquisition wave:
Oracle acquired BigMachines in October 2013 and rebranded it to Oracle CPQ Cloud
Salesforce acquired Steelbrick in January 2016 for approximately $360 million, rebranding it as Salesforce CPQ
SAP acquired CallidusCloud for approximately $2.4 billion in January 2018
Apttus and Conga merged in 2020 under the Conga brand
CPQ went from a niche manufacturing tool to a strategic sales platform in 20 years. And the big enterprise software vendors paid a lot to own it.
The CPQ market today
The CPQ market is big and growing fast.
The global CPQ market was valued at USD 3.14 billion in 2025 and is estimated to grow to USD 3.63 billion in 2026, reaching USD 7.55 billion by 2031 at a CAGR of 15.74%.
A few things worth noting in the data:
Cloud deployments captured 58.21% of CPQ market share in 2025 and are expanding at 18.86% CAGR through 2031
North America dominated with 39.22% share in 2025, while Asia-Pacific is the fastest growing region at 19.12% CAGR
Industrial machinery, automobile manufacturing, and technology hardware/software are spending the most on CPQ adoption
Every major enterprise software vendor has a CPQ product now. Salesforce, Oracle, SAP, PROS, Conga, DealHub, Tacton, Vendavo, Infor, Cincom, Model N. And many new players are focusing mainly on SaaS.
This is a mature category. Which is why pricing has settled at a specific, predictable and expensive level.
Why CPQ pricing is so high
Two things drive the cost: licenses and implementation.
License pricing is roughly on par with CRM
Salesforce CPQ pricing starts at around $200 per user/month for the basic package and can go up to $250 per user/month for more advanced editions. For comparison, the $200 is the same cost of the Sales Cloud CRM license.
And there's a catch. Salesforce often has a minimum purchase requirement for CPQ of around 10 licenses, and it layers on top of Sales Cloud - so you're paying for the base CRM seat plus the CPQ seat for anyone who touches quoting.
Implementation is in the same range as CRM implementation
Implementation can cost anywhere from $20,000 to $500,000+, depending on the complexity of your products, pricing models, and workflows. At the mid-sized company level (200+ FTEs) end, six figures is standard and seven figures is not unusual for enterprises.
The cost of a CPQ implementation project can rival the software cost, especially if your quoting processes are complex. And after go-live, budgeting 10–20% of your initial implementation cost annually for enhancements is typical for mature SaaS organizations.
Add it up. For a 50-rep team, you're looking at six figures of licenses per year plus six figures of implementation, with an ongoing maintenance line. Five-year TCO creeps toward seven figures fast.
So, why the big number?
What makes CPQ complex
Let me take the vendor side of the argument first.
Product configuration rules. Compatibility logic, constraints, required components, mutually exclusive options. If you sell industrial equipment, a 50-line BOM with dependencies is not uncommon. Get this wrong and you sell something that cannot be manufactured.
Pricing logic. List price, customer-specific discounts, volume breaks, ramp deals, multi-year commits, usage tiers, co-term mechanics, currency conversions, regional price books.
Approval workflows. Different discount thresholds trigger different approvers. Legal gets involved at certain deal sizes. Finance reviews anything with non-standard payment terms. Rev Rec wants to see any custom SKU.
Document generation. Branded, legally reviewed, dynamically populated, with the right T&Cs for the right deal type.
Integrations. Read from CRM (account, opportunity, contacts). Write back pricing, quote PDFs, subscription lines. Push to ERP for booking. Push to billing for invoicing. Push to CLM for contract. Feed data warehouse for forecasting.
Governance. Every change to a pricing rule or discount threshold has downstream implications. You need change management, sandboxes, testing protocols.
At an enterprise, all six of those are genuinely hard. That is what you are paying for.
But notice something. The core of that list is narrow and well-defined.
Why CPQ is much simpler than CRM or ERP
Now the other side of the argument.
A CRM is a system of record for accounts, contacts, opportunities, activities, tasks, notes, emails, calls, campaigns, leads. It powers marketing automation, sales workflow, customer success, support, partner ecosystems. It's the operating layer for your entire commercial org.
An ERP is the financial backbone: GL, AP, AR, inventory, procurement, revenue recognition, tax, consolidation, compliance.
Both touch every function in the business. Both have decades of feature bloat. Both have regulatory and compliance requirements layered in. Rebuilding either is a multi-year project that will fail.
But a CPQ, stripped down, is four things:
Hard-coded logic (configuration rules, pricing rules)
Approval flows
Document generation
Read and write data (from CRM, to CRM, to ERP)

Why the hell is this priced the same as CRM or ERP? It makes no sense, and that is why so many struggle to accept CPQ pricing
The scope is narrow, and the boundaries are clear. It sits between CRM and ERP with one job: to produce a correct quote that both systems can downstream. There is no 30-year backlog of regulatory features. There is no multi-department functional sprawl.
And that matters because when something is narrow and well-defined, it's buildable. Especially, in 2026 with low code and no code tools like Claude.
Why custom CPQ beats custom CRM
I'll say it again - a custom CRM is almost always a bad idea. You will spend two years rebuilding contacts, accounts, opportunities, activity tracking, email sync, mobile apps, permissions, reporting, integrations. By year three you have a worse HubSpot.
A CPQ is different.
The vendor surface area is tiny. You don't need a mobile app. You don't need email sync. You don't need marketing integrations, support integrations, partner portals. You need product data in, quote PDF out.
The logic is yours anyway. Nobody sells you pricing rules out of the box. Whether you buy Salesforce CPQ or build your own, you define every rule, every approval, every threshold. The vendor just gives you a framework to put them in.
The economics flip at scale. CPQ is priced per user. The more quoters you have, the more attractive a one-time build looks compared to a perpetual per-seat subscription.
The tooling has caught up. No-code and low-code tools in 2026 can genuinely handle the four things a CPQ needs to do. This was not true in 2015.
Put differently: with a CRM you are rebuilding a platform. With a CPQ you are building a workflow.
How to build CPQ in Salesforce or HubSpot
The best case - by-a-wide-margin - is to build it inside the CRM you already own. Salesforce can do this with its standard capabilities. So can HubSpot, and most of the modern challengers. You don't need a separate CPQ platform. You need to use the platform you already have properly.
Here is what each layer looks like.

Data layer where your product catalog and pricing live
In Salesforce: standard Product, Price Book, and Price Book Entry objects. Add custom fields for whatever your pricing model needs - region, tier, ramp logic, usage thresholds. Quote and Quote Line Item objects come standard. For complex bundles, custom objects with lookup relationships do the job.
Outside Salesforce: Airtable or Baserow for small catalogs, Postgres (via Supabase or similar) for anything bigger.
Logic layer - where rules get applied
In Salesforce: Flow (especially Screen Flow) handles guided selling, configuration rules, and dynamic pricing. Validation rules block invalid configurations. Apex only when you genuinely need it - most pricing logic does not. A well-built Screen Flow can walk a rep through a 30-step configuration with conditional logic, real-time price updates, and inline approvals.
Outside Salesforce: Retool for the UI and rules engine, with Make or n8n for multi-step automations. For heavy compute, a small Python or TypeScript function on Cloudflare Workers or Supabase Edge Functions costs pennies.
Document generation - the PDF output
DocuSign Gen and Conga Composer are the obvious enterprise picks, but they're not cheap. Cheaper options that work fine: PandaDoc, Docupilot, Documint, Formstack Documents (formerly WebMerge), Nintex DocGen. For a fully internal solution, the Google Docs API or a templating library hooked into a small function works at near-zero cost. Pick based on volume, not brand.
Approvals - routing and sign-off
Use Salesforce's standard Approval Processes. They're built in, they support multi-step routing, dynamic approvers based on deal size or discount %, recall, delegation, and email-based one-click approval. There is no reason to bolt on an external approval tool unless you've genuinely outgrown what Salesforce ships with — and most companies haven't. For lightweight cases, a Slack workflow does the job.
Integration layer - keeping CRM and ERP in sync
If your CPQ lives inside the CRM, this is mostly a non-issue. The data is already there. You just need an outbound connection to ERP for booking - REST API, middleware (Workato, Mulesoft, Boomi or cheaper new alternatives), or a scheduled batch job. Built-in change data capture and platform events handle the eventing.
If you build outside the CRM, we recommend to link always to CRM and not directly to the ERP. Use the CRM-ERP integration for that. Simpler to maintain.
Spend a weekend on a proof of concept. You'll know within a week whether this is feasible for your business.
Before you go custom, be honest about these four things
A custom CPQ is not a silver bullet. It has real prerequisites.
Have 1-2 genuinely tech-savvy people in your GTM org. Someone who can read JavaScript, write a Python function, understand an API. Not a full-stack engineer necessarily, but not an Excel-only operator either.
Consultants can build it, but someone needs to maintain it internally. This is where most custom-build stories go wrong. You'll change pricing, add products, tweak approvals constantly. That needs to live with someone who is there every day.
Have good governance. Who can change pricing rules? Who signs off on new SKUs? What's the testing protocol before a rule goes live? If you can't answer those, a vendor CPQ is safer - it at least forces a structure on you.
The investment scales with team size. A custom CPQ makes more sense the bigger your quoting team is. At 5 quoters, a vendor tool is cheaper. At 50, custom pays back inside a year. At 200, it's a no-brainer.
The bottom line on CPQ pricing
CPQ is expensive because the category has consolidated around three or four enterprise vendors who price it like CRM. The products are good. The services are good. And for many companies, buying is still the right call.
But the work you're actually paying for - configuration rules, pricing logic, approvals, document generation, integrations - is scoped, bounded, and in 2026, very buildable.
If you have the tech talent in-house, the quoting volume to justify it, and the governance to maintain it, a custom CPQ is one of the highest-return bets you can make in your revenue operations stack.
That's why we keep doing it.
Revenue Wizards is a boutique RevOps consulting agency based in Amsterdam. We help European B2B SaaS companies build the systems their revenue teams actually use.
CPQ Pricing: The Case for Building It Yourself in Salesforce or HubSpot
How you can save $100k-$500k on CPQ - and why it’s the one build-vs-buy decision in RevOps worth making.
The question we get every week
"Why would you pay 200k-500k for a CPQ project?"
Exactly. That is the most asked question from our clients.
And it's a fair one.
The right CPQ question is not "Why does it cost that much?"
It's "Should we build our own instead?"
I argue that a custom CRM is overkill for most companies.
But a custom CPQ? Now we're talking business.
About half of our client base uses a custom CPQ. Two of them we built alongside. A few others came in with one already running.

A quick history lesson
CPQ did not start as sales software.
It started in the 1980s as something called a configurator - rules-based logic sitting next to ERP, making sure a customer's spec didn't conflict with what the factory could actually build. Think aircraft, heavy machinery, industrial equipment.
Fast forward to 2000. Two guys in Deerfield, Illinois - Godard Abel and Christopher Shutts - founded a company called BigMachines, designed to integrate with ERP, CRM, and other business systems to automate the sales process. The name was literal: the product was originally for configuring, pricing and quoting big machines in oil and gas. They put the configurator in a browser. That was the breakthrough.
Then the category got formalized. In 2010, Gartner published a report defining CPQ as systems that include "pricing engines, proposal generators, quoting systems and rules or constraint engines, complemented by approval and authorization workflows." That definition still holds today.
Then came the acquisition wave:
Oracle acquired BigMachines in October 2013 and rebranded it to Oracle CPQ Cloud
Salesforce acquired Steelbrick in January 2016 for approximately $360 million, rebranding it as Salesforce CPQ
SAP acquired CallidusCloud for approximately $2.4 billion in January 2018
Apttus and Conga merged in 2020 under the Conga brand
CPQ went from a niche manufacturing tool to a strategic sales platform in 20 years. And the big enterprise software vendors paid a lot to own it.
The CPQ market today
The CPQ market is big and growing fast.
The global CPQ market was valued at USD 3.14 billion in 2025 and is estimated to grow to USD 3.63 billion in 2026, reaching USD 7.55 billion by 2031 at a CAGR of 15.74%.
A few things worth noting in the data:
Cloud deployments captured 58.21% of CPQ market share in 2025 and are expanding at 18.86% CAGR through 2031
North America dominated with 39.22% share in 2025, while Asia-Pacific is the fastest growing region at 19.12% CAGR
Industrial machinery, automobile manufacturing, and technology hardware/software are spending the most on CPQ adoption
Every major enterprise software vendor has a CPQ product now. Salesforce, Oracle, SAP, PROS, Conga, DealHub, Tacton, Vendavo, Infor, Cincom, Model N. And many new players are focusing mainly on SaaS.
This is a mature category. Which is why pricing has settled at a specific, predictable and expensive level.
Why CPQ pricing is so high
Two things drive the cost: licenses and implementation.
License pricing is roughly on par with CRM
Salesforce CPQ pricing starts at around $200 per user/month for the basic package and can go up to $250 per user/month for more advanced editions. For comparison, the $200 is the same cost of the Sales Cloud CRM license.
And there's a catch. Salesforce often has a minimum purchase requirement for CPQ of around 10 licenses, and it layers on top of Sales Cloud - so you're paying for the base CRM seat plus the CPQ seat for anyone who touches quoting.
Implementation is in the same range as CRM implementation
Implementation can cost anywhere from $20,000 to $500,000+, depending on the complexity of your products, pricing models, and workflows. At the mid-sized company level (200+ FTEs) end, six figures is standard and seven figures is not unusual for enterprises.
The cost of a CPQ implementation project can rival the software cost, especially if your quoting processes are complex. And after go-live, budgeting 10–20% of your initial implementation cost annually for enhancements is typical for mature SaaS organizations.
Add it up. For a 50-rep team, you're looking at six figures of licenses per year plus six figures of implementation, with an ongoing maintenance line. Five-year TCO creeps toward seven figures fast.
So, why the big number?
What makes CPQ complex
Let me take the vendor side of the argument first.
Product configuration rules. Compatibility logic, constraints, required components, mutually exclusive options. If you sell industrial equipment, a 50-line BOM with dependencies is not uncommon. Get this wrong and you sell something that cannot be manufactured.
Pricing logic. List price, customer-specific discounts, volume breaks, ramp deals, multi-year commits, usage tiers, co-term mechanics, currency conversions, regional price books.
Approval workflows. Different discount thresholds trigger different approvers. Legal gets involved at certain deal sizes. Finance reviews anything with non-standard payment terms. Rev Rec wants to see any custom SKU.
Document generation. Branded, legally reviewed, dynamically populated, with the right T&Cs for the right deal type.
Integrations. Read from CRM (account, opportunity, contacts). Write back pricing, quote PDFs, subscription lines. Push to ERP for booking. Push to billing for invoicing. Push to CLM for contract. Feed data warehouse for forecasting.
Governance. Every change to a pricing rule or discount threshold has downstream implications. You need change management, sandboxes, testing protocols.
At an enterprise, all six of those are genuinely hard. That is what you are paying for.
But notice something. The core of that list is narrow and well-defined.
Why CPQ is much simpler than CRM or ERP
Now the other side of the argument.
A CRM is a system of record for accounts, contacts, opportunities, activities, tasks, notes, emails, calls, campaigns, leads. It powers marketing automation, sales workflow, customer success, support, partner ecosystems. It's the operating layer for your entire commercial org.
An ERP is the financial backbone: GL, AP, AR, inventory, procurement, revenue recognition, tax, consolidation, compliance.
Both touch every function in the business. Both have decades of feature bloat. Both have regulatory and compliance requirements layered in. Rebuilding either is a multi-year project that will fail.
But a CPQ, stripped down, is four things:
Hard-coded logic (configuration rules, pricing rules)
Approval flows
Document generation
Read and write data (from CRM, to CRM, to ERP)

Why the hell is this priced the same as CRM or ERP? It makes no sense, and that is why so many struggle to accept CPQ pricing
The scope is narrow, and the boundaries are clear. It sits between CRM and ERP with one job: to produce a correct quote that both systems can downstream. There is no 30-year backlog of regulatory features. There is no multi-department functional sprawl.
And that matters because when something is narrow and well-defined, it's buildable. Especially, in 2026 with low code and no code tools like Claude.
Why custom CPQ beats custom CRM
I'll say it again - a custom CRM is almost always a bad idea. You will spend two years rebuilding contacts, accounts, opportunities, activity tracking, email sync, mobile apps, permissions, reporting, integrations. By year three you have a worse HubSpot.
A CPQ is different.
The vendor surface area is tiny. You don't need a mobile app. You don't need email sync. You don't need marketing integrations, support integrations, partner portals. You need product data in, quote PDF out.
The logic is yours anyway. Nobody sells you pricing rules out of the box. Whether you buy Salesforce CPQ or build your own, you define every rule, every approval, every threshold. The vendor just gives you a framework to put them in.
The economics flip at scale. CPQ is priced per user. The more quoters you have, the more attractive a one-time build looks compared to a perpetual per-seat subscription.
The tooling has caught up. No-code and low-code tools in 2026 can genuinely handle the four things a CPQ needs to do. This was not true in 2015.
Put differently: with a CRM you are rebuilding a platform. With a CPQ you are building a workflow.
How to build CPQ in Salesforce or HubSpot
The best case - by-a-wide-margin - is to build it inside the CRM you already own. Salesforce can do this with its standard capabilities. So can HubSpot, and most of the modern challengers. You don't need a separate CPQ platform. You need to use the platform you already have properly.
Here is what each layer looks like.

Data layer where your product catalog and pricing live
In Salesforce: standard Product, Price Book, and Price Book Entry objects. Add custom fields for whatever your pricing model needs - region, tier, ramp logic, usage thresholds. Quote and Quote Line Item objects come standard. For complex bundles, custom objects with lookup relationships do the job.
Outside Salesforce: Airtable or Baserow for small catalogs, Postgres (via Supabase or similar) for anything bigger.
Logic layer - where rules get applied
In Salesforce: Flow (especially Screen Flow) handles guided selling, configuration rules, and dynamic pricing. Validation rules block invalid configurations. Apex only when you genuinely need it - most pricing logic does not. A well-built Screen Flow can walk a rep through a 30-step configuration with conditional logic, real-time price updates, and inline approvals.
Outside Salesforce: Retool for the UI and rules engine, with Make or n8n for multi-step automations. For heavy compute, a small Python or TypeScript function on Cloudflare Workers or Supabase Edge Functions costs pennies.
Document generation - the PDF output
DocuSign Gen and Conga Composer are the obvious enterprise picks, but they're not cheap. Cheaper options that work fine: PandaDoc, Docupilot, Documint, Formstack Documents (formerly WebMerge), Nintex DocGen. For a fully internal solution, the Google Docs API or a templating library hooked into a small function works at near-zero cost. Pick based on volume, not brand.
Approvals - routing and sign-off
Use Salesforce's standard Approval Processes. They're built in, they support multi-step routing, dynamic approvers based on deal size or discount %, recall, delegation, and email-based one-click approval. There is no reason to bolt on an external approval tool unless you've genuinely outgrown what Salesforce ships with — and most companies haven't. For lightweight cases, a Slack workflow does the job.
Integration layer - keeping CRM and ERP in sync
If your CPQ lives inside the CRM, this is mostly a non-issue. The data is already there. You just need an outbound connection to ERP for booking - REST API, middleware (Workato, Mulesoft, Boomi or cheaper new alternatives), or a scheduled batch job. Built-in change data capture and platform events handle the eventing.
If you build outside the CRM, we recommend to link always to CRM and not directly to the ERP. Use the CRM-ERP integration for that. Simpler to maintain.
Spend a weekend on a proof of concept. You'll know within a week whether this is feasible for your business.
Before you go custom, be honest about these four things
A custom CPQ is not a silver bullet. It has real prerequisites.
Have 1-2 genuinely tech-savvy people in your GTM org. Someone who can read JavaScript, write a Python function, understand an API. Not a full-stack engineer necessarily, but not an Excel-only operator either.
Consultants can build it, but someone needs to maintain it internally. This is where most custom-build stories go wrong. You'll change pricing, add products, tweak approvals constantly. That needs to live with someone who is there every day.
Have good governance. Who can change pricing rules? Who signs off on new SKUs? What's the testing protocol before a rule goes live? If you can't answer those, a vendor CPQ is safer - it at least forces a structure on you.
The investment scales with team size. A custom CPQ makes more sense the bigger your quoting team is. At 5 quoters, a vendor tool is cheaper. At 50, custom pays back inside a year. At 200, it's a no-brainer.
The bottom line on CPQ pricing
CPQ is expensive because the category has consolidated around three or four enterprise vendors who price it like CRM. The products are good. The services are good. And for many companies, buying is still the right call.
But the work you're actually paying for - configuration rules, pricing logic, approvals, document generation, integrations - is scoped, bounded, and in 2026, very buildable.
If you have the tech talent in-house, the quoting volume to justify it, and the governance to maintain it, a custom CPQ is one of the highest-return bets you can make in your revenue operations stack.
That's why we keep doing it.
Revenue Wizards is a boutique RevOps consulting agency based in Amsterdam. We help European B2B SaaS companies build the systems their revenue teams actually use.
CPQ Pricing: The Case for Building It Yourself in Salesforce or HubSpot
How you can save $100k-$500k on CPQ - and why it’s the one build-vs-buy decision in RevOps worth making.
The question we get every week
"Why would you pay 200k-500k for a CPQ project?"
Exactly. That is the most asked question from our clients.
And it's a fair one.
The right CPQ question is not "Why does it cost that much?"
It's "Should we build our own instead?"
I argue that a custom CRM is overkill for most companies.
But a custom CPQ? Now we're talking business.
About half of our client base uses a custom CPQ. Two of them we built alongside. A few others came in with one already running.

A quick history lesson
CPQ did not start as sales software.
It started in the 1980s as something called a configurator - rules-based logic sitting next to ERP, making sure a customer's spec didn't conflict with what the factory could actually build. Think aircraft, heavy machinery, industrial equipment.
Fast forward to 2000. Two guys in Deerfield, Illinois - Godard Abel and Christopher Shutts - founded a company called BigMachines, designed to integrate with ERP, CRM, and other business systems to automate the sales process. The name was literal: the product was originally for configuring, pricing and quoting big machines in oil and gas. They put the configurator in a browser. That was the breakthrough.
Then the category got formalized. In 2010, Gartner published a report defining CPQ as systems that include "pricing engines, proposal generators, quoting systems and rules or constraint engines, complemented by approval and authorization workflows." That definition still holds today.
Then came the acquisition wave:
Oracle acquired BigMachines in October 2013 and rebranded it to Oracle CPQ Cloud
Salesforce acquired Steelbrick in January 2016 for approximately $360 million, rebranding it as Salesforce CPQ
SAP acquired CallidusCloud for approximately $2.4 billion in January 2018
Apttus and Conga merged in 2020 under the Conga brand
CPQ went from a niche manufacturing tool to a strategic sales platform in 20 years. And the big enterprise software vendors paid a lot to own it.
The CPQ market today
The CPQ market is big and growing fast.
The global CPQ market was valued at USD 3.14 billion in 2025 and is estimated to grow to USD 3.63 billion in 2026, reaching USD 7.55 billion by 2031 at a CAGR of 15.74%.
A few things worth noting in the data:
Cloud deployments captured 58.21% of CPQ market share in 2025 and are expanding at 18.86% CAGR through 2031
North America dominated with 39.22% share in 2025, while Asia-Pacific is the fastest growing region at 19.12% CAGR
Industrial machinery, automobile manufacturing, and technology hardware/software are spending the most on CPQ adoption
Every major enterprise software vendor has a CPQ product now. Salesforce, Oracle, SAP, PROS, Conga, DealHub, Tacton, Vendavo, Infor, Cincom, Model N. And many new players are focusing mainly on SaaS.
This is a mature category. Which is why pricing has settled at a specific, predictable and expensive level.
Why CPQ pricing is so high
Two things drive the cost: licenses and implementation.
License pricing is roughly on par with CRM
Salesforce CPQ pricing starts at around $200 per user/month for the basic package and can go up to $250 per user/month for more advanced editions. For comparison, the $200 is the same cost of the Sales Cloud CRM license.
And there's a catch. Salesforce often has a minimum purchase requirement for CPQ of around 10 licenses, and it layers on top of Sales Cloud - so you're paying for the base CRM seat plus the CPQ seat for anyone who touches quoting.
Implementation is in the same range as CRM implementation
Implementation can cost anywhere from $20,000 to $500,000+, depending on the complexity of your products, pricing models, and workflows. At the mid-sized company level (200+ FTEs) end, six figures is standard and seven figures is not unusual for enterprises.
The cost of a CPQ implementation project can rival the software cost, especially if your quoting processes are complex. And after go-live, budgeting 10–20% of your initial implementation cost annually for enhancements is typical for mature SaaS organizations.
Add it up. For a 50-rep team, you're looking at six figures of licenses per year plus six figures of implementation, with an ongoing maintenance line. Five-year TCO creeps toward seven figures fast.
So, why the big number?
What makes CPQ complex
Let me take the vendor side of the argument first.
Product configuration rules. Compatibility logic, constraints, required components, mutually exclusive options. If you sell industrial equipment, a 50-line BOM with dependencies is not uncommon. Get this wrong and you sell something that cannot be manufactured.
Pricing logic. List price, customer-specific discounts, volume breaks, ramp deals, multi-year commits, usage tiers, co-term mechanics, currency conversions, regional price books.
Approval workflows. Different discount thresholds trigger different approvers. Legal gets involved at certain deal sizes. Finance reviews anything with non-standard payment terms. Rev Rec wants to see any custom SKU.
Document generation. Branded, legally reviewed, dynamically populated, with the right T&Cs for the right deal type.
Integrations. Read from CRM (account, opportunity, contacts). Write back pricing, quote PDFs, subscription lines. Push to ERP for booking. Push to billing for invoicing. Push to CLM for contract. Feed data warehouse for forecasting.
Governance. Every change to a pricing rule or discount threshold has downstream implications. You need change management, sandboxes, testing protocols.
At an enterprise, all six of those are genuinely hard. That is what you are paying for.
But notice something. The core of that list is narrow and well-defined.
Why CPQ is much simpler than CRM or ERP
Now the other side of the argument.
A CRM is a system of record for accounts, contacts, opportunities, activities, tasks, notes, emails, calls, campaigns, leads. It powers marketing automation, sales workflow, customer success, support, partner ecosystems. It's the operating layer for your entire commercial org.
An ERP is the financial backbone: GL, AP, AR, inventory, procurement, revenue recognition, tax, consolidation, compliance.
Both touch every function in the business. Both have decades of feature bloat. Both have regulatory and compliance requirements layered in. Rebuilding either is a multi-year project that will fail.
But a CPQ, stripped down, is four things:
Hard-coded logic (configuration rules, pricing rules)
Approval flows
Document generation
Read and write data (from CRM, to CRM, to ERP)

Why the hell is this priced the same as CRM or ERP? It makes no sense, and that is why so many struggle to accept CPQ pricing
The scope is narrow, and the boundaries are clear. It sits between CRM and ERP with one job: to produce a correct quote that both systems can downstream. There is no 30-year backlog of regulatory features. There is no multi-department functional sprawl.
And that matters because when something is narrow and well-defined, it's buildable. Especially, in 2026 with low code and no code tools like Claude.
Why custom CPQ beats custom CRM
I'll say it again - a custom CRM is almost always a bad idea. You will spend two years rebuilding contacts, accounts, opportunities, activity tracking, email sync, mobile apps, permissions, reporting, integrations. By year three you have a worse HubSpot.
A CPQ is different.
The vendor surface area is tiny. You don't need a mobile app. You don't need email sync. You don't need marketing integrations, support integrations, partner portals. You need product data in, quote PDF out.
The logic is yours anyway. Nobody sells you pricing rules out of the box. Whether you buy Salesforce CPQ or build your own, you define every rule, every approval, every threshold. The vendor just gives you a framework to put them in.
The economics flip at scale. CPQ is priced per user. The more quoters you have, the more attractive a one-time build looks compared to a perpetual per-seat subscription.
The tooling has caught up. No-code and low-code tools in 2026 can genuinely handle the four things a CPQ needs to do. This was not true in 2015.
Put differently: with a CRM you are rebuilding a platform. With a CPQ you are building a workflow.
How to build CPQ in Salesforce or HubSpot
The best case - by-a-wide-margin - is to build it inside the CRM you already own. Salesforce can do this with its standard capabilities. So can HubSpot, and most of the modern challengers. You don't need a separate CPQ platform. You need to use the platform you already have properly.
Here is what each layer looks like.

Data layer where your product catalog and pricing live
In Salesforce: standard Product, Price Book, and Price Book Entry objects. Add custom fields for whatever your pricing model needs - region, tier, ramp logic, usage thresholds. Quote and Quote Line Item objects come standard. For complex bundles, custom objects with lookup relationships do the job.
Outside Salesforce: Airtable or Baserow for small catalogs, Postgres (via Supabase or similar) for anything bigger.
Logic layer - where rules get applied
In Salesforce: Flow (especially Screen Flow) handles guided selling, configuration rules, and dynamic pricing. Validation rules block invalid configurations. Apex only when you genuinely need it - most pricing logic does not. A well-built Screen Flow can walk a rep through a 30-step configuration with conditional logic, real-time price updates, and inline approvals.
Outside Salesforce: Retool for the UI and rules engine, with Make or n8n for multi-step automations. For heavy compute, a small Python or TypeScript function on Cloudflare Workers or Supabase Edge Functions costs pennies.
Document generation - the PDF output
DocuSign Gen and Conga Composer are the obvious enterprise picks, but they're not cheap. Cheaper options that work fine: PandaDoc, Docupilot, Documint, Formstack Documents (formerly WebMerge), Nintex DocGen. For a fully internal solution, the Google Docs API or a templating library hooked into a small function works at near-zero cost. Pick based on volume, not brand.
Approvals - routing and sign-off
Use Salesforce's standard Approval Processes. They're built in, they support multi-step routing, dynamic approvers based on deal size or discount %, recall, delegation, and email-based one-click approval. There is no reason to bolt on an external approval tool unless you've genuinely outgrown what Salesforce ships with — and most companies haven't. For lightweight cases, a Slack workflow does the job.
Integration layer - keeping CRM and ERP in sync
If your CPQ lives inside the CRM, this is mostly a non-issue. The data is already there. You just need an outbound connection to ERP for booking - REST API, middleware (Workato, Mulesoft, Boomi or cheaper new alternatives), or a scheduled batch job. Built-in change data capture and platform events handle the eventing.
If you build outside the CRM, we recommend to link always to CRM and not directly to the ERP. Use the CRM-ERP integration for that. Simpler to maintain.
Spend a weekend on a proof of concept. You'll know within a week whether this is feasible for your business.
Before you go custom, be honest about these four things
A custom CPQ is not a silver bullet. It has real prerequisites.
Have 1-2 genuinely tech-savvy people in your GTM org. Someone who can read JavaScript, write a Python function, understand an API. Not a full-stack engineer necessarily, but not an Excel-only operator either.
Consultants can build it, but someone needs to maintain it internally. This is where most custom-build stories go wrong. You'll change pricing, add products, tweak approvals constantly. That needs to live with someone who is there every day.
Have good governance. Who can change pricing rules? Who signs off on new SKUs? What's the testing protocol before a rule goes live? If you can't answer those, a vendor CPQ is safer - it at least forces a structure on you.
The investment scales with team size. A custom CPQ makes more sense the bigger your quoting team is. At 5 quoters, a vendor tool is cheaper. At 50, custom pays back inside a year. At 200, it's a no-brainer.
The bottom line on CPQ pricing
CPQ is expensive because the category has consolidated around three or four enterprise vendors who price it like CRM. The products are good. The services are good. And for many companies, buying is still the right call.
But the work you're actually paying for - configuration rules, pricing logic, approvals, document generation, integrations - is scoped, bounded, and in 2026, very buildable.
If you have the tech talent in-house, the quoting volume to justify it, and the governance to maintain it, a custom CPQ is one of the highest-return bets you can make in your revenue operations stack.
That's why we keep doing it.
Revenue Wizards is a boutique RevOps consulting agency based in Amsterdam. We help European B2B SaaS companies build the systems their revenue teams actually use.
Stay updated with our Revenue Blog
Stay updated with our Revenue Blog
View all Posts

CPQ Pricing: The Case for Building It Yourself in Salesforce or HubSpot
Apr 22, 2026
CPQ pricing starts at $200/user/month - before implementation. Here's when building your own configure, price, quote system inside Salesforce or HubSpot makes more financial sense than paying for a vendor tool.

What is Fractional Revenue Operations (RevOps) - and Is It Right for Your SaaS Company?
Apr 9, 2026
Fractional RevOps gives European B2B SaaS companies senior revenue operations expertise without the cost of a full-time hire. Here's how it works, who it's right for, and what Revenue Wizards does differently.

AI Is Challenging Seat-Based Pricing and what to do about it
Feb 17, 2026
Seat-Based Pricing Is dying: Data Shows SaaS Companies Have 5 Years to Adapt
Load More