--- title: "He Built a $60K CPQ Inside HubSpot in 2 Days" episode: 108 podcast: "The LeanScale Podcast" publisher: "LeanScale" guest: "Derek Mogar" guest_title: "Architect" date_published: 2026-09-01 date_modified: 2026-09-03 duration: 00:59:27 word_count: 10400 topics: ["revenue-operations", "pricing-packaging", "ai-in-gtm", "gtm-strategy"] canonical_url: https://www.leanscale.team/knowledge/podcast/derek-mogar-cpq-inside-hubspot-two-days/ source: "LeanScale Knowledge Hub — https://www.leanscale.team/knowledge" license: "Free to quote and cite with attribution to The LeanScale Podcast." --- # He Built a $60K CPQ Inside HubSpot in 2 Days _Derek Mogar on quote-to-cash in the AI era: the four-step build, the guardrails, and why trust in the data is where most projects fall short_ **Episode 108 · The LeanScale Podcast** Derek Mogar, Architect (LeanScale) · Hosted by Anthony Enrico Published September 1, 2026 · Updated September 3, 2026 · 00:59:27 Canonical: https://www.leanscale.team/knowledge/podcast/derek-mogar-cpq-inside-hubspot-two-days/ **Topics:** Revenue Operations · Pricing & Packaging · AI in GTM · GTM Strategy ## Executive summary The customer had spent two months evaluating quote-to-cash platforms — full-stack CPQ, billing, subscription management, sixty-thousand-dollar price tags — and was leaning toward one when their sales-led and product-led motions started to collide. Derek Mogar built a working CPQ inside HubSpot in two days purely to show them what advanced selling could look like. They took one look and asked why they did not just use it. That throwaway MVP is now the production system dozens of reps run on every day. The two days rest on two months in the data. Derek had already mapped how they actually sell, and the problems were visible before anyone spoke: no product SKUs, so no product-level ARR or segmentation; no restrictions on what a rep could edit; every motion sold the same way despite renewals, expansions and enterprise SKUs needing entirely different back-end treatment. His method is to model the top performers — break down in conversation intelligence how the best reps actually sell, which is usually the simplest approach. It is also how he found a quoting scenario nobody had mentioned: a rip-and-replace where the existing contract is voided, which needs the system to look back at the old records, find the differences and set credits. The build is four steps, designed around the front-end user rather than the plumbing. Scenario selection first, because the motion determines everything the quote offloads downstream. Then products, add-ons, quantities and discounts, with a live summary of total contract value, ARR and MRR — visibility they had never had. Then commercial terms, the most important step for the payload it produces and where the guardrails live: on a 36-month deal, monthly billing is simply not in the rep's list of options. Finally a review step where nothing can be edited, plus a controlled one-time discount capped by the earlier values. He took the blueprint to Claude Code as a HubSpot extension UI and got the four steps back almost exactly. What needed real work was the payload writing back to the deal — ten fields at first, growing to seventy as the reporting appetite grew. The three hardest problems were co-termed expansions, honest churn and early renewals. Expansions could not produce trustworthy ARR, which matters going into a funding round. Churn could only be established by a rep typing it in or by someone checking when billing stopped — useless when you need net revenue retention off the cuff. And an early renewal creates a two-month overlap where one contract is ending while another begins. The proration that used to happen in a spreadsheet now runs off exact day counts pulled from the dates themselves. On build versus buy, Derek's view is that the billing and subscription software dictates most of the answer, and that the real question is whether you have someone who can support it at 2am. HubSpot's legacy app platform upgrade was going to remove the serverless functionality his React extension depended on; he judged from the forums that they would reverse it, and they did — the migration then took thirty minutes. An API change can arrive with no notice at all. He would still buy where products are complex or nobody wants to manage it; high-volume SMB motions are where custom wins. And the part most teams skip is the last mile: data mapping to the billing system, granular alerting rather than quarterly reconciliation, and a Stripe sync that quietly overwrote contact names with company names. Trust in the data, not speed, is where quote-to-cash falls short — everything downstream comes off this one deal. ## Key takeaways 1. **Two days of building rested on two months in the data** — Derek spent two months in the customer's data while they spent two months evaluating platforms. The problems were crystal clear before the MVP existed: no product SKUs, no editing restrictions, and every selling motion handled identically. _Why it matters:_ The speed of the build is the least transferable part. What made it possible was already knowing the motions, the reporting requirements and the downstream systems. _For:_ RevOps Leaders, Revenue Executives 2. **The CPQ is the brain, not a quote generator** — Contracts, proposals, commission systems and forecasting all branch off it. A tool that lets you pick a product, set a quantity and add a discount produces a couple of bland numbers and no product-level ARR, segmentation or reporting. _Why it matters:_ Teams underestimate this because the front end looks simple. The permutations behind even an on-paper simple offer — dependencies, quantity thresholds, usage tiers — need a serious logic engine. _For:_ RevOps Leaders, Revenue Executives, Finance Leaders 3. **The real limitation of out-of-the-box quoting is guardrails, not features** — Derek knew before checking that HubSpot native quoting would not reach the blueprint, and the deciding factor was the inability to constrain sellers. In the custom build, a 36-month deal simply does not offer monthly billing in the rep's view. _Why it matters:_ Removing the option is better than catching the error later. It avoids going back to a customer to say the terms they were quoted are not available. _For:_ RevOps Leaders, Sales Leaders 4. **Model your top reps the way you would model top performers anywhere** — Derek goes into conversation intelligence and breaks down how the best sellers actually sell. What he usually finds is the simplest approach — an honest conversation, a clear read on what the customer needs, and speed. _Why it matters:_ That becomes the guided selling. Looking at the schema, the tools and the data will not surface it; talking to the people using the system will. _For:_ RevOps Leaders, Sales Leaders, Revenue Executives 5. **Discovery surfaced an entire quoting scenario nobody had mentioned** — A rip-and-replace, where the existing contract is voided and superseded. The system needs to look back at the old records, find the differences and set credits — something out-of-the-box CPQs cannot do without heavy customisation. _Why it matters:_ Leadership confirmed they wanted to keep selling that way because it produces more revenue, so it became a first-class scenario with its own contract language and its own update to the billing system. _For:_ RevOps Leaders, Revenue Executives, Sales Leaders 6. **The four-step build: scenario, products, commercial terms, review** — Scenario selection first, because the motion determines everything the quote offloads downstream. Then products, add-ons, quantities and discounts with a live TCV, ARR and MRR summary. Then commercial terms — the most important step for the payload. Then a review screen where nothing is editable. _Why it matters:_ Derek designed it as what the front-end user needs to do, not how the plumbing works. Other platforms call these workflows; here they are quoting scenarios. _For:_ RevOps Leaders, Revenue Executives 7. **The payload grew from ten fields to seventy** — Claude Code reproduced the four-step blueprint almost exactly. The part that needed real work was writing back to the deal and creating line items, and the field count kept climbing as the reporting appetite grew. _Why it matters:_ The build effort is not in the interface. It is in deciding what the business wants to report on and making every quote produce it consistently. _For:_ RevOps Leaders, Revenue Executives 8. **Co-termed expansion ARR was the number they could not trust** — Proration was being done in a calculator or a spreadsheet. Now the start date is entered, the end date is pulled automatically, the exact day count is known, and the proration is calculated from it. _Why it matters:_ Going into a funding round you are asked about expansion pipeline and year-over-year expansion growth. An ARR figure a rep typed in is not an answer. _For:_ RevOps Leaders, Finance Leaders, Revenue Executives 9. **Honest churn and early renewals are design problems, not reporting problems** — Churn could only be established by a rep typing it in or by checking the finance system for when billing stopped — neither works when you need net revenue retention off the cuff. Early renewals compound it: new paper, usually an upsell, on a contract renewing two months early, so one contract is ending while another begins and the revenue in that window needs correct treatment. _Why it matters:_ Both have to be driven by the renewal motion in the system rather than reconstructed afterwards. These are the edge cases that never appear in a feature comparison but decide whether your revenue reporting is defensible. _For:_ RevOps Leaders, Finance Leaders, Customer Success 10. **Post-launch changes take about fifteen minutes** — A billing-contact override was added in fifteen minutes when it turned out reps needed to send invoices to an AP address rather than the signer. The controlled end-of-year discount took fifteen to twenty. _Why it matters:_ That iteration speed is the case for building — but it only holds for an organisation that is genuinely AI-heavy and agent-savvy enough to keep making changes safely. _For:_ RevOps Leaders, Revenue Executives 11. **The maintenance tax: who owns your CPQ at 2am** — HubSpot's legacy app platform upgrade was going to remove the serverless functionality Derek's React extension depended on. He watched the forums, judged they would walk it back, and they did — the migration then took thirty minutes. _Why it matters:_ That one came with four months of notice. An API change can arrive in the middle of the night with none, and the build-versus-buy question is really whether you have someone who can respond. _For:_ RevOps Leaders, Revenue Executives, Founders 12. **Your billing software dictates the architecture** — Stripe requires the CPQ and CRM to work a particular way; Maxio, PandaDoc Payments and others each impose their own shape. Derek singles out Rillet for making billing simple and asking very little of the CRM — the smallest data mapping he has done. _Why it matters:_ Build versus buy is decided less by CPQ features than by what the billing and subscription layer demands and whether the three systems can communicate flawlessly. _For:_ RevOps Leaders, Finance Leaders, Revenue Executives 13. **When to buy instead: complexity, deal rooms, and not wanting to manage it** — Derek would reach for enterprise-grade tools when products and dependencies are complex, when enterprise deals are heavily multi-threaded with documents going back and forth, or when nobody wants to own it. DealHub is his top-rated standalone, largely for its deal room. _Why it matters:_ The inverse is where custom wins: high-volume, fast-paced SMB motions where enterprise systems working through APIs and over-built guided selling slow you down. _For:_ RevOps Leaders, Revenue Executives, Founders 14. **Reconciliation and alerting is the underrated last mile** — A closed-won deal with a known invoice schedule should reconcile against the billing system automatically. If the account-side number stays at zero, or sits five days past when it should have billed, you want an alert immediately — not a quarterly review. _Why it matters:_ Five days late is an awkward conversation with a customer expecting the invoice weeks ago. Derek also warns against adapting custom objects to a billing system, and cites a Stripe sync overwriting contact names with company names because it was designed for consumer subscriptions. _For:_ RevOps Leaders, Finance Leaders 15. **Trust in the data, not speed, is where teams fall short** — Most projects start with the right intention — get a good tool, remove friction, speed the reps up — and stop before asking how the data will hold up across systems and over time. _Why it matters:_ Everything comes off this one deal: future expansions, churn, auto-renewals, early renewals, upsells. Get it wrong once and it propagates. Derek's stated focus is building confidence in the system, on the view that speed follows from it. _For:_ RevOps Leaders, Revenue Executives, Finance Leaders ## Frameworks ### The Four-Step CPQ (26:43) **Definition:** Scenario selection, product configuration, commercial terms, and a locked review step — designed around what the front-end user must do rather than how the plumbing works. The scenario sets up everything the quote will offload downstream. Commercial terms carry the heaviest payload. The review screen is deliberately uneditable, with a controlled one-time discount capped by the earlier steps. ### Model Your Top Reps (11:17) **Definition:** Treat guided selling design the way you would treat replicating any top performer: go into conversation intelligence, break down how the best sellers actually sell, and encode that rather than an idealised process. Derek's consistent finding is that the best reps use the simplest approach. The design job is to remove everything between them and a shareable proposal. ### Guardrails Over Features (29:50) **Definition:** The binding constraint on out-of-the-box quoting is not what it can produce but what it fails to prevent. Restrict the options a scenario allows rather than correcting errors after the quote goes out. A 36-month deal does not offer monthly billing in the rep's view. The discount is capped by values derived from the preceding steps rather than typed in freely. ### Map the Full Quote-to-Cash Stack First (15:26) **Definition:** Before recommending anything, map CPQ, contract lifecycle management and billing/subscription — plus ERP or accounting where relevant — and confirm they can communicate flawlessly. If an element of one system is unavailable in another, that is the moment to hit the abandonment button and change direction rather than discovering it mid-build. ### Alerting, Not Quarterly Reconciliation (52:08) **Definition:** Automate granular alerts for the things you expect to go wrong — an invoice schedule that has not appeared, a billing date that has slipped — instead of reconciling on a quarterly cadence. A known $100,000 invoice schedule that leaves the account record at zero, or bills five days late, should surface immediately rather than in a review. ## Quotes _Speakers inferred from an undiarized transcript — verify before attributing._ > "Oh these are nice to have automation so that way we can not have to do as much work." > > — Derek Mogar, The LeanScale Podcast Ep. 108 (01:29) > "if we don't do this it could put deals at risk, if billing looks funky it could put our reputation at risk" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (01:35) > "Not gonna call it a love story but it was a love at first sight when they saw it." > > — Derek Mogar, The LeanScale Podcast Ep. 108 (02:25) > "They loved it immediately and they're basically just said well why don't we just use this" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (03:26) > "it was kind of just a wild wild west from what you can see in the data" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (04:52) > "it was almost like a one-trick pony. You can put a product in there. You can select a quantity." > > — Derek Mogar, The LeanScale Podcast Ep. 108 (06:31) > "it's driving how your contracts are laid out, how your proposals are laid out, your commission systems, your forecasting." > > — Derek Mogar, The LeanScale Podcast Ep. 108 (06:56) > "it creates repeatable, confident, stable, structured data" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (08:21) > "For sales teams we want them spending as much time with the customers, not buried in tools, not buried in calculations." > > — Derek Mogar, The LeanScale Podcast Ep. 108 (09:14) > "you have a lot of legacy technical debt that gets built up over time" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (09:39) > "mapping that out completely end-to-end as well as anything net new that is going to be coming in, that's day one." > > — Derek Mogar, The LeanScale Podcast Ep. 108 (09:50) > "you want to find your top performers and try to replicate what they're doing" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (11:17) > "I want to understand what the top sales people are doing, how are they selling the product, let's go into conversation intelligence" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (11:25) > "actually talking to the people that use these systems is really really helpful" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (12:06) > "Those all need to work together flawlessly." > > — Derek Mogar, The LeanScale Podcast Ep. 108 (15:26) > "you want to prepare for the future" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (16:52) > "basis what I would have been talking about from quote to cash six months ago" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (17:48) > "part and I spent about two months in the data before we got to this point" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (20:20) > "guardrails every single selling motion is a little bit different on the front" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (20:40) > "you're constantly looking for those metrics that signal growth and you couldn't get an honest number out of the expansion pipeline" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (21:21) > "them to really show accurate churn was was essential and right now the only way to show churn was relying on manual input by the rep or going into the finance system and see when billing stopped" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (21:53) > "it gave them an accurate number not something that they couldn't trust" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (23:34) > "if you can make it if you can do this in two days what can you do in 30 days" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (25:16) > "so the next 30 days was just hardening the code making sure it was production ready" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (25:20) > "with this like AI invincibility cloak that everyone has" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (25:34) > "able to control the user interface control the quoting scenarios put the guardrails on that kept the data accurate" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (25:56) > "I so I started with a simple diagram of what the process should look like" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (26:43) > "we don't want to allow monthly billing for that we want that to be billed annually or all up front" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (29:50) > "Claude enables you to do that really really fast but it took my brain dump and the blueprint that I created and it almost like to a T created it perfectly" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (33:36) > "initial one was a like a ten field payload and it grew to 50 and then 60 70 it kept growing because of what they wanted to report on" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (33:55) > "I think every change that we made post-launch took about 15 minutes and it was live tested in production" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (37:06) > "the billing software billing and subscription software is going to dictate a lot of that" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (38:30) > "specifically for build versus buy do we have the team to support it long term do we have someone that can understand if there's if an issue pops up" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (39:51) > "there's other ones that are going to come an API update for example that you don't get to prepare for it just hits you middle of the night" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (41:57) > "you want somebody that is going to introduce innovation to it" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (42:56) > "the high high volume fast-paced SMB they need to get it out quickly those enterprise systems are gonna slow you down a little bit" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (44:02) > "that CPQ tends to be the brain of everything and pushing the information everywhere where it needs to go" > > — Anthony Enrico, The LeanScale Podcast Ep. 108 (45:11) > "the North Star for it is I want to see the CRM data the contract data lock step" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (48:39) > "which I would I would never recommend because it creates a lot of complexity in the system that is unnecessary" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (51:31) > "something that's like a underrated part of quote to cash is just reconciliation and alerting and monitoring" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (52:08) > "you want to be alerted to that immediately if you see that it goes five days past the day that it should have been billed" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (53:03) > "compromise certain deals so this is not like oh these are nice to have automation so that way we can not have to do as much work" > > — Anthony Enrico, The LeanScale Podcast Ep. 108 (55:06) > "the trust and reliability of the data is where a lot of teams setting up quote to cash CPQ they don't go to that level of detail" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (56:28) > "it's not just the one deal it's future deals it's future expansions it's future churn auto renewals" > > — Derek Mogar, The LeanScale Podcast Ep. 108 (56:44) ## Practical advice by role ### RevOps Leaders - Map CPQ, document handling and billing end to end before recommending anything; if one system cannot supply what another needs, change direction now. - Design the quoting scenarios first — the motion determines the entire downstream payload. - Constrain the rep's options per scenario rather than correcting bad quotes afterwards. - Decide the reporting you want out of the CPQ up front, and build for 12–18 months ahead, not just today. - Automate granular alerts on invoice schedules and billing dates instead of reconciling quarterly. ### Revenue Executives - Treat quote-to-cash as revenue risk, not convenience automation — bad billing damages reputation and stalls deals. - Ask whether you can produce an honest expansion ARR and churn number off the cuff; if not, that is a system problem. - On build versus buy, the question is whether you have someone who can respond to a platform change with no notice. - Empower reps within guardrails: quoting friction shows up in conversion rate, cycle time and closed-won volume. ### Finance Leaders - Run the data mapping exercise with the billing vendor's technical team before any CPQ work begins. - Never adapt custom CRM objects to fit a billing system — the complexity it creates is unnecessary. - Check what a billing sync actually writes; a Stripe-to-HubSpot sync can overwrite contact names with company names. - Make sure early renewals and co-termed expansions have defined revenue treatment before they appear in a board deck. ### Sales Leaders - Look at how your top reps sell in conversation intelligence, then design guided selling around that. - Give reps a controlled end-of-year discount mechanism rather than an ad-hoc approval scramble. - Give them live TCV, ARR and MRR on the quote screen so the numbers are not a surprise later. ## AI takeaways **Thesis:** The headline is a two-day build, but the argument underneath is that AI collapsed the implementation cost of a CPQ without changing any of the thinking that has to precede it. Derek spent two months in the data, designed a four-step blueprint around the seller, and only then handed it to Claude Code — which reproduced the interface almost exactly and left him with the genuinely hard part, the seventy-field payload that makes the reporting trustworthy. - **** — - **** — - **** — - **** — - **** — - **** — - **** — **Agent & automation ideas** - A quoting scenario engine where the selected motion determines the fields, terms and downstream payload. - Automatic proration from exact day counts on co-termed expansions, replacing spreadsheet calculations. - Rip-and-replace handling that looks back at superseded contracts, computes differences and sets credits. - Reconciliation alerting that fires when an invoice schedule fails to appear or slips past its billing date. - Lifecycle stage automation driven by document events — sent, signed — rather than manual rep updates. - A billing sync auditor that checks what a vendor integration actually writes into CRM fields. ## Operations takeaways ### Revenue operations - **.** - **.** - **.** - **.** - **.** ### Pipeline & marketing ops - **.** - **.** - **.** - **.** ### Customer operations - **.** - **.** - **.** ## Metrics mentioned | Value | Metric | Context | | --- | --- | --- | | ~$60K | Platform being replaced | The full-stack quote-to-cash system the customer had spent two months evaluating. | | 2 days | MVP build time | A working four-step CPQ inside HubSpot, including invoice schedule setup, built to demonstrate advanced selling. | | ~2 months in the data | Discovery time | Run in parallel with the customer's own platform evaluation. | | ~30 days | Hardening to production | What followed the MVP — making the code production-ready for dozens of reps. | | 10 fields → 50, 60, 70 | Deal payload | Properties written back to the deal and line items, growing with the reporting requirements. | | ~15 minutes | Post-launch change cycle | Including the billing-contact override and the controlled end-of-year discount, live tested in production. | | 20–50 reps | Users on the system | The scale the build had to hold for, confirmed by LeanScale's engineering team before launch. | | 4 months' notice, 30 minutes' work | Platform migration | HubSpot's legacy app platform upgrade, once serverless functionality was reinstated. | | 5 days | Reconciliation alert threshold | An invoice sitting five days past its due date is already an awkward customer conversation. | ## Entities mentioned - **LeanScale** (company) — Derek is an architect here, and the engagement described is a LeanScale project. Anthony notes the firm has worked on organisations where every line item carries its own terms, start dates and delivery dates, and Derek brought LeanScale's engineering team in to pressure-test whether the build would hold for 50 reps. · https://www.leanscale.team/knowledge/company/leanscale/ - **Subskribe** (company) — Derek pushed hard for it early in the year because of the colliding PLG and sales-led motions, and much of his blueprint drew on its guided-selling model. It was acquired mid-evaluation, which took it off the table — going in as a vendor is acquired risks onboarding twice. · https://www.leanscale.team/knowledge/company/subskribe/ - **HubSpot** (company) — The CRM the custom CPQ was built inside, using a React extension UI. Also the source of the maintenance scare: the legacy app platform upgrade was going to remove serverless functionality before HubSpot reversed course two months later. · https://www.leanscale.team/knowledge/company/hubspot/ - **Derek Mogar** (person, guest) — · https://www.leanscale.team/knowledge/guest/derek-mogar/ - **Anthony Enrico** (person, host) — Co-founder of LeanScale and host of The LeanScale Podcast. · https://www.leanscale.team/knowledge/guest/anthony-enrico/ - **Claude Code** (tool, AI Dev Tool) — Used to turn Derek's blueprint into a HubSpot extension UI. It reproduced the four steps almost exactly; the part needing rework was the deal update and line item creation, whose payload grew from ten fields to seventy. - **HubSpot** (tool, CRM) — The environment the CPQ lives in. Native quoting was ruled out on guardrails rather than features, and Derek is watching the revamped Revenue Hub, which is aimed at co-termed expansions, ramp deals and year-over-year escalators. - **Maxio** (tool, Billing) — The billing and subscription platform this customer used, updated automatically when a rip-and-replace quote is applied so the system knows the new contract supersedes the old one. - **Rillet** (tool, Billing / ERP) — Derek's tool shout-out: it made billing simple and asks very little of the CRM — the smallest data mapping exercise he has run, which widens how far a custom CPQ can be taken. - **Stripe** (tool, Payments / Billing) — Cited twice: as a billing system that forces the CPQ and CRM into a particular shape, and as the source of a sync that overwrote contact first and last names with the business name because it was designed around consumer subscriptions. - **DealHub** (tool, CPQ / Quote-to-Cash) — Derek's top-rated standalone CPQ, largely for its deal room — useful on enterprise deals with many documents and multi-threaded buying groups. Recently acquired Subskribe, which should help on subscription billing. - **Subskribe** (tool, Quote-to-Cash / CPQ & Billing) — The platform Derek recommended for the colliding PLG and sales-led motions, and the basis for much of his guided-selling blueprint, until its acquisition made the timing too risky. - **Ironclad** (tool, CLM) — Derek's preferred contract lifecycle management system where there is procurement, redlining and robust MSAs, chosen for how it handles documents across the contract lifecycle. - **PandaDoc** (tool, CPQ & Quoting) — Named among the document and payment options whose setup and customisation burden customers describe as one of the biggest pain points in quote-to-cash. - **Salesforce CPQ** (tool, CPQ / Quote-to-Cash) — No longer being sold, though existing customers can continue using it, with open questions about how Revenue Cloud's architecture will affect implementations. ## FAQ **Q: How did a two-day MVP become a production CPQ?** A: Derek Mogar set out only to show the customer what advanced selling could look like inside HubSpot, using an extension UI. They had already spent two months evaluating full-stack quote-to-cash platforms with sixty-thousand-dollar price tags, and their sales-led and product-led motions had started to collide. When they saw the MVP their reaction was to ask why they did not simply build on it and make it the system the whole sales team runs on. The next thirty days were spent hardening the code for production, and it is now what dozens of reps use. **Q: What can you not do with out-of-the-box quoting?** A: The limitation is guardrails, not features. In the customer's previous setup everything was sold the same way, there were no restrictions on what a rep could edit, and there were no product SKUs — so no product-level ARR, segmentation or meaningful reporting. You could add a product, set a quantity and apply a discount, and get a couple of bland numbers out. Derek describes it as a one-trick pony, and notes that the CPQ is actually driving contracts, proposals, commissions and forecasting, so everything downstream inherits whatever it produces. **Q: What are the four steps of the build?** A: First, scenario selection — which selling motion is this, which then determines everything the quote will offload downstream. Second, products: the SKUs, add-ons, services, quantities, seats and discounts, with a live summary showing total contract value, ARR and MRR breakdowns the team had never previously had. Third, commercial terms — billing frequency, payment terms, the billing contact — which Derek calls the most important step because of the payload it produces. Fourth, a review step where nothing is editable, plus a controlled one-time discount whose ceiling is derived from the previous three steps. **Q: How do you handle co-termed expansions accurately?** A: The problem was that proration was being done in a calculator or a spreadsheet, so nobody could trust the ARR. In the build, the rep enters the start date, the end date is pulled automatically, the exact number of days in the co-term is therefore known, and the proration is calculated from that number. That matters most going into a funding round, where you are asked what the expansion pipeline looks like and what year-over-year expansion growth is — questions you cannot answer with figures a rep typed in by hand. **Q: How should churn and early renewals be handled?** A: Before the build, the only ways to establish churn were a rep entering it manually or someone checking the finance system to see when billing stopped — neither of which works when you need net revenue retention on demand. Early renewals are the related edge case: new paper, usually with an upsell, on a contract that renews two months early, creating an overlap where one contract is ending while another begins. The revenue in that window has to be tracked correctly, which means the renewal motion itself has to drive the records rather than being reconstructed afterwards. **Q: When should you build a custom CPQ instead of buying one?** A: Derek's first filter is the billing and subscription software, because it dictates how the CPQ and CRM must work — Stripe imposes one shape, Maxio another, and he singles out Rillet for asking very little of the CRM. His second filter is support: do you have someone who can respond when the platform changes, potentially with no notice. Custom wins for high-volume, fast-paced SMB motions where enterprise systems working through APIs and over-built guided selling slow you down. He would buy where products and dependencies are genuinely complex, where enterprise deals need a deal room for multi-threaded document exchange, or where nobody wants to manage it — DealHub being his top-rated standalone. **Q: What is the maintenance tax on a custom CPQ?** A: HubSpot's legacy app platform upgrade was going to remove the serverless functionality that Derek's React extension depended on. He watched the customer forums, judged from HubSpot's own language that they would reinstate it, and they did two months later — after which the migration took about thirty minutes. That one came with four months of notice. His point is that other changes, an API update for example, arrive in the middle of the night with none, so the organisation needs someone watching for them who can act quickly. **Q: What does the last mile of quote-to-cash look like?** A: It starts with a conversation with the billing vendor's technical team to map, top to bottom, what data they need for invoices to be created correctly — including how something like a one-time end-of-year discount has to be passed over, and which objects can be pulled from. Derek warns against adapting custom CRM objects to fit a billing system, which creates unnecessary complexity. Then comes the underrated part: automated, granular alerting rather than quarterly reconciliation. If a closed-won deal with a known $100,000 invoice schedule leaves the account record at zero, or the billing date slips five days, you want to know immediately. **Q: Where do most quote-to-cash projects fall short?** A: Trust and reliability in the data. Derek's view is that teams start with the right intention — buy a good tool, remove friction, speed the reps up — and stop before working through how the data will behave across systems and over time. The consequence is that it is never just one deal: future expansions, churn, auto-renewals, early renewals and upsells all descend from the record that deal creates. He says this is deliberately where he spends most of his time, on the basis that reduced friction and increased velocity follow from a system people trust rather than substituting for it. ## Timeline - **00:00** — Cold open + intro - **01:47** — When the throwaway MVP became the product - **05:15** — The environment: colliding sales-led and product-led motions - **07:09** — The gotchas of quoting in spreadsheets or out-of-the-box tools - **11:05** — Model your top reps: discovery, conversation intelligence, rip-and-replace - **14:39** — How he approached the build: mapping the full tech stack - **20:19** — The three hardest problems: co-termed expansions, churn, early renewals - **26:27** — The four-step build and the 50–70 property payload - **32:26** — Building it with Claude Code as a HubSpot extension UI - **35:05** — From MVP to production-grade: hardening and battle testing - **38:06** — Build vs. buy: when custom isn't enough - **42:27** — The maintenance tax: the HubSpot serverless scare - **50:28** — The last mile: invoicing, billing, and reconciliation - **55:13** — Why this isn't nice-to-have — it puts deals and reputation at risk ## Related episodes - **Ep. 106: How She Runs All of RevOps From the Terminal** (Sarah Madden (FERMÀT)) — The same build-it-yourself instinct, including a lightweight Salesforce-to-SpotDraft integration used instead of a CPQ. - **Ep. 103: Why Your Reps Should Never Open the CRM Again** (Justin Lee (Superblocks)) — Internal applications built over the CRM, and the same question of how much a seller should have to touch directly. - **Ep. 104: The State of the GTM Stack** (null) — The consolidation and M&A across CPQ, billing and subscription tooling that shaped this build-versus-buy decision. - **Ep. 91: Why Outcome-Based Pricing Is a Trap for Most AI Companies** (Roee Hartuv) — The pricing and packaging complexity a CPQ has to encode, argued from the model design side. · https://www.leanscale.team/knowledge/podcast/roee-hartuv-outcome-based-pricing-trap/ - **Ep. 100: AI Ops: How We Run RevOps for 30 SaaS Companies at Once** (Jake Toepel (LeanScale)) — The same field practice at portfolio scale — what LeanScale builds and maintains across clients. - **Ep. 105: You Built a Brilliant AI Agent — Now Get 300 People to Use It** (Christopher O'Donnell (Day AI)) — The gap between a working build and something dozens of people run on every day. ## Full transcript _Machine-transcribed and not diarized; speaker attribution is inferred._ _Transcript only, as a separate file: https://www.leanscale.team/knowledge/podcast/derek-mogar-cpq-inside-hubspot-two-days/transcript.md_ ### 00:00 — Cold open + intro **[0:00]** And those changes are gonna impact the, you know, the way that the contracts are **[0:04]** built or handled. That's gonna be really important that you have someone that **[0:07]** knows that and owns it and can make sure that those processes are keeping up **[0:11]** with one another. My guest today is Derek Mogar, one of the architects here at **[0:17]** LeanScale. Derek, this is a fun one. I'm really excited to get some of the **[0:21]** projects that were running in the field and share it with our audience. So one of **[0:28]** the trickiest things when it comes to CPQ and quote-to-cash in general is **[0:34]** everything that drives the downward systems and motions of your go-to-market. **[0:39]** Some of the downstream effects like billing and reporting, some of those **[0:45]** nuances really require a strong CPQ in place. What are some limitations they're **[0:51]** gonna run into and some things they might not have? I think reconciliation **[0:56]** and alerting and monitoring, that's not something that I would recommend doing **[1:02]** on a quarterly basis. If you can automate like alerts of things that you expect to **[1:06]** come up and there's a lot that could potentially come up, you want to make **[1:11]** sure that you surface those things immediately. A lot of people don't think **[1:15]** about that part but there's so many different things that require a really **[1:20]** really strong logic engine just to produce the quote, let alone document **[1:25]** everything and connect it to your other systems for reporting and intelligence **[1:29]** purposes as well. Oh these are nice to have automation so that way we can not **[1:35]** have to do as much work. This is, oh if we don't do this it could put deals at **[1:40]** risk, if billing looks funky it could put our reputation at risk, it doesn't look **[1:44]** good to a customer if you send a bill with the wrong name or don't bill them ### 01:47 — When the throwaway MVP became the product **[1:47]** and try to bill them later, it just looks like you don't have your house in order. **[1:54]** Derek this is a fun one, I'm really excited to get some of the projects that **[1:59]** were running in the field with actual B2B SaaS AI companies and share it with **[2:07]** our audience. So with this one you set out to show the customer a demo of what **[2:13]** advanced selling could look like and you ended up walking away building a **[2:19]** production level CPQ. When did you realize that the typical throw MVP **[2:25]** actually became the product? Not gonna call it a love story but it was a love **[2:32]** at first sight when they saw it. As you said you know we set out to really just **[2:38]** show them what advanced selling looks like inside of HubSpot because HubSpot **[2:44]** is so accessible it's really easy to show off a lot of MVPs. You have an idea **[2:49]** it's really easy to bring it to life but I use all of my knowledge and **[2:54]** experience with CPQ, quote to cash, my background in sales and a lot of **[2:59]** discovery and diving into the data before that happened to really tailor **[3:05]** this MVP to how they sell, the different types of selling motions that they have **[3:10]** addressing some of the different pain points that they have and now I'm not a **[3:15]** developer or coder I understand it and I can be dangerous with it at times but I **[3:20]** understand design really well and that really assisted kind of building it out **[3:26]** to where they saw it. They loved it immediately and they're basically just **[3:31]** said well why don't we just use this like why don't we build on this and make **[3:35]** this kind of the go-to system for everything that the sales team does. So **[3:41]** it really started as just like hey I just want to show them something really **[3:45]** cool in HubSpot, something maybe that they haven't seen because coming into **[3:50]** this they actually already had two months of research into different like **[3:54]** full-stack kind of quote to cash systems, different CPQ systems, different billing **[4:00]** and subscription systems and they had kind of started leaning towards one and **[4:04]** then something that you mentioned sales lead and product lead started to collide. **[4:10]** Those you know don't tend to act very nice when it comes to billing and **[4:16]** subscriptions. The way that they enter the system, the way that they grow, they're **[4:20]** vastly vastly different. So we came in had a really really good time to just **[4:26]** start talking about it, start really digging in with the sales team. How do you **[4:31]** actually sell today? From the data we can see a lot of the issues already. We can **[4:36]** see that the lack of guardrails, the lack of kind of decision-making when it **[4:42]** comes to selling a certain type of product or selling a certain type of **[4:47]** motion like a renewal or an expansion or an enterprise product skew, those were **[4:52]** all things that it was kind of just a wild wild west from what you can see in **[4:57]** the data and even when we were doing walkthroughs with the sales team you can **[5:00]** see that just very very clearly. So that was something that I didn't set out to **[5:06]** prove against. They knew they needed a new solution. What I didn't think is **[5:12]** that it was going to be this MVP that we were just standing up to show them how ### 05:15 — The environment: colliding sales-led and product-led motions **[5:17]** the full quote to cash system could work. Maybe let's walk through exactly the **[5:24]** environment that you're walking into because all selling motions are not **[5:29]** created equal. There's certain things that make selling certain products or **[5:34]** services more difficult than others. So what did the environment look like? I've **[5:37]** heard some product led motions, some sales led motions, but what are the **[5:41]** details of how they sold, how they sold their products and some of the **[5:44]** challenges that have brought up? So one of the trickiest things when it comes to **[5:49]** CPQ and quote to cash in general is everything that drives the downward **[5:55]** systems and motions of your go-to-market. So you can sell one product one way. It **[6:02]** may have 15, 16 different conversions. It definitely has you know eight to ten **[6:07]** different ways that it can be billed, sliced and diced. What they had in **[6:11]** place before was almost like a single motion. Everything was sold the same **[6:16]** exact way. There were no restrictions around like what could and could not be **[6:20]** edited. HubSpot does have some natural like out-of-the-box limitations when it **[6:26]** comes to B2B SaaS Rev Rec and we can probably get into a lot of those later **[6:31]** but it was almost like a one-trick pony. You can put a product in there. You can **[6:35]** select a quantity. There's no product SKUs so there's no way to do any kind of **[6:40]** reporting or segmentation or product level ARR. You can add the discount and **[6:45]** then that's it. It's giving you a couple kind of bland numbers out of that engine **[6:50]** but there's so much more that you need from a CPQ system because ultimately **[6:56]** it's driving how your contracts are laid out, how your proposals are laid out, your **[7:02]** commission systems, your forecasting. Like everything is kind of branching off of **[7:07]** really the CPQ as the starting point but really the quote to cash system as a ### 07:09 — The gotchas of quoting in spreadsheets or out-of-the-box tools **[7:11]** whole. Yeah I think you mentioned a couple things where I think a lot of **[7:17]** people have a simplistic view of oh I just need to build a quote. I probably **[7:22]** need to put a couple line items, quantities, lock and load but some of the **[7:27]** downstream effects like billing and reporting some of those nuances really **[7:32]** require a strong CPQ in place because that's kind of the beginning of that **[7:39]** process. What are some gotchas that people either not using a CPQ they're **[7:45]** just doing things maybe in like Google Sheets or Google Docs or they're just **[7:51]** using very simple out-of-the-box stuff. What are some limitations they're going **[7:54]** to run into and some things they might not have because they're not using a **[7:58]** proper CPQ? So I'm gonna dabble into revenue intelligence on this one just **[8:05]** because one of the most important things outside of the data being in a single **[8:10]** environment that is consistent, clean, it's structured and that's what a CPQ **[8:16]** sets the tone for across your entire go-to-market across the entire quote to **[8:21]** cash is that it creates repeatable, confident, stable, structured data. When it **[8:29]** comes to revenue you know tons of formulas out there there's tons of **[8:32]** calculations that are driving it in the back end. For us we want to make it as **[8:37]** easy as possible for a sales rep to go in there, build a proposal, have confidence **[8:42]** in the output and get a signature as quick as they possibly can. We don't want **[8:47]** to really distract them with having to go build out these elaborate pricing and **[8:52]** quoting tables. They should be filling out a couple questions in the guided **[8:56]** selling. There should be the products, the few configurations that go with that **[9:01]** product and everything else should be done for them. It should be really a **[9:05]** couple you know minutes in there depending on you know how complex the **[9:10]** the pricing and selling is. It might take a little bit longer but it should get **[9:14]** them to sharing something with the customer. For sales teams we want them **[9:18]** spending as much time with the customers, not buried in tools, not buried in **[9:23]** calculations. We want to try to restrict and reduce the number of errors that can **[9:29]** happen with say a spreadsheet or can happen just trying to use like out of the **[9:34]** box HubSpot properties or even in Salesforce. When I've done quote-to-cash **[9:39]** and CPQ in Salesforce you have a lot of legacy technical debt that gets built up **[9:45]** over time. So when you're going into a project like this understanding every **[9:50]** single thing that this might touch, mapping that out completely end-to-end as **[9:54]** well as anything net new that is going to be coming in, that's day one. Like we **[10:00]** have to understand the entire ecosystem before we can recommend changes, before **[10:04]** we can look at tool selection or anything like that. Yeah and I think a **[10:10]** lot of people don't have an appreciation for the complexity behind it and the **[10:15]** permutations of different types of pricing and coding models that you could **[10:20]** have depending on the types of rules that you have in place. So if you have **[10:23]** like product dependencies, so hey you can't buy this product unless you have **[10:27]** this product, if you have any like quantity thresholds, if you have a usage **[10:31]** based product, okay how are you stair-stepping different gates of the **[10:36]** price per unit. There's so many different things that require really really strong **[10:41]** logic engine just to produce the quote let alone document everything and **[10:46]** connect it to your other systems for reporting and intelligence purposes as **[10:50]** well. So there's a lot in here even if you have an on-paper simple product **[10:56]** you'd be shocked at how many permutations of quotes you could develop **[11:02]** with a simple offer. I actually had an interesting conversation with my dad ### 11:05 — Model your top reps: discovery, conversation intelligence, rip-and-replace **[11:06]** this morning, he's been in enterprise sales his entire life but we were going **[11:11]** into just different types of leadership and how as a business, as a company, as **[11:17]** an organization you want to find your top performers and try to replicate what **[11:21]** they're doing. I take the same approach when it comes to quote to cash like I **[11:25]** want to understand what the top sales people are doing, how are they selling the **[11:30]** product, let's go into conversation intelligence and really break down the **[11:34]** ins and outs and a lot of the times you'll find that it's just the simplest **[11:38]** approach. They get on, it's an honest conversation, they know what the the **[11:42]** prospect or the customer needs and wants and they're able to get it to them **[11:46]** really really quickly. So even modeling some of like the guided selling, **[11:51]** simplifying some of those processes is always an approach that I try to apply **[11:56]** when it when getting into quote to cash. You can again look at what exists, you **[12:01]** can look at the data schema, you can look at what you know what tools are in place **[12:06]** today and you can look at the data itself but actually talking to the **[12:11]** people that use these systems is really really helpful and even just looking at **[12:16]** like how they're talking about them, how they're talking about the products. So **[12:20]** I'll use an example with one of the customers that we had. They were going **[12:26]** through a selling motion that wasn't a tip like a standard selling motion like **[12:30]** an enterprise ramp deal or a co-term to expansion. This was a full like rip and **[12:37]** replace. This existing contract is going to be null and void and this one is **[12:41]** going to be replacing it. So there's nothing to handle that within their **[12:45]** system but in talking through discovery we knew like hey this needs to be a **[12:50]** quoting scenario that we need to address for. I think from like the the CPQ **[12:55]** standpoint it's about the same. You're building products, you're assigning terms, **[12:59]** you're going through the same guided selling, but something that the out of **[13:03]** the box CPQs can't do without heavy heavy customization is okay let's go **[13:09]** look back at the records. What is this actually replacing? And then you can find **[13:14]** the differences, you can set credits, you can do a lot more calculations that are **[13:18]** going to give you much better revenue reporting on the back end. So it's little **[13:22]** things like that that won't come up or surface in like looking at the **[13:27]** intangibles but then when you actually talk to the people that are doing it on **[13:31]** the day-to-day that's when you start to uncover a lot more and then you bring **[13:35]** that to leadership like is this how we want to sell, is this something that we **[13:39]** want to continue with and the answer ultimately landed on yes for them **[13:44]** because it's more revenue. Of course we're gonna you know cancel a contract **[13:49]** and they can you know go on a new 12-month or 36-month term with more **[13:52]** seats and products. There's no reason not to do that so build the system and make **[13:58]** it work and with the the extension UI which is how you do a custom CPQ inside **[14:05]** of HubSpot we just built out a new scenario for that. So now you have a new **[14:09]** scenario it can easily handle that and everything on the back end gets done, new **[14:14]** language goes in the contract that's getting inserted, Maxio which is a **[14:21]** billing and subscription platform that gets updated and it knows that hey this **[14:25]** is going to replace this contract. So all that identity resolution is happening in **[14:29]** the back end because of just a simple discovery and seeing that this was **[14:33]** something that they needed. So I'd love if you could walk through exactly how ### 14:39 — How he approached the build: mapping the full tech stack **[14:39]** you built it. I know a lot of this was AI powered but how did you approach it? How **[14:46]** did you feed the context? How did you deploy it? All of the details if somebody **[14:51]** could try to figure this out for their own. How did you put it all together? I **[14:55]** guess the one of the initial steps that you want to take is you need to map the **[15:01]** full tech stack that is going to be touched by quote-to-cash. So not just the **[15:06]** the tools that are in place but the typical tools that would be part of **[15:10]** quote-to-cash which would be CPQ, CLM or document handling and billing and **[15:16]** subscription and then maybe you tack on like ERP or accounting systems but for **[15:21]** the most part it's focused around CPQ, document handling and billing and **[15:26]** subscriptions. Those all need to work together flawlessly. If those can't **[15:31]** communicate or there are certain elements of one system that aren't **[15:35]** available in another that's when you have to potentially hit the the **[15:40]** abandonment button and go a different direction. Luckily with this we were able **[15:44]** to do a lot of that very early on so we kind of knew where they were leaning on **[15:49]** the billing and subscription side so we knew what that what that data model **[15:54]** needed to look like. So that made it a little bit easier. The other part of just **[16:00]** CPQ in general is what reporting do we want to get out of this and you don't **[16:05]** need to overload it. If you build it the right way you can always get additional **[16:09]** reporting but do we want to report you know year-over-year ARR growth for a **[16:15]** multi-year deal? Do we want to be able to really granularly track like product **[16:20]** level ARR or do we want to is contracted ARR and bookings is that the only thing **[16:24]** that's important to us? So you start to go down this list and we have a full **[16:28]** you know library built out of all the different revenue fields and and **[16:34]** potentially you can get out of a correctly set up CPQ and we just start **[16:38]** to go down the list. What of this is important to you? This is what it could **[16:43]** potentially deliver depending on where they are in their funding stages to **[16:46]** certain ones might be more important now than they are in the future but I would **[16:52]** push back and be like well you want to prepare for the future. You know we're **[16:55]** building something here in the present and it's gonna service you very well but **[16:59]** we also want to look six months down the road, 12 months down the road, 18 months **[17:03]** down the road. What are you know the product and price book changes that **[17:07]** you're gonna be going through? Are you thinking about AI? Are you gonna be **[17:11]** bringing on a you know partner channel or something like that that might need to **[17:15]** be serviced by this a little bit differently and there are actually point **[17:19]** solutions for like partner CPQs out there that I would definitely recommend **[17:24]** potentially looking at but it's a it's a great way to allow partners to co-sell **[17:30]** and sell on your behalf so there are options like that out there as well but **[17:35]** it's you got to think ahead you can't just think about the here and now you **[17:40]** have to think about where the organization's gonna be what the world's **[17:44]** gonna look like six months from now with AI it changes on a daily and a weekly **[17:48]** basis what I would have been talking about from quote to cash six months ago **[17:52]** to what we're talking about now has dramatically shifted and it's gonna **[17:57]** continue to change I think within the industry just specifically talking about **[18:02]** you know CPQs and subscription and building software 2025 you saw big **[18:07]** consolidation you saw a lot of new kind of all-in-one solutions come up you saw **[18:13]** a lot of M&A activity across the board that's gonna continue to happen one **[18:18]** thing I haven't seen but I'm actually really excited to check out is the hub **[18:22]** spot revenue hub which just got totally revamped by an acquisition that they had **[18:27]** earlier 2025 might have been end of 2024 but they in that kind of roll out one of **[18:34]** the biggest things they were trying to address is how do we make this more than **[18:39]** just a singular subscription system and you know singular like e-commerce style **[18:44]** sales and revenue system so a lot of what they've a lot of the R&D that they **[18:50]** put into revenue hub is specifically addressing that some of the most like **[18:54]** advanced selling motions co-termed expansions ramp deals you're over your **[19:00]** escalators all of these are some of the toughest to figure out as a rev ops **[19:04]** person but they're starting to lean that way because they see the benefit of **[19:09]** having a fully robust and native CPQ built out within HubSpot yeah the tech **[19:18]** stack is definitely going through quite a bit of an evolution on the HubSpot side **[19:22]** investing in their own Salesforce end of sailing Salesforce CPQ so not end of **[19:30]** lifing it if you have you can still use it but they're not selling it anymore and **[19:33]** there's still a lot of unknowns about their revenue cloud architecture and how **[19:39]** that's going to impact and then there's a few bigger players like deal hub they **[19:43]** just acquired subscribe which should help with that subscription based billing **[19:47]** but yeah it's starting to feel like there's some consolidation there might **[19:52]** be a couple obvious choices but in the meantime you chose to build it on your **[19:57]** own so once you have the discovery done you knew exactly the motions they needed **[20:02]** to account for you knew what the reporting looked like the downstream **[20:04]** effects all the blueprint of exactly what you needed to build how did you **[20:09]** actually end up building it it started with the data like what do we want that **[20:15]** the data outcome to be when it comes to quote to cash so that that was the first ### 20:19 — The three hardest problems: co-termed expansions, churn, early renewals **[20:20]** part and I spent about two months in the data before we got to this point they **[20:25]** spent two months kind of evaluating different systems and looking at **[20:28]** different CPQ options different billing and subscription softwares but being **[20:34]** in the data the problems were crystal clear the the first thing is the the **[20:40]** guardrails every single selling motion is a little bit different on the front **[20:46]** end to the salesperson it's the exact same I'm getting on the phone I'm **[20:49]** putting together a package I'm sharing it with them but how it needs to work in **[20:54]** the back end is totally different so I started there I started with their **[20:58]** their three biggest problems so the three biggest problems for them were **[21:03]** co-termed expansions they weren't able to get accurate ARR values out of the **[21:07]** co-termed expansions which is a huge miss I think when you're going into a big **[21:11]** funding round like you want to know what does our expansion pipeline look like **[21:17]** what does our year-over-year growth across expansion look like you're **[21:21]** constantly looking for those metrics that signal growth and you couldn't get **[21:26]** an honest number out of the expansion pipeline so that was that was one of the **[21:31]** first things the second thing and this is maybe less to do with quote to cash **[21:36]** and more to do with just renewal motions and churn but how do we honestly churn a **[21:43]** customer at what point does that happen and what does it drive across the rest **[21:47]** of the system so churn was also part of this conversation so building a way for **[21:53]** them to really show accurate churn was was essential and right now the only way **[21:59]** to show churn was relying on manual input by the rep or going into the **[22:04]** finance system and see when billing stopped which that's not going to cut it **[22:08]** when you need to understand your net revenue retention very very quickly and **[22:13]** have an answer off the cuff ready to go so that was a another kind of portion of **[22:18]** this is how do we handle renewals and specific renewal motion so an early **[22:23]** renewal is another type of motion that they go through where it renews say two **[22:29]** months earlier so that two months what how are we measuring measuring the **[22:34]** difference so this is new paper new contract usually it's an upsell that's **[22:37]** happening in that early renewal period but there's that two-month overlap that **[22:42]** an old contract is ending and a new one is is beginning and we want to make sure **[22:47]** that we track revenue in that period correctly so one's turning off one's **[22:51]** turning on essentially and so those were all the scenarios that I started to show **[22:56]** them and then from there it showed it what I call the payload so when the rep **[23:01]** hits the apply button quotes on everything looks good they did the guided **[23:05]** selling what happens then so I show them how accurate numbers can be put in there **[23:11]** I showed them that instead of doing these co-termed expansion proration **[23:18]** calculations in a calculator nowhere in a spreadsheet it's all done in a **[23:22]** calculator it's done automatically you just plug the start date well sorry the **[23:26]** that you plug in the start date the end dates automatically grabbed now you have **[23:30]** the exact days of that co-termed expansion and you can do an exact **[23:34]** proration calculation based on that exact number of days so it gave them an **[23:40]** accurate number not something that they couldn't trust not something that was **[23:43]** rep rep manually inputted and again it's it's all just feeding better tracking of **[23:49]** revenue better commissions invoice schedules I also shared that as part of **[23:55]** this like MVP walkthrough of how an invoice schedule gets set up so I think **[24:01]** for you know a very basic example if you look at a 12-month deal they're paying **[24:06]** annually that's one invoice but now there's the question when does that **[24:11]** invoice go out does that go out on the contract start date does that go out 30 **[24:17]** days on like net 30 terms so all of that is designed into the guided selling to **[24:23]** determine what those what those terms are some of the more complex **[24:28]** organizations that I've worked with and lean scales worked with is when each **[24:33]** individual line and we can carry individual terms if the whole deal you **[24:37]** know 15 line items all carry the same terms it's a little bit easier but if **[24:41]** you have individual products with different configurations different **[24:44]** start and end dates or delivery dates that adds a whole another layer of **[24:47]** complexity to everything but for this particular case like showing them how **[24:53]** invoice schedule gets get set up how this could potentially feed the the **[24:59]** billing and subscription system making it really easy for invoices to get **[25:02]** established for a new account to get set up that was all done in two days and **[25:07]** shared via that MVP conversation just showing them how that that motion should **[25:11]** work and I think that's ultimately what like entice them to say let's go into **[25:16]** this more let's look at this if you can make it if you can do this in two days **[25:20]** what can you do in 30 days so the next 30 days was just hardening the code **[25:25]** making sure it was production ready we should talk about build or buy I think **[25:29]** that's something that most you know sass orgs are gonna start talking about is **[25:34]** with this like AI invincibility cloak that everyone has builder by I think is **[25:39]** gonna become a huge conversation for everybody should we build it or should **[25:42]** we buy it from a vendor or a partner or someone that's already doing this into **[25:46]** the industry for this particular case they landed on build because they knew **[25:52]** kind of where they were as an organization they knew that by being **[25:56]** able to control the user interface control the quoting scenarios put the **[26:04]** guardrails on that kept the data accurate that's where they needed to be **[26:09]** accurate data so that's that's how we got to that decision of let's go all in **[26:14]** on this and start building it out now so in the build conversation can you walk **[26:19]** through technically and mechanically how you built it what tools did you use what **[26:24]** context did you gather to feed the build how did you deploy how have you ### 26:27 — The four-step build and the 50–70 property payload **[26:30]** maintained since that or from MVP to production technically how did you make **[26:37]** the changes and adjustments how did you use AI to do it and then how are you **[26:43]** maintaining once it's been deployed I so I started with a simple diagram of what **[26:52]** the process should look like so I looked at it in four different steps and not **[26:58]** not the technical steps are like how the plumbing needs to work but here's what **[27:03]** it needs to do for the front end user so the first is the scenario selection what **[27:08]** am I selling right now what motion am I going through and that almost sets the **[27:12]** rest of the CPQ up for what it's going to offload onto the deal onto the line **[27:19]** items what it's going to set up from a from a revenue standpoint all the 50 to **[27:25]** 100 properties that are updated after the quote is built I started there that **[27:32]** the selection of a scenario or a selling motion is is kind of position one and a **[27:39]** lot of CPQ platforms they'll call them workflows so we're selecting a workflow **[27:42]** that we're going to launch that might be a renewal workflow enterprise workflow **[27:48]** but for this for this particular purpose we call them quoting scenarios so starts **[27:53]** with the quoting scenarios then it goes to the products so selecting the **[27:57]** products selecting the add-ons the services the quantities the discounts the **[28:02]** number of seats basic kind of like minor product and pricing configuration and **[28:08]** then right there on that page you're gonna have a summary of the breakdown **[28:13]** based on the schedule the billing schedule and you're gonna have AR which **[28:17]** is something they didn't have visibility into before so they're gonna see total **[28:21]** contract value this is what everything costs end-to-end across two years three **[28:26]** years whatever that term is you're gonna have the ARR breakdown the MRR **[28:30]** breakdown and then you're also gonna have you know discount breakdowns for **[28:34]** co-term expansion you're gonna see the peration discount amount but ARR is **[28:40]** gonna be accurate in that case which they didn't have before so products **[28:44]** pricing slight configuration is the next the third steps I would say is more of **[28:49]** the guided selling slash like commercial terms set up how are we gonna bill for **[28:54]** this quarterly monthly semi-annually all up front is it net 30 terms one thing **[29:01]** that we added after that we fell found was very helpful and it got added in 15 **[29:05]** minutes was the ability to change a billing contact so by default it selects **[29:10]** the signer and or the billing contact role but if you want to adjust that if **[29:17]** say you know someone else we need to send this to AP at or accounting at they **[29:21]** can do that in that step or they can come back to it later and change it if **[29:25]** they want to as well but the the commercial term set up is the third step **[29:31]** and I would say it's the most important in terms of the payload that comes out **[29:34]** of it the last step oh here's actually another part another nuance to all of it **[29:39]** is that certain quoting scenarios will have certain commercial term setups so **[29:45]** you're you're gonna be setting these up in the parameters that we allow so for a **[29:50]** 12 month deal sorry for a 36 month deal we don't want to allow monthly billing **[29:56]** for that we want that to be billed annually or all up front so we remove **[30:00]** that we remove that option from the reps view so now you don't get in the mess of **[30:05]** like okay they billed it for 36 months either we have to go back to them and **[30:10]** say we can't do monthly or it's just not an option for them to do that so that **[30:14]** was all cleaned up put in those guardrails so after you get through those **[30:18]** three steps you go into just the quick review you want to see that the numbers **[30:24]** all match up you want to make sure that it's a very you know clean process it's **[30:29]** all nothing is edited on this final screen it's just the final review step **[30:33]** before you get to actually generating the document or before you create the **[30:37]** line items update the line items update the deal data any of that but the very **[30:43]** bottom was in something new that we also added which was a almost like a selling **[30:48]** mechanism where reps were allowed to do a one-time discount really quick example **[30:54]** if you've ever been in sales you get to the end of the year you want to try to **[30:59]** get people on the phone you want to close out your you're strong so your **[31:02]** cons you're going to leadership and you're asking for hey can we do an end **[31:05]** of the year discount of some sort or an end of the year push that we can get **[31:10]** some more people through the door I have you know pipeline X and I really want to **[31:13]** get them sold or even at the beginning of the year when budgets get released **[31:17]** and people start to look at what they you want to do for the upcoming year **[31:22]** that's also another really good time depending on the industry and they may **[31:26]** have different planning periods you may see like July fiscal years are when most **[31:30]** people start to get their budgets and numbers and start to plan out for the **[31:35]** upcoming year so you have to plan around that but their their idea was like a **[31:40]** hundred percent like we should be doing this type of stuff all the time but it **[31:44]** should be controlled so you can't just go in there and put a hundred percent **[31:47]** discount it was controlled based on the value from those three previous steps so **[31:53]** that that is something that gets put in at the end it's a you know a line item **[31:57]** in there in their case when it comes to CPQ and the billing system but it's just **[32:02]** a really just nice touch and again 15-20 minutes to get that introduced and **[32:07]** built into the CPQ so definitely gold in hey let's set up all the rules all of **[32:15]** the decisions the blueprint of everything then did you take that did you **[32:20]** put it into cloud code and then ask it to build a HubSpot extension how did you **[32:25]** take the hey I have everything I want it to be in every scenario and then ### 32:26 — Building it with Claude Code as a HubSpot extension UI **[32:30]** actually turn it into something that somebody's going into HubSpot and **[32:34]** putting a quote into it was first to actually cross-check if HubSpot native **[32:42]** quoting was a viable option so it was almost like a blueprint of what good **[32:47]** looks like and then I brought that into Claude to compare to their existing **[32:52]** environment and just HubSpot native quoting in general is can we get it to **[32:58]** this point and I kind of knew the answer already to that I knew that it was going **[33:02]** to be no and the the the biggest dent on arrival point was the lack of guardrails **[33:08]** that you can put on the the sellers so I knew that was probably going to be a no **[33:14]** option and then I built a couple other extension UIs out I knew it was a really **[33:19]** nice way to build custom cards within a HubSpot environment and I decided to **[33:24]** roll the dice and say let's actually see if we can do this tick so they can see **[33:27]** that comparison between native quoting and what this MVP is gonna look like I **[33:33]** wasn't gonna spend like a ton of time on it I was just gonna stand something **[33:36]** quick Claude enables you to do that really really fast but it took my brain **[33:40]** dump and the blueprint that I created and it almost like to a T created it **[33:46]** perfectly the four steps the one part that needed tweaking was the updating of **[33:51]** the deal itself and the creation of the line items that you know I think the **[33:55]** initial one was a like a ten field payload and it grew to 50 and then 60 70 **[34:01]** it kept growing because of what they wanted to report on but that's how it **[34:05]** ultimately got to that first point of getting it in front of them was it was **[34:10]** showing that you know this is why a HubSpot isn't gonna be suitable for you **[34:16]** and then it turned into let's build this which was for me I was excited **[34:21]** something that you actually taught me too it was is you know build or buy you **[34:26]** know is it gonna be production ready our 20 30 40 50 reps going to be able to use **[34:32]** this thing without fall and I think because the way extension UIs are built **[34:36]** they're built in react they're built into the HubSpot environment and we're **[34:41]** only interacting with HubSpot at that point hundred percent like it's gonna **[34:44]** it's gonna move quickly I battle tested it too before that first MVP demo yeah **[34:50]** and maybe it's just maybe that's good to know like the difference between okay **[34:54]** once you do the MVP they fell in love they're like okay this is great and **[34:57]** you're able to take the blueprint put it in quad code push it to HubSpot now **[35:02]** they're in HubSpot looking at it and they're like oh why don't we just do **[35:04]** this what did you have to do to say okay fun MVP but now we need to make some ### 35:05 — From MVP to production-grade: hardening and battle testing **[35:12]** changes to make it production grade anything that stands out as you were **[35:16]** testing it that you needed to make adjustments to or is it just tweaking **[35:20]** and fine-tuning yeah we haven't talked about the the tools in the the quote to **[35:25]** cash space I know we're kind of heavily focused on CPQ right now but I was **[35:30]** actually trying to recommend subscribe based on PLG sales led motion I was **[35:36]** really trying to this is beginning of the year trying to really get them to **[35:41]** look at subscribe I think there were some existing relationships there that **[35:45]** they thought like oh yeah it sounds like a great system but they just got **[35:50]** acquired so you know it's it's always a little shaky a little scary to be going **[35:56]** in as they're getting acquired you have no idea what the acquiring company is **[36:00]** going to do with this piece of software is it gonna just go away completely are **[36:04]** you gonna onboard and then have to re-onboard in a couple months so I was **[36:08]** actually really pushing for subscribe and a lot of like the kind of the **[36:12]** blueprinting was built with on my experience using subscribe and how they **[36:17]** go about CPQ guided selling user experience all of that so that's that **[36:22]** sunk that plan and then they looked at a couple other ones but the the MVP when **[36:29]** we said hey we're gonna go this route I actually got really excited because it's **[36:33]** now this you know domain of expertise and the you know level in which like AI **[36:39]** really really accelerates your ability to fine-tune build create launch deploy **[36:45]** support it really got me excited about it and not to say like oh we're never **[36:51]** gonna go with deal hub or subscribe again I think there is absolutely cases **[36:55]** in which you are 100% going to do that I think for an organization that is very **[37:01]** AI heavy very AI focus very agent savvy this is a great option because you can **[37:06]** continue to evolve it support it make simple changes I think every change that **[37:11]** we made post-launch took about 15 minutes and it was live tested in **[37:16]** production good to go reps are ready so that that got me really excited about **[37:22]** doing it the only thing that I was a little bit nervous about is is the the **[37:27]** battle-tested portion of it can 50 people beyond this and it's not going to **[37:31]** break and that's where I brought the engineering cloud of lean scale and to **[37:35]** really look at it and give me the honest answer and they're like well no like the **[37:39]** way that the code works on the back end it's gonna be very stable because you're **[37:44]** not having all these different instance they're not all logging into the same **[37:47]** instance everything is individual to the deal itself hmm walk me through maybe on **[37:53]** the build versus by scenario I mean this sounds super robust it sounds like it's **[37:58]** scalable you're not gonna run into any issues it's on hub spots you have all **[38:02]** the permissioning and everything that you'd expect when when does it make sense ### 38:06 — Build vs. buy: when custom isn't enough **[38:08]** to say hey this isn't going to be enough for what this company's quote to cash **[38:13]** process is and we do need to go with something like a deal hub or subscribe **[38:18]** or new or whoever name your solution of the of the week what are those nuances **[38:26]** or thresholds or specific things to that company that would say hey this isn't **[38:30]** gonna cut it I need to go look for a vendor the billing software billing and **[38:35]** subscription software is going to dictate a lot of that depending on how **[38:39]** depending on which one they have depending on like which billing and **[38:43]** exactly exactly so if you're on stripe you need the CPQ and the CRM to work a **[38:50]** certain way if you're on you know anything else if you're on maxio if **[38:57]** you're on pandadoc payments there's a lot of bill it real it's honestly one of **[39:01]** my favorite if I can you know give a tool shout out real it has been one **[39:04]** that's been on my mind a lot but they took the they took billing and made it **[39:09]** really simple they don't require a whole lot from the CRM it's actually **[39:14]** probably the smallest data mapping that we've done I mean for from a revenue **[39:22]** perspective or from an invoicing setup perspective but I think that is gonna **[39:27]** dictate a lot of which direction you go when it comes to a CPQ native something **[39:34]** that that if you don't if you want a standalone solution you don't want it **[39:37]** native in the CRM that is another potential you want to be fully **[39:41]** integrated Salesforce and HubSpot are pretty well integrated across the CPQ **[39:48]** ecosystem right now but that's another thing to keep an eye out and then **[39:51]** specifically for build versus buy do we have the team to support it long term do **[39:58]** we have someone that can understand if there's if an issue pops up I'll give **[40:03]** you a really good example HubSpot just went through their legacy app platform **[40:08]** upgrade so they gave everybody four weeks and or sorry four months when we **[40:14]** first became about the update that everyone is going to have to move to **[40:18]** the platform upgrade that they're doing I believe end of August now is when it's **[40:23]** going live one of the biggest components of that and this might scare people away **[40:27]** from the build side of it is they were going to be going away with the **[40:31]** serverless serverless functionality which being a react application in **[40:37]** HubSpot that serverless functionality was was crucial so they were gonna be no **[40:43]** apps were gonna be allowed to use that and that was a you know an aha moment **[40:49]** for me of like okay I need to make sure they're prepared to actually be able to **[40:52]** support these types of changes that might come up and I decided with them I **[40:59]** decided I want to see if this actually goes through so anytime that HubSpot **[41:03]** puts out a controversial update I always look at the forums I want to know **[41:08]** exactly what the what the customers are saying and people were grabbing their **[41:13]** pitchforks and you know lighting the fires and running down the door but I **[41:17]** had a feeling that they were gonna make a shift and they even in their their own **[41:21]** announcements we're starting to say like hey we're gonna look at potentially **[41:25]** reintroducing this and a later update so two months later they came out and they **[41:31]** said okay now with the new update there is gonna be serverless functionality and **[41:34]** you can import you know update it and move everything over this way that update **[41:39]** took 30 minutes I think to get it done get everything moved over to that new **[41:44]** environment but for an organization like you need someone that can support that **[41:49]** that understands that they can keep their eye out and really can jump on it **[41:53]** really quickly because that's an update we had four months to prepare for but **[41:57]** there's other ones that are going to come an API update for example that you **[42:01]** don't get to prepare for it just hits you middle of the night and you have to **[42:05]** jump on it as quick as you can so that makes sense where you don't want to have **[42:11]** all your eggs in one basket if you will and then the billing integration so it **[42:17]** sounds like if you're on real it you could probably take a custom built **[42:21]** pretty far is there anything around the process or blueprint of how outside of ### 42:27 — The maintenance tax: the HubSpot serverless scare **[42:30]** maybe the tech stack but just are there any complexities of pricing and **[42:34]** packaging that would make you think a company should go towards a vendor **[42:40]** solution versus building their own or does it all have to do with the **[42:43]** surrounding ecosystem like can you take a custom-built app to 500 reps a thousand **[42:49]** reps you could you could but I would lean on the enterprise-grade softwares **[42:56]** in those in those cases because you want somebody that is going to introduce **[43:01]** innovation to it one deal hubs probably my my top rated CPQ out there for if **[43:08]** you're going with a standalone option they have something called a deal room **[43:12]** and a deal room is a great way for you to interact especially across enterprise **[43:15]** deals where you have lots of documents going back and forth lots of people **[43:20]** multi-threaded into that particular sales process I would say in those cases **[43:25]** like the more complex the products the more people you have or if you don't **[43:32]** want to manage a lot you go with an option like that if you have some some **[43:36]** simplicity from a from a product standpoint every single product is going **[43:39]** to have very complex billing configurations but from a you know packaging standpoint **[43:46]** from how products pair together the dependencies like that I would say if **[43:52]** it's simple or like a medium level then a hundred percent you can get through **[43:56]** with a with a you know custom-built option in Salesforce or in HubSpot the **[44:02]** the high high volume fast-paced SMB they need to get it out quickly those **[44:09]** enterprise systems are gonna slow you down a little bit because they're all **[44:11]** working through API's typically the the guided selling gets just overly built **[44:17]** and you just want something that's fast that's accurate fast and reliable and **[44:21]** custom options probably going to be really good in that case yeah I'm **[44:28]** thinking it's like there's two forces here one AI capabilities are going to **[44:33]** continue to grow and then I think the CRM infrastructure is like Salesforce **[44:37]** going headless I'm sure HubSpot will be forced to go that way may open up more **[44:45]** capabilities and at the same time you're right these enterprise grade platforms **[44:50]** are introducing innovation that's kind of outside of just the business logic so **[44:54]** but I do think it's a much more nuanced conversation than it ever used to be and **[45:00]** the other thing that is developing as well that I'd really like you to shed **[45:06]** some light on is the rest of the tool ecosystem outside of the CPQ so that CPQ **[45:11]** tends to be the brain of everything and pushing the information everywhere where **[45:15]** it needs to go but what other mission critical tools are there is it reasonable **[45:21]** to build custom solutions for some of these are there some where you have to **[45:26]** go with more of a vendor strategy and then what are your favorites so let's **[45:33]** start with the next step after you get the numbers and the the the numbers **[45:39]** generated in the CPQ which is how you surface a document and send it to the **[45:45]** prospect or customer in case of renewals and expansions so the first where I like **[45:50]** to start there is looking at the actual sales process the sales lifecycle every **[45:55]** company is a little bit different on what they surface and when some do **[45:59]** proposals very early on some do very just standard pricing tables very early **[46:04]** on the I like to look very heavily at the contracting period what does that **[46:09]** look like is their procurement do you allow red lines do you have you know **[46:15]** really robust MSAs or you know legal requirements that you would want to **[46:19]** bring on a professional grade contract lifecycle management system like an iron **[46:24]** cloud which I really really like ironclad just for how they handle documents and **[46:29]** really robust lifecycle across the contract but I want to dig into all of **[46:35]** that and I want to look at all the contracts over the last you know 12 **[46:39]** months I want to look at how they've changed over the last six months and how **[46:42]** that relates to the last three months so we go into every single contract to see **[46:46]** how they're being structured how they differ across reps what should be **[46:50]** locked down what shouldn't be locked down what requires an approval before you **[46:54]** even gets to that point of sharing a document so we I really like to look at **[46:59]** the lifecycle and where documents first appear and then from there there's more **[47:05]** there's more setup I would say I a lot of customers describe that as probably **[47:10]** one of the biggest pain points in quote to cash is just the level of like **[47:15]** customization setup that you have to do to set up a ironclad or a panda doc or a **[47:20]** doc you sign it's also something to be aware of too is when you're making **[47:25]** changes to the CPQ and those changes are going to impact the you know the way **[47:31]** that the contracts are built or handled that's gonna be really important that **[47:34]** you have someone that that knows that and owns it and can make sure that those **[47:38]** processes are keeping up with one another once you have that all mapped out **[47:42]** you know all the agreements that need to go out you know all the approval **[47:45]** processes the type of documents that need to be handled maybe have different **[47:49]** tiers of service level agreements that need to be attached to these documents **[47:52]** that's where you then get to do the fun part which is building it out and you **[47:58]** know building out the template the creative side usually falls on like the **[48:01]** marketing brand or creative folks I've gotten to do a couple of them I I **[48:06]** wouldn't say I'm a creative but I really enjoy that stuff I enjoy making things **[48:10]** look really good and when they don't have the time or resources I'll go in **[48:14]** there and do it and present it and kind of similar to like the MVP option like **[48:18]** great let's use that so it's like we just save them some time and it's a **[48:22]** document that thousands of businesses are gonna see it's it's fun to be a part **[48:27]** of that and I've always really just I've enjoyed that part of it but yeah the **[48:34]** the the contract and the document handling is really really important but **[48:39]** the the North Star for it is I want to see the CRM data the contract data lock **[48:44]** step like those are fully working operational they're consistent they're **[48:50]** accurate we can reconcile those against each other that's the North Star of that **[48:54]** whole process is that those are perfectly aligned the other part too is **[49:00]** the lifecycle stage like automation how do we automate the lifecycle so reps **[49:08]** don't have to manually move a stage can we move it from say you know stage three **[49:13]** which might be like technical evaluation or it might be a POC can we move it to a **[49:19]** you know negotiation or proposal set or proposal negotiation step based on that **[49:25]** document going out once it gets closed one or sorry once it gets signed what **[49:31]** happens after that are we immediately moving it to closed one and having **[49:34]** finance come in is there a deal desk step or deal desk team that's in the **[49:38]** middle of all that that is going to you know check everything once over and make **[49:42]** a good I feel like if you do your if we if the setup is done correctly and **[49:47]** you've covered every angle and you've looked at looked into the future you **[49:51]** should have a lot of confidence in that that contract lifecycle automating those **[49:56]** stages across the board so that that's the contract lifecycle part do you want **[50:03]** to dig into anything else on that side no I think I think a lot of people don't **[50:09]** think about that part but like getting everything approved getting a document **[50:14]** out the door getting it signed getting that signature on it and then once it is **[50:19]** then pushing that to invoicing and billing and I think that's a big a big **[50:27]** part where people miss or it's very manual so maybe as we wrap up the full ### 50:28 — The last mile: invoicing, billing, and reconciliation **[50:34]** quote to cash process what does that last mile look like when you're actually **[50:38]** getting in an invoice prep sent on the right time and and getting billed and **[50:44]** collecting collecting revenue yeah it starts with a conversation with the the **[50:51]** tools technical team or support team so you can understand top to bottom the the **[50:59]** data mapping between the two systems these are all the types of ways that we **[51:04]** sell these are all the types of ways that we bill what data do you need in **[51:09]** order to have a successful billing system and in order for invoices to get **[51:14]** set up correctly that you know one time end of the year discount how does that **[51:19]** need to be passed over to your system what objects can you pull from I have a **[51:24]** horror story from one of our customers of trying to adapt a CRM and a CPQ to a **[51:31]** billing system which I would I would never recommend because it creates a lot **[51:37]** of complexity in the system that is unnecessary so be aware of that be aware **[51:42]** of adapting custom objects to a billing system just because that's what they **[51:48]** need always look for solutions outside of that but the data mapping exercise is **[51:53]** the most important then once you understand that then you start to layer **[51:57]** that into the CPQ into the contracts into everything that is eventually going **[52:02]** to feed this billing and subscription system I think the something that's like **[52:08]** a underrated part of quote to cash is just reconciliation and alerting and **[52:15]** monitoring that's not something that I would recommend doing on a quarterly **[52:20]** basis if you can automate like alerts of things that you expect to come up and **[52:24]** there's a lot that could potentially come up you want to make sure that you **[52:29]** surface those things immediately so to give you an example not you know calling **[52:35]** out anybody specifically but if a deal gets climate use that actually most **[52:40]** basic example to explain the point but if a deal gets closed one and you know **[52:45]** exactly how much that invoice schedule looks like let's just you know make it **[52:49]** easy it's $100,000 and you have the billing system tied back to the company **[52:55]** or the account record in your CRM you should be able to reconcile that very **[52:59]** easy but if you see that that number on the company account side is staying at **[53:03]** zero you want to be alerted to that immediately if you see that it goes five **[53:07]** days past the day that it should have been billed that's almost five days two **[53:12]** lakes and you have this awkward conversation with the customer sending **[53:15]** them an invoice they were expecting probably weeks ago so setting up the the very **[53:20]** granular alerts of issues that may pop up is really really important and when **[53:26]** you get to the billing in the subscription side I would also look at **[53:31]** the sink to make sure your data map is correct I actually just had an example **[53:36]** last night when I was working of a stripe sink to HubSpot that was **[53:42]** overriding the contact first name and last name with the business name because **[53:46]** of how stripe is set up as a billing system so stripe as a billing system **[53:51]** they're typically used to subscription which is a typically a person the the **[53:57]** billing account which is typically an email and they interpreted that when **[54:02]** they set up the sink as like oh name that's the business name but it's like **[54:06]** no no no they're solving for the PLG side right they're not the B2B side and **[54:10]** B2B like your company name is you know what you're going for but that's not **[54:15]** going to be surfaced and in the way that the sink to HubSpot works with stripe so **[54:20]** just little like things that you you look out for that it seems great right **[54:23]** stripe is well connected with Salesforce with HubSpot you know let's get **[54:28]** this thing set up and start pushing invoices transaction and account records **[54:32]** but it doesn't miss necessarily mean that the system is set up correctly to be **[54:39]** able to handle B2B be able to separate out product lead versus sales lead yeah **[54:47]** and I think a lot of things people don't recognize when they're talking about **[54:52]** these systems in this process is that if you don't have this streamlined then you **[54:59]** have a really really tough time getting getting revenue in the door and it could **[55:06]** compromise certain deals so this is not like oh these are nice to have **[55:11]** automation so that way we can not have to do as much work this is oh if we don't ### 55:13 — Why this isn't nice-to-have — it puts deals and reputation at risk **[55:18]** do this it could put deals at risk if billing looks funky it could put our **[55:21]** reputation at risk it doesn't look good to a customer if you send a bill with the **[55:25]** wrong name or don't bill them and try to build them later it just looks like you **[55:28]** don't have your house in order and that's a reflection whatever product and **[55:31]** service you're offering too and then same with the the reps in the field that **[55:36]** you've put quotas on if they're running through mud to get quotes out the door **[55:42]** deals out the door decisions on whether they can quote something or discount **[55:47]** something you want to be able to empower them as much as you can and the more you **[55:50]** can it has a massive impact on conversion rate sales cycle shared number **[55:58]** of closed one deals and then of course downstream effects of cash position and **[56:03]** collections and everything as well so I think when people are thinking about **[56:07]** this process sometimes it's seen as oh these are some nice to have automations **[56:10]** they have real business impact they do they do and to your point it's as much **[56:18]** about having a great tool that can support your team and reduce friction as **[56:22]** it is about reliability and trust in the data and I would say that last part that **[56:28]** the trust and reliability of the data is where a lot of teams setting up quote to **[56:33]** cash CPQ they don't go to that level of detail and that's a big miss because if **[56:39]** you're not thinking about that part of it how the data is going to be impacted **[56:44]** across the systems and it's not just the one deal it's future deals it's future **[56:49]** expansions it's future churn auto renewals it's future you know early **[56:55]** renewals or upgrades upsells like all of that is coming off this one deal so **[57:00]** getting it right is really really important but that's that's where I **[57:04]** think it falls short they start with the best intentions of hey we want to get **[57:08]** them a really cool tool it's going to speed them up it's going to eliminate **[57:10]** some friction but where it gets where you fall short is when you don't look at **[57:16]** that that next thing that data the data the trust that you want to have in the **[57:20]** data and just the reliability overall of the system to fit within your go-to **[57:24]** market and that's where I wanted to spend the most time when it comes to **[57:30]** quote to cash because it touches so many things you have to go into that level of **[57:35]** detail with every part of it it can't just be the CPQ you have to look at the **[57:41]** document handling you have to look at the billing and subscription potentially **[57:46]** you have to look at the accounting system forecasting commissions being **[57:51]** able to track that accurately and reliably and so everybody has trust in **[57:55]** the numbers that are that are feeding the machine that's where I wanted to be **[57:59]** really good in an expert and that's where I spend most of my time because **[58:03]** I'm confident in my you know non-designed background design **[58:07]** capabilities to build something that is seamless and user-friendly I focus **[58:12]** heavily on the everything that happens after which is let's build trust let's **[58:16]** build confidence in this system and I think naturally with that you know the the **[58:21]** reduction of friction the increase of speed velocity all that just starts to **[58:26]** fall in line with it well Derek this has been a master class on quote to cash and **[58:33]** specifically on CPQ I'm so impressed I know the customer that you worked with **[58:39]** is very impressed as well that we've been able to build a custom CPQ **[58:43]** solution built off of deep discovery deep understanding of the business **[58:48]** process leveraging cloud code to deploy to HubSpot so you can use it in CRM and **[58:54]** something that's actually production grade and scalable so I appreciate you **[58:59]** sharing everything you did it's so much fun to do it with somebody on the team **[59:03]** who's out in the field building real things every single day and I can't wait **[59:09]** for the next one and you mentioned earlier in the conversation quote to **[59:13]** cash is only evolving and changing every single day so we're gonna have to do a **[59:17]** refresh probably every three months or so of what the latest and greatest is **[59:20]** I'm on I'm in for that a hundred percent --- _LeanScale Knowledge Hub. Free to quote and cite with attribution to The LeanScale Podcast (https://www.leanscale.team)._