For a founder-led B2B SaaS org scaling from $5M to $25M ARR, what's the clearest signal that the founder should hire RevOps instead of doing a full CPQ overhaul — and when does it switch the other way?

The Friday night that tells you which problem you actually have

Picture a $9M ARR company with eleven reps, a first VP Sales hired eight months ago, and a founder who still opens the laptop at 9pm every Friday to build the forecast. The CRM says $2.4M in commit. The VP says $1.9M. Finance says $2.1M once you strip the two deals that were double-counted after a rep cloned an opportunity. The founder spends three hours reconciling, lands on $2.0M, and closes the quarter at $1.6M anyway.

That same week, two reps complain that quotes take forever. One deal slipped because a quote sat for four days. The founder, holding both facts, reaches an intuitive conclusion: we need CPQ. It is the wrong conclusion, and the reason it is wrong is visible in the story if you read it carefully. The quote sat for four days because it needed a 27% discount, and the only person who could approve 27% was the founder, who was heads-down in a board deck. The tool was never the constraint. The approval owner was.

This is the diagnostic that matters more than any framework: trace the latency to its actual queue. When a quote takes four days, ask what it was waiting on. If it was waiting on a rep to hand-assemble twenty line items across three price sheets, that is mechanical, and mechanical problems yield to tooling. If it was waiting on a human decision that nobody but the founder is authorized to make, that is a governance problem, and buying software to route the request faster just gets the request to the bottleneck sooner.

Founders systematically misread this because CPQ pain is loud and RevOps absence is silent. Reps complain about slow quotes in Slack, in pipeline reviews, in one-on-ones. Nobody walks into the founder's office and says "we are missing a revenue process architect." They just quietly miss forecast, leak discount, and reconcile spreadsheets at midnight. The loud pain gets the budget. The quiet pain compounds — and it compounds faster with every rep you add, because each new hire is one more person operating inside a system with no owner.

There is a second scenario worth holding alongside the first, because it is the mirror image and it does exist. A $7M ARR infrastructure company selling pure consumption pricing — per-request, per-gigabyte, tiered overages, committed-use discounts with ramp schedules. They hired a strong RevOps lead nine months ago. She built the forecast methodology, cleaned the CRM, stood up a deal desk. And now she spends roughly sixty percent of her week checking rep-built spreadsheets for math errors on committed-use contracts, because no human can consistently price a three-year ramp with overage tiers by hand. That company should start the CPQ project this quarter. The architect is already in the building and is being used as a calculator.

Between those two poles sits almost every company asking this question, and the honest answer is that the poles are not symmetric. One of them is far more common than the other in the $5M-$25M band, and the cost of guessing wrong is far more severe in one direction than the other.

Why the sequence is hierarchical rather than a coin flip

RevOps is a capability: the function that owns the design, instrumentation, and continuous improvement of the revenue process from lead capture through renewal. CPQ is a tool: software that encodes a pricing and quoting process so it executes fast, consistently, and with low error rates. The relationship between them is not a preference — it is structurally hierarchical. RevOps designs the process. CPQ automates a process. Automate a process you have not designed and you do not get a fast revenue engine; you get a fast way to reproduce the same mistakes at higher volume.

Watch what a CPQ implementation actually demands, decision by decision. What is the canonical price book, and who owns it when marketing wants to run a promo? What are the bundles, and which SKUs are mutually exclusive? What is the discount approval matrix — who approves 10%, who approves 25%, what triggers desk review, and what is the SLA on each tier? How do multi-year ramps get priced, how does co-terming work when a customer expands mid-contract, and what happens to the original term? What is the quote-to-order-to-provisioning handoff, and which system is the source of truth once the deal closes? How does revenue recognition read the contract?

Every one of those is a revenue-process decision, not a software decision. Run a CPQ project without a RevOps owner and those decisions still get made — just by default. By whichever sales engineer happens to be configuring the tool. By an implementation consultant who learned your business six weeks ago and will be gone in four months. Or, most often, not at all, leaving the tool half-configured, the exceptions handled in spreadsheets, and the team quietly back where they started within two quarters.

This is why "CPQ first, RevOps never" is the dominant expensive failure in this band. Implementations get rebuilt not because the software was bad but because nobody owned the process the software was supposed to encode. The corollary cuts both ways and is worth stating plainly: even when CPQ is the correct spend, RevOps is usually still the correct first hire, because the strongest predictor of a CPQ implementation surviving is that a RevOps owner scoped it, owns the data model behind it, and will run it after go-live.

