Hi! I’ve been learning HubSpot as I go for the past 2 years (it’s not my main job, but I’ve been dubbed the keeper). I recently razed and rebuilt the whole thing. Can someone please review it for best practice?!
For context, we’re a small professional services firm with five service lines under two divisions. Division A is consulting/services work (A1, A2, A3) and Division B is capital deployment (B1 is a lending product, B2 is acquisitions). The old setup had grown into a mess of one-off fixes, so my goal this time was one lead front door and as few deal pipelines as possible, with the service lines told apart by tag instead of by spinning up more pipelines. Two deal pipelines because the sales processes genuinely differ. We’re on Sales Hub Enterprise.
How it flows, contact to deal
1. Contact created. Someone fills in the contact card. Two fields do all the downstream work: Service Line (five values) and Lifecycle Stage. Company gets associated right at creation.
2. Lead auto-created. Setting Lifecycle Stage = Lead on a contact that has a Service Line automatically creates a Lead, associates it to the contact and company, and tags it by Service Line. Nobody makes leads by hand. All five service lines share one Lead pipeline, and the tag is what keeps them straight.
3. Estimated value auto-set. A workflow writes an Estimated Deal Value onto the Lead based on its Service Line, so everything hits the forecast immediately without anyone typing a number. It only writes if the field is empty, so it can’t stomp a real figure.
4. Task auto-created (stage: New). A Lead-based workflow (re-enrollment ON) enrolls leads where Lead Pipeline = Lead pipeline AND stage = New, then creates an Email-type task titled “Contact [First] [Last] ([Company]) re: [Lead tags]”, due 14 business days out at 8:00 AM. (Long due date is intentional, our sales cycles are slow.)
5. New > Attempting. A Task-based workflow (re-enrollment OFF) enrolls tasks where status = Completed AND the task is associated to Any Lead AND that Lead’s stage = New, then moves the lead to Attempting. So finishing the outreach task is what advances it.
6. Attempting > Connected. This one I left alone. I assumed HubSpot handles it natively when a contact replies, but I’m honestly not sure, which is my first question below.
7. Connected > Scheduled. A Contact-based workflow (re-enrollment OFF) triggers on “Meeting booked has been completed,” conditioned on the contact being associated to Any Lead whose stage = Connected and Lead Pipeline = Lead pipeline. Moves the lead to Scheduled. The intro call is our qualifying moment across every line, which is the only reason Scheduled exists as a stage at all.
8. Qualified > Deal created. Marking the lead Qualified prompts deal creation and routes it by Service Line into the Division A or Division B pipeline. The tag rides along onto the deal, so it still separates the lines inside each pipeline. Actual Deal Amount gets entered here; Estimated Deal Value stays behind on the lead and native Deal Amount becomes the real number.
9. Lifecycle progresses natively. Contact flips to Opportunity when the deal is created and Customer when it’s won. Both are just native toggles, no custom automation.
If a lead dies, it goes to Disqualified with a Disqualification Reason. At the deal level, each division has its own reason field.
Structure
Lead pipeline (single, all five lines): New > Attempting > Connected > Scheduled > Qualified, plus Disqualified.
Deal pipelines:
Division A: Discovery (20%) > Proposal sent (40%) > Verbal win (65%) > Closed won (100%) / Closed lost (0%)
Division B: Screen (15%) > Diligence (40%) > Term sheet / LOI (65%) > Committed (85%) > Closed (100%) / Passed (0%)
Key properties
Service Line is a custom dropdown on the Contact, set once and carried to Lead and Deal. Deal Tags are native HubSpot pipeline object tags, one per service line. Estimated Deal Value is a custom number on the Lead; Deal Amount is the native field on the Deal.
I ended up with three structured reason fields, one per level/division:
Disqualification Reason (native, Lead) serves both divisions using prefixes, where A = Division A, C = Division B, A/C = both: A - Bad Timing, A - Budget Constraints, A - No Decision-making Power, A - Competitor Preference, A - Not a Good Fit, A - No Interest, A - No Response, A - Prior Negative Experience, A - Technical Limitations, C - Not a fit for mandate, C - Declined by founder / timing, C - Commercial terms misalignment, C - Diligence breakdown, A/C - Other, A/C - Revisit / Watch, A/C - Refer
Division A Closed Lost Reason (custom, Deal): Price / fee too high, Timing deprioritized, Chose another provider, Scope mismatch, Went in-house, No decision / stalled, Budget cut / lost funding, Lost contact, Revisit, Refer, Other. Plus a free-text note field.
Division B Pass Reason (custom, Deal): Not a fit for mandate (size, industry, economics, founder profile, geography), Declined by founder / timing, Commercial terms misalignment, Diligence breakdown (financials, traction, margins, governance), Internal timing, Revisit, Refer, Other. Plus a free-text note. I also kept about 20 legacy screening reasons as hidden options so the old records still read correctly without cluttering the active picklist.
Ideas I haven’t built yet
A unified Contact/Company creation form, one lightweight form that makes both records at once so the company is populated with the baseline our reporting needs (domain, region, industry, revenue range) right at creation instead of getting backfilled later. This is my current answer to question 6 below: instead of syncing company values onto deal properties, just make sure the company record is complete from the start. Deliberately separate from our long diligence form, which is for enriching qualified opportunities, not creating records.
A contract handoff stage for Division A, a “Contract out” step between Verbal win and Closed won that auto-creates a task for whoever preps contracts, so signed work stops living in someone’s inbox. Useful or stage bloat?
The detailed intake form for Division B, which I want to enrich an existing Lead rather than create records, and only send once a Lead is Qualified. Still torn on whether earlier makes more sense.
Property cleanup. There are still several hundred legacy custom deal and company properties sitting at basically zero fill that need archiving.
Questions
- The Connected transition (step 6). I assumed HubSpot natively nudges a lead to Connected when a contact replies, so I never built a workflow. Is that actually native behavior on the Leads object? My Scheduled workflow requires Connected, so if nothing sets it, leads just stall at Attempting.
- Native vs custom stage movement. More broadly, am I reinventing things the Prospecting workspace already does with steps 4, 5, and 7?
- One property doing double duty. Service Line handles both pipeline routing and telling lines apart within a pipeline. Reasonable, or should those be separate properties?
- Reason field architecture. One prefixed field at the lead level but two separate division-specific fields at the deal level. Does that inconsistency hurt cross-division loss reporting, or is the per-pipeline specificity worth it?
- Hidden legacy options. I hid about 20 obsolete screening reasons instead of deleting them so historical records stay intact. Is that standard, or does it bite you later?
- Company-level reporting. My dashboards read mostly company properties through the deal’s associated company (region, industry, revenue range, that kind of thing). Should I instead create deal properties that sync from the company at deal creation so the values live on the deal itself? The tradeoff as I see it: syncing gives point-in-time snapshots and simpler deal-only reporting but duplicates data and drifts if the company record gets corrected later. Reading through the association keeps one source of truth but every report then depends on the association existing and the company being filled in. Which way do people go at scale, and is HubSpot’s association-based reporting good enough that syncing isn’t worth the trouble?
- Pipeline split. Two pipelines with tags separating the lines inside each, or should I split B2 (acquisitions) out of Division B given how different an acquisition is from B1 lending?
- Re-enrollment mix. ON for task creation, OFF for the two stage-movement workflows. Any gotchas with mixing those?
Thanks in advance, any and all feedback welcome!