---
title: "Rebuilding quoting from zero in DealHub after a CRM consolidation took the old CPQ away"
type: case-study
evidence_type: proof
category: "Quote-to-Cash & CPQ"
publisher: "LeanScale"
date_modified: 2026-08-08
word_count: 1411
topics: ["pricing-packaging", "revenue-operations"]
canonical_url: https://knowledge.leanscale.team/customers/rebuilding-quoting-in-dealhub-after-the-legacy-cpq-went-away/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# Rebuilding quoting from zero in DealHub after a CRM consolidation took the old CPQ away

**Evidence type:** proof (what happened)

A sales-technology company lost its CPQ during a CRM consolidation and could not send contracts at all. LeanScale built the replacement in DealHub — catalog, pricing rules, order forms, approvals and deal rooms — then trained the sellers, wrote the admin handoff, and triaged the post-launch request queue into build work versus open business decisions.

## The challenge

The business was consolidating two product lines into a single CRM, and the CPQ that had served one of them did not come with it. That left a hard stop: reps could not generate a quote or send a contract. The old system carried a large legacy catalog, most of it deprecated or near-duplicates of the rest, and there was no price book, no order form template and no approval path in the new environment. One product line had a manual fallback process it could limp along on; the other had none at all. Whatever got built had to cover both catalogs from one quoting experience, and it had to be live in weeks, not quarters.

## The approach

Sequence the build around 'get reps quoting', then everything else
The first release deliberately scoped to a working price book, a working order form and a working approval path. Everything richer — pricing intelligence, catalog nice-to-haves, template polish — was explicitly deferred behind that. This is the single decision that made a weeks-long timeline possible.

One product, one SKU — consolidate instead of migrating the mess
The catalog was rebuilt from the product sheet rather than lifted from the old system, collapsing variants wherever the CPQ's own pricing rules could absorb them: a product that had been modelled as a whole family of separate SKUs became a single SKU with a tiered price rule on quantity. A standing rule was set that legacy SKUs would be added back one at a time on request, with the name confirmed by the requester — never bulk-imported, because bulk import defeats the consolidation.

Build native-first and keep workarounds to a minimum
Tags, product families, playbook conditionals and advanced pricing rules were used in preference to CRM flows or custom logic. Workarounds are where CPQ builds turn fragile and un-upgradable, so they were treated as a last resort rather than a shortcut.

Make the pricing math depend on one field, and make that field mandatory discipline
Every line prices as list × duration × quantity. Duration is derived from a tag on the product: recurring products take the contract term divided by twelve, one-time products are hardcoded to a duration of one. That single tag is the difference between a three-year deal quoting correctly and quoting at one year of revenue, so 'tag every new product recurring or one time' became the first rule in the admin handoff. Old products get marked inactive rather than deleted, because historical quotes still resolve against those SKUs.

Guided selling that forks on how the deal is actually structured
The playbook opens by asking which product line is being sold, then branches on how the customer licenses an underlying dependency the software needs. One path carries floor-price obligations the quote has to respect; on the other, pricing is far more flexible. Deals that mix both are discounted on total deal value rather than component by component, and conditional visibility rules keep the branch questions hidden from reps who never sell that shape of deal.

Multi-year handling: year tabs, a validator, and the ramp-vs-uplift distinction
Any term over twelve months requires one year tab per year, and products must be added before tabs are duplicated or they land in year one only. A submit-time validator was added that checks the number of year tabs against the contract term and returns a descriptive error naming the right count, because reps were otherwise guessing. Year-over-year dollar increases go in the uplift field (compounding); year-over-year seat expansion goes in per-year quantity edits. One-time products such as implementation clone forward into out-years and had to be manually stripped — an auto-strip was scoped with the vendor rather than hacked around.

Contract terms rendered conditionally from the CRM's legal record
Two synced account fields — the master-agreement type and the custom redlined agreement date — drive what prints in the custom terms block: both populated renders type plus date, type alone renders type alone, neither renders nothing. A real gotcha surfaced here: the CPQ treats a blank date as the Unix epoch, so the conditional has to test for 1970 rather than for null. That pattern was documented so every future date-based conditional inherits it.