The same logic shows up in adjacent systems and is worth recognizing because it generalizes. Companies that buy a forecasting platform before defining a forecast methodology get a beautiful dashboard displaying numbers nobody trusts. Companies that buy lead routing before defining territory logic get faster distribution of leads to the wrong reps. Companies that buy a billing system before deciding how contracts are structured get automated invoices for terms the CRM disagrees with. Tooling amplifies whatever process you have. If the process is undefined, amplification is not the thing you want.

How the decision actually resolves, step by step

Run your company through this sequence in an afternoon. It is more useful than any ARR rule of thumb because it looks at the constraint rather than the size.

Map your last twenty slipped or lost deals and classify each cause. Not the CRM's loss reason — the real one, which usually requires asking the rep. Sort into two columns: died in quoting mechanics (quote took too long to build, quote had errors, rep could not configure the bundle, pricing was inconsistent versus a competitor bid), or died in process ambiguity (unclear approval path, sat in legal with no owner and no SLA, forecast said commit but nobody had qualified it, sales and CS fought over who owned the expansion so it fell through the crack). The tally is rarely close. In founder-led companies under $12M ARR, the process column typically dominates three or four to one.

Time the workflow end to end and find where deals queue. The full chain runs lead capture → routing → discovery → scoping → configure-price-quote → approval/desk review → legal and security review → close → order and provisioning → onboarding handoff → adoption → renewal and expansion. CPQ touches exactly one link: configure-price-quote, plus the approval enforcement that follows it. If your constraint sits anywhere else in that chain — and in this band it usually sits in qualification discipline, approval ownership, or the CS handoff — then CPQ optimizes a non-bottleneck, which by definition does not speed the system up. That is straight Theory of Constraints, and it applies to revenue workflows as cleanly as it applies to factory floors.

Ask whether the constraint is judgment or speed. "We keep discounting inconsistently and nobody knows our real net price" is a judgment constraint; it needs a person to design governance. "Our pricing rules are perfectly clear and it still takes a rep four hours to build a quote" is a speed constraint; it needs a machine to execute known rules fast. CPQ is a speed-and-consistency-of-execution machine. It is not a judgment machine. It will enforce an approval matrix beautifully and has no opinion whatsoever about whether the matrix is correct.

Test whether anyone can produce a trusted pipeline number in under thirty minutes without reconciliation. If the real number requires the founder, a finance person, and a sales leader to argue for three hours every Friday, that is a process and data-ownership failure that no quoting tool touches. This single question carries more signal than the other three combined, because it is binary, it is easy to test honestly, and it maps directly to whether anyone owns the system.

Assess pricing complexity honestly, separately from ARR. Count actual sellable SKUs. Identify whether you have usage-based or consumption pricing, tiered pricing with volume breakpoints, multi-product bundles with dependency rules, multi-year ramps with escalators, channel or partner-sold motions with margin layers, or multi-currency and regional variation. Complexity is a CPQ accelerant that overrides ARR entirely — a $7M company with consumption pricing may need CPQ-grade tooling before a $20M company selling three flat seat tiers does.

Notice what the tree does structurally: the only path that terminates in "prioritize CPQ now" requires a RevOps owner to already exist. That is not a thumb on the scale. It reflects the underlying dependency — the building requires the architect, so any branch that legitimately reaches the building has already passed through the architect.

The numbers a founder should actually anchor on

RevOps hiring cost. A first RevOps leader at Director or Head level in this band typically runs $150K-$220K base, roughly $180K-$270K OTE with variable, plus equity. A senior RevOps manager — often the correct first hire between $5M and $10M ARR — runs closer to $115K-$160K base. Fractional RevOps firms and independent operators generally price at $3K-$10K per month for ongoing engagement, or $15K-$60K for a scoped project such as a process design and CPQ readiness assessment. Ranges vary by market and by whether you are hiring in a major metro.

Headcount ratio as you scale. A healthy planning benchmark is roughly one RevOps FTE per 8-15 quota-carrying reps, or RevOps at about 2-4% of total go-to-market headcount. A $12M company with twenty-five GTM staff typically supports one to three RevOps people. Below that ratio the function becomes purely reactive; well above it, you are usually compensating for a CRM that needs re-architecting rather than more hands.

