Enterprise CPQ vs custom: how to work out which one pays
There is no universal answer to whether a machinery dealer should buy a quoting platform or build one. There is a calculation — four measurable properties of the company, run over three to five years — and it lands differently for different dealers.
Whether a machinery dealer should buy an enterprise quoting platform or build a custom system is not a question with a fixed answer — it is a calculation, and it turns on four measurable properties of the company: quote volume, catalog complexity, source-data formats, and who will own the data model. For some companies the platform is the better answer. For others, the same calculation run over three to five years lands an order of magnitude apart, in favor of a custom build. The rest of this article is the calculation: what each answer is genuinely good at, what the public prices do and do not tell you, and the test to run before signing either contract.
What enterprise CPQ is built for
Configure-price-quote software is a mature category, and inside its home territory it is genuinely good. Salesforce defines CPQ as software that generates accurate quotes quickly alongside the CRM; Tacton, Epicor, encoway, and Elfsquad build serious versions of it for manufacturers with complex configurable products. The home territory is specific: a manufacturer that controls its own product rules, bills of materials, and configuration constraints, produces high quote volumes that amortize the cost of building the product model, and reuses that logic across sales channels. In that setting the platform prevents impossible configurations, enforces approvals, and pays for itself.
The category's own literature is candid about where the friction sits. Tacton's implementation survey — a vendor's research, worth reading as such — reports integration with ERP, CRM, and legacy systems named by 20 percent of respondents as an implementation barrier, complex configuration by another 20 percent. The platforms are mature. The work of fitting a company into them is not small, and the vendors say so themselves.
The path most companies take without deciding: the ERP's offer module
Most mid-market companies never run a quoting-software comparison at all — quoting arrives as a component of the ERP they are already implementing. The sequence is familiar from the companies we meet: the ERP project comes first, inventory and invoicing and warehouse move in, and somewhere late in the rollout someone points out that the system already has an offer module. The reasoning is hard to argue with in the meeting where it happens: the bigger things already live there, the module is already paid for, the data is already in the system, one vendor instead of two. So quoting gets switched on — not chosen, switched on — as an increment of a project that was justified for other reasons.
It fails quietly, in two places. The module inherits the ERP's data model, which was built around items, stock, and invoices, because that is the ERP's job. A multi-brand machinery catalog does not reduce to inventory items — a model with masts, options, and per-series price logic is a configuration structure the item table was never designed to hold, and forcing it in becomes a standing translation job nobody scoped. And the sequence puts quoting at the end of the longest project in the company instead of at the front of the shortest: quoting is the one workflow that needs no integration to start, because offers go out to new prospects, not into the ledger. None of this is an argument against the ERP — it is the system of record and it earns that place. The argument is narrower: switching on the offer module is a data-model decision that deserves the same test as a purchase, and it usually gets none, precisely because nobody experienced it as a decision.
What the subscription actually covers
A subscription removes one layer of maintenance — the vendor's — and leaves the other layer with the buyer. The first half of that sentence is the platforms' honest pitch, and it is true: no server for the dealer to run, no patching, no release pipeline. The platform vendor maintains the software, operates the infrastructure, ships the roadmap.
What no subscription covers is the buyer's side of the system: the catalog, the mappings from each manufacturer's format, the price rules, the templates, the permissions, the queue of values someone has to verify each cycle. That work lands on whoever the dealer assigns, performed inside a data model the dealer does not control. The useful distinction is between platform maintenance — the vendor's, included — and business-system maintenance, which splits into layers of its own and appears on no invoice.
There is a second quiet cost in the subscription model: buying more machine than the workload needs. Zylo's analysis of 30 million SaaS licences — again, vendor research, labeled as such — found companies using 49 percent of the licences they had provisioned. The pattern is sharper for a dealer, because the platforms are sized and priced for companies producing thousands of quotes a month. A multi-brand machinery dealer typically produces tens. The team ends up in two or three components of a suite built with dozens, on a subscription priced for the whole machine.
What the public prices tell you — and what they leave out
Licence prices are public; five-year totals are not. Salesforce's official price sheet lists Revenue Cloud Growth at $150 per user per month. Held flat, ten named users cost $90,000 over five years — as a licence floor only, before the CRM prerequisites the product assumes, before implementation, before integration with the ERP, before anyone touches the catalog. At the other end of the spectrum, PandaDoc's Business plan lists at $49 per user per month billed annually — a different class of product, closer to document automation than CPQ, and the comparison is useful only for one thing: seat count is a durable cost multiplier in either case, and it is the one number every pricing page prints.
What the pricing pages do not print is the line that actually differs between buying and building: who does the data work, at what cadence, in whose format. That omission is not deception — the number depends on the buyer's catalog, and no vendor can know it from the outside. What that work consists of, cycle after cycle, is the price-list update path, and it exists in both models; the difference is whose data model it runs inside.
The variable no comparison prices: whose data model
The strongest predictor we have seen of a quoting-software decision going wrong is not the price of the software — it is a data model imposed on a catalog that does not fit it. One company we know made the decision before we ever met them: they had chosen a ready-made platform, bought it, and begun the rollout. Three months in, they had more problems than before the implementation started. Getting catalog data out of manufacturer sources, into the vendor's prescribed structure, and matched correctly was complicated enough that it simply did not finish. Nothing was wrong with the platform as software. The platform's model of a product and the manufacturers' models of a product were different shapes, and the translation between them — unpriced, unowned, unscoped — became the project.
The pattern has an academic name older than the current platform generation: Wu and colleagues proposed measuring data and output misfits before selecting packaged ERP software precisely because model mismatch was a recognized implementation risk in 2005. Martin Fowler's warning about package customization is the same idea from the engineering side: bend a package far enough toward your reality and you inherit the cost of custom software without its coherence. And Simon Wardley's build-buy-by-evolution frame supplies the discipline both directions need: sourcing follows the component's maturity, not a slogan. Multi-brand dealer catalogs — five manufacturers, formats that differ per product series, refresh cycles the dealer does not control — are precisely the component that is not commodity, no matter how commodity the word "quoting" sounds.
Where that leaves the honest version of this comparison: a platform is a good purchase when your data fits its model, and an expensive one when the fit has to be manufactured every quarter by people whose time nobody counted. Which of those describes a given dealer is checkable — before signing.
The calculation to run before choosing
We run a version of this before any engagement of our own, and there is no reason a dealer cannot run it independently — including on us. It has three steps, and only then a return figure.
Step one: measure today. What the quoting process costs as it runs now — hours per quote, quotes lost to speed, price-list update effort, error rate a customer sees. This is the baseline both options get compared against, and companies that skip it end up comparing two futures against a present nobody measured.
Step two: score the operating load. Eight variables, one afternoon:
| Variable | Reading that favors a platform | Reading that favors a custom build |
|---|---|---|
| Quotes per month | Hundreds to thousands | Tens |
| Brands carried | One, or one dominant | Several, none dominant |
| Series per brand | Uniform structure | Structures differ per series |
| Source formats | Standardized (ETIM/BMEcat or clean exports) | Heterogeneous, per-series file types |
| Update cycles per year | Rare or vendor-managed | Several, on manufacturers' schedules |
| Approval levels | Standard discount ladder | Custom per-deal, owner involved |
| Integrations | CRM-centric, standard connectors | Comarch or legacy ERP, non-standard surface |
| Modules you would use | Most of the suite | Two or three components |
No single row decides. A column that fills up does.
Step three: test the data model before buying. Take your most difficult manufacturer, two product series, one historical price list, and one current update — photos, options, missing values included. Ask the platform vendor, or the custom vendor, to run that material through their model as a paid or time-boxed proof, ending with an export. The acceptance test must include the uncertain and missing values and a reversal, not just the clean path. A model that fits will show it in two weeks. A model that does not will show it in three months of rollout, at a very different price.
Then, and only then, the return calculation: the baseline from step one against each option's cost structure, modeled three ways — realistic, aggressive, optimistic — over three to five years, not at signature. We publish none of our own figures here on principle, and the principle cuts both ways: any vendor's pre-built TCO comparison, including a builder's, optimizes for the vendor's model. The buyer who runs the calculation owns the answer. And when the calculation lands on the platform side, that is the answer — a custom build justified against the arithmetic is a worse purchase than a subscription that fits.
Frequently asked questions
Is a subscription always cheaper than a custom build?
No — and it is not always more expensive either; the totals converge or diverge based on seats, years, and who does the catalog work. A public licence floor like $150 per user per month compounds with seat count and time, while a build's cost is front-loaded and its recurring cost follows data volume and the availability commitment. Which curve wins depends on the workload matrix above, which is why the comparison has to be run per company rather than quoted from anyone's blog — including this one.
Our ERP already has an offer module — why not just use that?
Because the module inherits a data model built for inventory and invoicing, and a multi-brand catalog has to be forced into it — so the fit deserves the same test as any platform you would pay for. If your products reduce cleanly to the ERP's item structure, the module is the cheapest good answer available, and you should take it. If each brand carries per-series configurations, options, and price logic, the module is the imposed-data-model problem with no purchase decision attached: run the step-three test on it exactly as you would on a platform, before the rollout does the testing for you.
We already bought a platform. Was that a mistake?
Not necessarily — but it is testable now rather than arguable later. Run the step-three test on your hardest manufacturer inside the platform you own. If the data fits, the purchase was sound and the work is adoption. If every cycle manufactures the fit by hand, sunk cost is not a reason to keep feeding a model that does not match your catalog.
How long does the evaluation take?
The format count takes an afternoon; the data-model test takes about two weeks with a real price list. Both are short compared to a rollout that stalls in month three, and both produce evidence a committee can argue about instead of opinions.
Does AI change the answer?
It changes the cost of prototypes, not the cost of the decision. Foundation models make a working demo cheap in either direction — a configured platform trial or a custom prototype in days. Production is what stayed expensive: the data preparation, the review, the update path. The calculation still runs on the same four properties it ran on before the models arrived.
Who should run the calculation — the buyer or a vendor?
The buyer owns the calculation; vendors supply inputs and show their math. Any vendor-run comparison, platform or custom, is an argument for that vendor's model wearing a spreadsheet. Take the inputs, check the assumptions, and run the three scenarios yourself — the assumptions are where the answer hides.
The answer in one paragraph
Whether a multi-brand machinery dealer should buy an enterprise quoting platform or build a custom system is decided by two things no pricing page prints: who maintains the data, and who operates the system — measured over three to five years, not at signature. The platform wins where the catalog fits its model and the volume uses its capacity. The custom build wins where the data model must fit the dealer — several brands, per-series formats, manufacturer-scheduled updates, a legacy ERP — and where the alternative is paying every quarter to translate reality into someone else's schema. Run the measurement, score the load, test the model, and the decision mostly makes itself.