Turn the SOW gate from a blocker into an attribute
In the old system a rep could not submit a quote for approval until a statement of work existed, even though finance did not need it to review. The rebuild made 'SOW required' a per-product attribute (not a per-family rule) that controls whether an SOW link field renders on that quote line, moved the link to something the rep pastes in, and allowed submission without it so approvals and services drafting can run in parallel. The request path for the SOW itself moved to a chat-based action so the trigger did not disappear entirely with the old button.

Approvals as rules, with an eye on who is actually available
Approval rules fire on save from trigger conditions — total list price, discount thresholds, product family containing services — with approver groups reusable across rules and an explicit any-approver versus all-approvers setting so time off and staffing gaps don't stall a deal. Services and implementation products were tagged to trigger their own approval step, custom payment terms were locked to approval-required, and the workflow was re-sequenced from services-then-legal-then-finance to all three firing in parallel.

Two order form templates, kept honest
Renewals needed an order form without the list-price column, so a second template exists alongside the full-detail one. Because they are maintained by hand, every header, contact or layout change has to be made in both — this was documented as a checklist item rather than left as tribal knowledge, since it is the most likely source of a silently wrong contract.

Version discipline as the operating model
Nothing is edited on the live configuration. Every change — product, price, template, approval rule, playbook question — starts as a duplicated draft version with a name and comment, is tested in the sandbox environment connected to the CRM sandbox by clicking through a real quote, then activated. Access changes and approvals do not need a version; anything that changes what a rep sees does.

Enablement that outlives the consultants
Delivery included a live seller training, a seller guide written from that session, a searchable admin handoff covering build philosophy, core concepts, step-by-step runbooks (add a SKU, bulk-update pricing, build an approval rule, add a product family group), a symptom-to-cause troubleshooting table, a list of hard-coded values, and a version log. A shared support channel was staffed during the rollout for live triage with quote IDs and screenshots.

Triage the post-launch queue by owner, effort and decision status
Every request that came out of the training was logged with a proposed owner (LeanScale build vs. client business decision vs. joint), an effort band, and a status. That separated quick toggles from real builds, and — more importantly — pulled genuine policy disagreements out of the build queue and named them as leadership decisions instead of quietly implementing one side.

## Outcomes

Quoting restored
Reps build quotes from the opportunity, submit through approvals, and publish e-signature deal rooms — in a business that had not been able to send contracts on one of its product lines.

Catalog consolidated
A large legacy catalog, most of it deprecated, was replaced by a curated active catalog with a standing ad-hoc process for legacy additions instead of a bulk re-import.

Quote-to-approval friction removed in the first post-launch week
Payment schedule made a required field, the uplift field renamed so it stopped being confused with volume uplift, and the contract PDF changed to map legal language by deal value automatically instead of relying on a manual catch during approvals.

Approvals re-sequenced
The sequential services → legal → finance chain was decided and put in flight as a parallel workflow, and quotes were allowed to submit without an SOW link so services drafting no longer sat on the critical path.

A handoff the client's admins can actually run
A searchable admin handoff plus a seller guide, both including the pending-change log and open questions, so the next admin inherits the reasoning and not just the configuration.

Open business decisions surfaced rather than absorbed
Contested items — whether a contractual opt-out clause builder should exist at all, how early-renewal credits should be calculated and superseded, which legacy SKUs deserve to be re-imported — were escalated as leadership decisions with the disagreement documented, not resolved unilaterally in configuration.

## Quotes

> a six month contract and a one year contract with a six month opt out are two entirely different things. We very rarely have customers opt out of a six month opt out but getting another contract signed six months later is much, much harder and a lot of times people don't even realize they remember they had an opt out.
>
> — Customer, Enterprise seller

> we couldn't send it in for approval at all until the SOW was there
>
> — Customer, Enterprise seller

> we just didn't solve for, like, the nuance of what it takes to get the SOW created
>
> — Customer, Revenue Operations lead


## Canonical

https://knowledge.leanscale.team/customers/rebuilding-quoting-in-dealhub-after-the-legacy-cpq-went-away/