CPQ cost. Software commonly lands in the $75-$200 per user per month range across the major platforms, frequently with platform minimums that matter more than per-seat price at small headcount. Implementation services in this ARR band typically run $80K-$300K for a clean scope, with complex usage-based or multi-catalog builds running higher. First-year total cost of ownership for a thirty-rep org commonly lands somewhere in the $150K-$450K range all-in. Timeline for a well-scoped implementation is roughly three to six months — longer if your price book is still changing monthly, which is itself the signal that you went too early.

What each investment actually returns. RevOps done well tends to recover meaningful forecast accuracy — often in the range of eight to fifteen points of variance reduction — plus five to twelve percent of discount margin that was leaking through inconsistent, ungoverned discounting, plus ten to twenty percent of rep selling time previously lost to administrative work. CPQ done well cuts quote turnaround dramatically, often sixty to ninety percent, drops quote and order error rates from high single digits into the low single digits, and recovers three to eight percent of discount margin through enforced approval logic. Note the overlap on discount margin, and note which direction it runs: RevOps *designs* the governance, CPQ *enforces* it. Enforcement of a policy that does not exist returns nothing.

Thresholds worth writing down. Quote turnaround: if your median exceeds twenty-four hours and your ninetieth percentile exceeds forty-eight to seventy-two hours, and you can trace slipped deals to that latency, the mechanical case is quantified. Quote and order error rate: above eight to ten percent — wrong SKU, wrong term, wrong discount, arithmetic mistakes — is textbook CPQ territory. SKU count: somewhere past fifteen to twenty-five sellable SKUs, human consistency degrades sharply. Discount variance across reps: more than about ten percent spread on comparable configurations means either governance or enforcement is missing, and which one determines your answer.

The failure-cost asymmetry, which is the real argument. A CPQ implementation that has to be rebuilt costs the sunk implementation spend — commonly six figures — plus six to twelve months of organizational drag, plus the opportunity cost of a team operating worse during a failed rollout. And you still have to make the RevOps hire afterward, except now that person inherits a broken system to untangle before they can do anything else. Compare that to the cost of hiring RevOps when CPQ was arguably the more urgent problem: you delayed the CPQ project by roughly a quarter, and the person you hired is the one who now scopes and de-risks it. One mistake costs a quarter. The other costs a rebuild plus the hire you were avoiding. Under genuine uncertainty — and founders in this band are genuinely uncertain — you minimize the cost of being wrong, and that math points one direction.

What the RevOps-first year actually produces

Scope the hire correctly by knowing what twelve months should deliver, quarter by quarter. This matters for the founder's own expectation-setting as much as for the job description.

Months zero to three — make the numbers trustworthy. Clean the CRM data model: stage definitions with exit criteria, required-field discipline, deduplication, opportunity hygiene rules that are actually enforced rather than documented. Define one canonical pipeline and one forecast methodology. Build the weekly forecast cadence with real inspection. The deliverable is concrete and testable: a single forecast number the founder does not have to reconcile. If that does not exist by end of quarter one, the hire is off track.

Months three to six — govern the deal flow. Stand up a real deal desk: a documented discount approval matrix with named approvers and SLAs at each tier, a non-standard-deal review process, quote templates, a pricing reference, a legal and security review SLA with an owner. This is the quarter where the founder gets removed from the deal desk. The deliverable: the founder no longer approves routine non-standard deals — a documented process does, and exceptions are genuinely exceptional.

Months six to nine — close the loops at both ends. Build the marketing-to-sales SLA and lead routing logic. Build the sales-to-CS handoff with a defined trigger and owner. Assign renewal and expansion ownership explicitly, because unowned renewals are where quiet churn lives. Instrument funnel conversion by stage so leakage becomes visible rather than inferred. The deliverable: end-to-end funnel visibility and handoffs that do not drop deals.

Months nine to twelve — scope what scales. Your RevOps owner has now lived inside the revenue engine for three quarters and knows the real price book, the real approval logic, the real bottlenecks, and where the exceptions cluster. This is when they scope the CPQ overhaul, if it is needed, against a data model grounded in observed reality rather than a vendor template. The deliverable is either a CPQ requirements document and phased build plan, or a defensible "we do not need this yet, here is what we will watch."

That last quarter is the reason RevOps-first is rarely wrong even when CPQ turns out to be the real problem. The hire is the person who correctly scopes and de-risks the CPQ project. You almost never regret making them first.

