HubSpot's own team was candid: engineered, spreadsheet-style manufacturing quoting is roughly a year away from what Revenue Hub does natively.
I appreciate that candor, and I want to build on it rather than complain about it, because the manufacturer in that conversation still needs to quote next month. Here's the architecture we landed on together with HubSpot, why it works, and when a dedicated CPQ is still the better answer.
Revenue Hub is strong where quoting is catalog-driven: price books, line items, contracts, approval flows. Manufacturing quoting often isn't. One division in this group prices engineered projects with margin, lead-time, and freight fields on a spreadsheet, per quote. Another runs sixty quotes a day out of a database quoting tool keyed to ERP customer numbers. A third quotes from STEP files in a specialist tool built for exactly that. Ask native Revenue Hub to replace all three and you get a demo that fails to impress, which is what happened to a different client with complex quoting earlier this year.
I wrote last week about piloting CPQ in the hardest division first. This post is about what that pilot is actually built from.
The architecture: a custom UI extension in HubSpot that walks the rep through the engineered quote, the fields the spreadsheet had, in the order the spreadsheet had them, with the calculations the spreadsheet did. Underneath it, native Revenue Hub objects: price books synced from the ERP, line items, contracts. The custom layer is the guided selling. The native layer is the system of record. When Revenue Hub's roadmap catches up, the custom layer shrinks; the data underneath doesn't move.
The specialist tools stay. The STEP-file quoting tool integrates through its API rather than being replaced, because replacing a tool engineers trust with a generic one is how you lose a division. The database quoting tool gets the same treatment: ingest its quotes, key them to ERP customers, and let the CRM show status rather than pretend to be the quoting engine.
Two cases. First, when you're consolidating two companies with two CPQs, a few dozen SKUs and four price books on one side, a multi-price-book structure on the other, and the acquirer already runs a dedicated CPQ. Rebuilding both in Revenue Hub is a project nobody asked for. Second, when quoting depends on features Revenue Hub simply doesn't have yet and your quoting motion can't wait a year for them.
The steelman for waiting on native: less to maintain, one vendor, and the roadmap is real. If your quoting is catalog-driven, wait, and use the native tools now. The hybrid is for the manufacturers whose quoting was never going to be a catalog.
Simple beats complex, and this is the simplest thing that actually works for engineered quoting today: native where native holds, custom only where it doesn't, and specialist tools connected rather than replaced.
If you've tried to move engineered quoting into a CRM, native or not, what broke first? I suspect it was the spreadsheet fields nobody wanted to give up.