Worth naming explicitly: a competent RevOps owner can run what amounts to CPQ-lite — standardized quote templates in the CRM, a documented price book, an approval matrix enforced through native CRM approval processes, a pricing calculator maintained centrally rather than by each rep — and it works adequately well into the $10M-$15M range for a simple price book. This is not a workaround; it is the correct intermediate state. Its existence is precisely why "RevOps first" does not collapse into "RevOps and then immediately CPQ anyway." A good RevOps hire genuinely defers the CPQ spend, often by a year or more, and when the spend finally happens it is aimed correctly.

Trade-offs, alternatives, and what else competes for the same dollar

The framing so far has been binary, which is a useful simplification and also a slight distortion. In practice this budget competes against several adjacent moves, and a founder should know which ones can substitute.

Fractional versus full-time RevOps. At $5M-$8M ARR, a fractional engagement is often the better first move rather than a compromise. You get architect-grade thinking without committing to a permanent role before the role is fully defined, and a good fractional engagement produces the process design and the CPQ readiness assessment as tangible deliverables. The transition point to full-time is usually somewhere around $8M-$12M ARR, when ongoing execution volume justifies a dedicated owner and when institutional continuity starts to matter more than flexibility. The pattern that works cleanly: fractional from roughly $5M-$9M to design the system, then a full-time leader at $9M-$12M to run and scale it, sometimes with the fractional firm helping recruit their own replacement. The failure mode is staying fractional past $12M, when the absence of an embedded owner costs more than the salary saved.

Comp plan redesign as a substitute for both. A meaningful share of "we need CPQ" pain is incentive pain wearing a tooling costume. When reps discount inconsistently, the root cause is frequently that the comp plan pays full commission on a heavily discounted deal — so reps rationally give away price. CPQ can enforce an approval matrix, but if the plan still pays out the same either way, you have deployed software to fight an incentive, and incentives win that fight over any twelve-month horizon. The cheaper fix is often margin-protected commission or discount thresholds that affect payout, which costs a comp cycle rather than a six-figure implementation. Likewise, "deals stall in the sales-to-CS handoff" is frequently a comp problem: nobody is paid to own the transition. RevOps can see and fix incentive-rooted dysfunction; CPQ structurally cannot.

CRM re-architecture as a prerequisite to either. Most revenue dysfunction in this band traces to a CRM configured by the founder or the first sales hire and never properly architected since. Objects, stages, fields, validation rules, and automation accreted rather than designed. Layering CPQ on top of a broken data model guarantees rework, because CPQ reads product, pricing, and account objects that must be correct upstream. This work costs nothing but the RevOps hire's time and is almost always the highest-leverage first move.

Hiring another rep instead. The honest comparison. A rep at $150K OTE produces incremental pipeline; a RevOps leader at $180K OTE produces leverage across every existing rep. The tiebreaker is your ratio: if you have five reps and no process, the sixth rep will underperform the existing five because they onboard into chaos. If you have three reps and a clean process, the fourth rep is the better dollar. RevOps pays off as a multiplier, which means it needs a multiplicand — somewhere around six to eight reps is where the math usually flips decisively.

Revenue intelligence tooling as a partial substitute. Conversation intelligence and forecasting platforms deliver real value and are frequently bought as a RevOps substitute. They are not one. They surface signal; they do not design process or make decisions. A forecasting platform installed over an undefined forecast methodology displays a confidently wrong number faster. That said, these tools genuinely reduce the manual reporting burden, which extends how far a fractional engagement or a single RevOps manager can stretch.

The pitfalls that sink each path

Hiring an analyst and expecting an architect. The single most common RevOps mis-hire. A strong sales operations analyst is genuinely valuable at reporting, dashboards, CRM administration, and execution — but the work is reactive and downstream. The architect designs the system: forecast methodology, deal desk, comp logic, cross-functional process, data model, CPQ scope. Founders who hire the analyst and expect the architect end up with better dashboards and identical structural dysfunction. Screen for it directly: ask a candidate to describe a revenue process they designed from scratch rather than administered. Ask how they would stand up a deal desk where none exists — an architect describes the approval matrix, the SLAs, the escalation logic, and the change-management plan; an analyst describes the CRM approval-process configuration. Ask how they would decide whether the company needs CPQ — an architect runs a diagnostic; an analyst opens a vendor comparison.

Letting ARR alone trigger the CPQ project. A $14M company selling three seat-based tiers and two add-on modules does not need CPQ just because $14M feels like CPQ territory. If the real pain on inspection is forecast swings, no deal desk, and the founder approving large discounts, CPQ would automate a price book that native CRM quoting handles fine. Conversely, a $7M consumption-pricing company may need it immediately. Complexity is the variable; ARR is only a proxy, and a loose one.

Skipping the paper freeze before tool selection. Before any vendor conversation, document the canonical price book, the bundle and SKU rules, the discount approval matrix, the quote-to-order handoff, and the data model. If you cannot write those down clearly, you are not ready to buy — you are still in design territory, which is the tell that RevOps comes first. Founders skip this because it feels like delay; it is the single highest-return two weeks in the entire project.

Big-banging the implementation. Phase it: core quoting, then approvals, then advanced configuration, then renewals and amendments. Each phase should be genuinely faster than what it replaced before the next one starts. A big-bang rollout that lands half-working teaches the sales team that the tool is unreliable, and that lesson is expensive to unteach.

Underestimating rep resistance to both. In a founder-led company, reps have often operated with substantial freedom. RevOps brings required fields, stage-gate criteria, forecast accountability, an approval matrix. CPQ removes the ability to freelance pricing in a spreadsheet. Both are experienced as loss of autonomy, and in the first sixty to ninety days the friction is real rather than imagined. Design the process so it visibly serves the rep — faster approvals because the matrix is clear, faster quotes because the template exists, fewer deals lost in legal because there is an SLA — or it gets quietly routed around. A CPQ that reps bypass is worse than no CPQ: sunk cost plus a false sense of control. Measure adoption as a real metric — quotes generated inside the tool versus outside it — and treat a low number as a design failure rather than a compliance failure.

Leaving CPQ unowned after go-live. The price book changes. Pricing strategy shifts. New SKUs launch. Approval thresholds need adjusting as deal sizes grow. Without an owner maintaining the configuration, a CPQ degrades within two quarters into a system everyone works around. This is the final structural argument for the sequence: even the CPQ-urgent company needs RevOps to keep the CPQ working.

Misreading the org placement. Where RevOps reports changes what it can do. Under the CRO, it is fast and sales-aligned but tends to narrow into sales ops and under-serve marketing and CS. Under the CFO, it is rigorous and finance-aligned but risks becoming a controls function disconnected from go-to-market reality. Reporting to the founder or COO — common and often correct in the $5M-$10M window — preserves the cross-functional mandate but depends on the founder actually delegating. This interacts directly with CPQ, which touches sales, finance, and product simultaneously. Bury RevOps under sales and the CPQ project will under-weight billing and catalog requirements, which is precisely how rebuilds start.

Assuming AI changes the sequence. It does not, and it arguably strengthens it. AI-assisted configuration and natural-language quote generation are genuinely compressing CPQ implementation cost and timeline — the building is getting cheaper to construct. AI is also automating the execution layer of RevOps work: data hygiene, report generation, deal inspection, forecast roll-ups. But that elevates the function rather than eliminating it, shifting the RevOps role toward pricing strategy, comp design, go-to-market architecture, and orchestrating automation across the stack. The new failure mode is the important one: as both layers get more powerful, the cost of automating a badly-designed process goes up, because you can now make the wrong decisions at machine speed and at scale. Powerful tools wired up wrong fail faster and more expensively than weak ones. AI does not let a founder skip the architect. It raises the price of skipping.

Related questions

Does hiring RevOps mean I still need a sales ops person later?

Usually yes, but later and in a different shape. The architect designs; execution volume eventually justifies dedicated administration. Expect the split to appear somewhere around $12M-$15M ARR, when one person can no longer both design the system and maintain it daily.

Can our CPQ implementation consultant design the process for us?

Partly. A good consultant will push you to define a price book and approval matrix — but scoped to what the tool touches, on the tool's timeline, with no ongoing ownership and no authority over comp, handoffs, or forecast methodology. You can rent process design for a project; you cannot rent ongoing ownership.

We are only $6M ARR — aren't we too small for RevOps?

You are too small for a RevOps *team*, not for RevOps *capability*. A fractional engagement or one senior hire scales down cleanly to $5M. Conflating the two is exactly what keeps founders serving as the integration layer two years longer than they should.

What if we hire RevOps and they immediately say we need CPQ?

Then the hire did their job. They scoped and de-risked a six-figure project against real data instead of a vendor template, and they will own it after go-live. That is not a wasted year; that is the year that keeps the project out of the rebuild statistics.

How does this change if we are product-led with an enterprise tier layered on?

The architect case gets stronger. PLG-plus-sales hybrids have judgment problems first — who owns the self-serve-to-sales handoff, how you forecast a hybrid motion, how enterprise expansion prices off a self-serve base — none of which CPQ addresses. Design the hybrid motion, then automate the enterprise tier's quoting.

FAQ

What is the single clearest red flag that a founder should hire RevOps before touching CPQ?

The founder is personally the integration layer of the revenue org: running the forecast, approving every non-standard deal, arbitrating lead quality between marketing and sales, and being the only person who actually knows why last quarter missed. That is a capability gap, and software does not fill capability gaps. It also has a hard ceiling — one person can hold the revenue system in their head to roughly $5M-$8M ARR, after which entropy compounds with every new rep, product line, and quarter.

At what point does a CPQ overhaul become the higher priority?

When three conditions hold simultaneously: pricing is genuinely complex (past roughly fifteen to twenty-five sellable SKUs, or usage-based, tiered, multi-year ramp, or channel-sold pricing), quote latency is measured rather than felt (median past twenty-four hours, ninetieth percentile past forty-eight to seventy-two, with traceable deal slippage), and a RevOps owner is already in seat spending their week on manual quote QA instead of design work. That third condition is the one founders skip, and skipping it is what produces rebuilds.

Can a founder do both at the same time?

Yes, and sometimes you should — the compressed-timeline case. A company with genuinely complex pricing and no RevOps should hire the architect immediately and make the CPQ scope their first deliverable rather than their fourth-quarter one. The project starts around month three or four instead of month twelve. What does not work is running the CPQ implementation with no internal owner while simultaneously recruiting for one; the decisions the implementation forces will get made by default before the owner arrives.

How quickly does a RevOps hire pay for itself?

Typically within one to two quarters, through a combination of recovered forecast accuracy, discount margin that stops leaking once governance exists, and rep selling time returned from administrative work. The margin line alone often carries it: on a $10M ARR base, recovering even a few points of systematically leaked discount covers the salary. The less quantifiable return is the founder's calendar — eight to fifteen hours a week of revenue firefighting redirected to product, fundraising, and key hires.

What is the clearest sign we should NOT hire RevOps yet?

Low deal volume, a small rep count, a simple price book, and a founder who can genuinely manage deal flow in well under ten hours a week without the numbers going fuzzy. If forecast reconciliation is not painful and nothing is queuing behind founder approvals, the system has not yet outgrown its owner. A fractional engagement to design the process before the pain arrives is still cheap insurance, but a full-time hire is premature.

Our investors ask about quote-to-cash tooling — won't they want to see CPQ in the stack?

Sophisticated investors care about clean revenue data and a forecast that holds far more than about which logo sits in the quoting layer. A company with a sharp RevOps owner, a well-architected CRM, and a forecast that predicts reality will diligence better than one with an expensive CPQ and numbers nobody trusts. Lead with the capability; the tooling narrative follows from it rather than substituting for it.

Sources

1. Salesforce Revenue Cloud — https://www.salesforce.com/products/revenue-cloud/
2. HubSpot quotes and CPQ documentation — https://knowledge.hubspot.com/quotes/create-and-share-quotes
3. Gartner sales technology and CPQ research — https://www.gartner.com/en/sales
4. Bessemer Venture Partners, State of the Cloud — https://www.bvp.com/atlas/state-of-the-cloud
5. SaaStr, go-to-market and scaling library — https://www.saastr.com/
6. Winning by Design, Revenue Architecture — https://winningbydesign.com/
7. Pavilion, revenue leadership community and benchmarks — https://www.joinpavilion.com/
8. Conga CPQ product documentation — https://conga.com/products/conga-cpq
9. DealHub CPQ resources — https://dealhub.io/
10. McKinsey on B2B pricing and discount leakage — https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights

Related on PULSE

• What's the right deal desk org design philosophy for a founder-led B2B SaaS company planning to scale from $5M to $50M ARR?
• What's the right governance model for a founder-led sales org under $5M ARR still deciding between PLG and sales-led?
• How do you coach reps to stop doing feature-dump demos?
• Should I be worried my company stopped doing demos?
• How is the 2027 AI compliance overhaul reshaping your B2B sales discovery stage?