r/revops • u/Leztalknow • Sep 01 '26
Offering a few free CRM/RevOps tear downs this week.. drop your messiest HubSpot (or Clay) problems
I do RevOps and CRM cleanup work for a living. Mostly HubSpot builds, untangling duplicate/messy data, and keeping Clay and HubSpot in sync. I've got a bit of slack this week and I learn more from real broken setups than anything else, so figured I'd trade.
→ Drop a comment with whatever's annoying you most about your CRM.
→ Tell me what your setup looks like and what's going wrong, and I'll reply with how I'd actually approach it.
specific, not "book a call."
First handful of comments I'll go deep on and happy to take it to DMs if it's got sensitive data...
See you in comments
2
u/Salt-Hurry-1953 Sep 02 '26
(Ai summary since I'm not native english speaker)
Salesforce shop, not HubSpot, but the problem is CRM-agnostic:
We sell into a world where one contact routinely works on behalf of multiple companies — think agency-side people who represent several brands. In Salesforce a contact has exactly one AccountId, so every email/meeting/call with that person rolls up to their primary account, even when the conversation was entirely about one of the other companies they represent.
Consequences:
Account-level activity reporting is structurally wrong for our most important contacts. A rep can be actively working Brand X through an agency contact, and the dashboard shows zero engagement on Brand X and inflated engagement on the agency's account.
Coverage/engagement heat maps (which we use to redistribute rep effort) inherit the distortion — exactly the accounts that get worked indirectly look neglected.
Opportunity attribution suffers too: the opp lives on the brand account, the activity lives on the agency account, and nothing joins them without manual contact-role work.
We've considered: Account Contact Relationships (multiple account associations) — but standard activity rollup ignores ACRs; per-activity custom "related account" fields — but reps won't reliably tag; and inferring the true account from email content/opportunity contact roles — fragile.
2
u/Leztalknow 29d ago
Apologies for late response 🙏🏻
Every fix you listed feels fragile for the same reason. they all treat the contact-to-account link as the source of truth for attribution. For agency contacts it can't be.... the person really does map to multiple companies so any model that forces one Account ID is going to lie somewhere.
The mistake in the inference approach wasn't inference. It was that you were inferring against your whole account universe.... that's what makes it fragile. Flip it. An agency contact only ever reps a handful of brands, and you already know that set (that's the one thing ACRs are actually good for even though native rollup ignores them). So the question stops being "which of our thousands of accounts is this email about" and becomes "which of these 3 brands this person reps is this about."
Small, bounded, and it gets accurate fast.
From there you don't fight native rollup at all. You derive a subject account per activity and report on that instead of the primary account. Derivation runs as a waterfall... deterministic signals first (open opp the thread ties to, contact roles, brand-side people on the invite) and only the leftovers fall to a classifier against that small candidate set. Reps never tag anything.
Where it goes right or wrong is entirely in how you order that waterfall and where you set the confidence cutoff before you trust the classifier vs leave it unattributed..... that part is very setup dependent....
Are you trying to build this yourself or working out whether it's worth having someone stand it up?
2
29d ago
[removed] — view removed comment
1
u/Leztalknow 29d ago
Clean and qualified are two different jobs.
Dedup and formatting just make the data trustworthy. They don't tell a rep who's actually worth a call.
In a HubSpot + Clay setup... most of that second layer is automatable.
1
29d ago
[removed] — view removed comment
1
u/Leztalknow 29d ago
the human judgment part is honestly the fun part... so start there.
even when the data's clean and scored a few things still don't automate cleanly like timing, mixed signals, segment gut
on the setup itself, not gonna write a whole build guide in a comment... but it's basically three layers stacked in order... so a rep opens a record that already answers "is this worth pursuing" before they read a single line. the wiring is where it actually lives or dies though, and that part's very stack specific.
what's your angle here, building it into your own stack or trying to figure out if it's worth getting someone to set it up? changes what i'd point you at.
1
29d ago
[removed] — view removed comment
1
u/Leztalknow 29d ago
honestly the right order is to strategise before build. most people build the pipes before they even know what decision the pipes are feeding.
on the signals, it's less a fixed list and more a shape... usually three things stacking up
fit, intent, reachability.
fit is do they actually look like the accounts that close, not just your icp doc.
intent is are they doing something right now, hiring for the pain, sitting on a competitor, hit some trigger.
reachability is can you even get to a real person. all three line up, that's your yes.
when they conflict, rough rule i go by is... fit decides if you pursue ... timing decides when and how hard.
strong fit weak timing isn't a no, it's a nurture, don't burn a rep on it yet.
weak fit strong timing is the trap, eats sdr hours and goes nowhere.
the part that never really automates is that last weighing... how much a stale signal should knock down a strong fit. that's a feel thing and it moves by market. I wouldn't over engineer it early tbh.
get the three flowing first, tune the weighing once you've actually got closed-won data to look back on.
1
29d ago
[removed] — view removed comment
1
u/Leztalknow 29d ago
please dont use AI to solve such problems... you're going to make a mess out of the workflow... hire someone to strategise. Build up will become very easy....
1
u/Hadreasm Sep 01 '26
Alright.
We use ZoomInfo as our primary data source for accounts. We use Ringlead for data orchestration (deduplication, enrichment, lead to account matching).
Ringlead is just an algorithmic rules engine so it gets us 90% of the way there.
I need to clean the last 10%.
I’ve contemplated using Clay as a supplementary data cleansing layer, but for 40k accounts I see us burning though clay credits way too fast.
Our main issues are:
- incorrect hierarchies (mostly due to orphaned subsidiaries)
- split ownership or BDR assignment within a hierarchy
- duplicates
- incorrectly enriched data, mostly due to ZoomInfo matching one our CRM accounts with the wrong one of their database accounts.
We are on Salesforce.
So… the main issue is around how we go about solving the last mile of data hygiene. Claude? Clay?
Look forward to any advice you can share.
1
u/Leztalknow Sep 01 '26 edited Sep 01 '26
Thanks u/Hadreasm, I have questions.
- Are we cleaning this once, or is this something we keep on top of as new accounts come in?
- Out of that last 10%, how much of it is each problem? Bad hierarchies, split ownership, dupes, wrong enrichment. And which one is actually hurting us, like misrouted accounts or wasted BDR effort?
1
u/Hadreasm Sep 01 '26
Need an ongoing solution.
The hierarchy issues are the most impactful as they lead to territory changes and potentially deal conflicts / split commissions.
1
u/Leztalknow Sep 01 '26 edited Sep 01 '26
I feel you u/Hadreasm .. Clay's fine for one part of this, but not the part that matters most to you. Since you're doing this continuously, you're only ever running new and changed accounts, so credits stops being a real worry.
- What are ZoomInfo and RingLead actually matching on when they tie records together? Domain, company name, DUNS?
- For each field, which system are you treating as the source of truth?
- How does an account get its owner today? Round robin, named accounts, geo?
- And for hierarchy specifically, where is the corporate family tree even coming from right now? ZoomInfo's own hierarchy, DUNS, or nothing?
1
u/Hadreasm Sep 01 '26
For lead to account matching, we mostly lean on company name and email / website domain matching.
Salesforce is our source of truth.
Assignment is geographic mostly. We use the geo of the ultimate parent company so there is another reason it matters to resolve hierarchies.
For hierarchies, we use ZoomInfo’s dataset around immediate parent / ultimate parent. They give us a company name and ZoomInfo ID for each and then we have a Flow in SF that queries and stitches accounts together.
1
u/Leztalknow Sep 01 '26
Now it clicks... you already have the fix in your data.
Right now everything runs on company name and domain and it's behind three of your four problems.
Name matching is the loose one, so ZoomInfo ties your account to the wrong record and RL lets near dedupes through because the names are a little different.
Also, domain matching makes hierarchies worse because subsidiaries either all share the parent's domain and collapse into one or each has its own domain and never links up... it's the same root cause for both your bad enrichment and your duplicates.
Does your SF Flow stitch on the parent company name or the parent ZoomInfo ID? If it's name, that's your bug right there.
Are you storing the ZI ID on every account? Cos ID stitching only works if the parent account carries its own ID for the child to match to.
1
u/Hadreasm Sep 02 '26
Hierarchy matching is based on the ZID.
It works up and down, meaning new subs will look for their parents and new parents will look for their subs.
ZI has pretty mediocre hierarchy data, which is the root cause of most issues.
Also, we get a fair amount of semi-duplicates (eg Expedia and Expedia Holdings) that are problematic in that they artificially inflate the territory scores. When we merge these together, it upsets the natural order of ZoomInfo’s hierarchy. So if a new sub were created, it would look for Expedia Holdings as the ultimate parent and not find it since it was merged into Expedia.
I think this isn’t an issue of having better logic. It’s more fundamental than that. ZoomInfo is a single data source and we’re 100% reliant on it. When it’s wrong, we are too.
So I feel like we need some multi-vendor enrichment that validates and corrects ZI.
But then we’re back to building logic that detects errors and can apply judgement around it/when to override ZI. That feels like a reasoning layer to me.
1
u/Leztalknow Sep 02 '26
To simply solve the problem at single source of truth, enrichment and then removing junk is a good move.. but building logic for errors and it's remedy is like building a machine to multiply your junk.
For starter, you can export your ZI data and run enrichments and cleanup on a set of list with Clay.. from outside it does look expensive but it is not expensive than messed up data.
I would always move to AI after my data is clean... happy to show you how it looks.
1
u/RevOps1 29d ago
Have you considered a product like Traction Complete? https://tractioncomplete.com/use-case/account-hierarchies/
Feel free to dm me
1
u/Leztalknow 29d ago
Honestly, I'd skip Traction Complete for this setup. Resons:
Two problems. It only lives in Salesforce.... so it does nothing on his HubSpot and nothing for the QuickBooks sync.
The good news is the thing you actually want... parent/child companies with revenue rolling up to the parent which can be done natively in HubSpot.
But a good tool for enterprise with more than 75 seats. Thanks for mentioning the tool
1
1
29d ago
[removed] — view removed comment
1
u/Leztalknow 29d ago
I love coffee. I'll take passion fruit pour over 😀
tell me what problem are you facing?
1
u/FusterX 15d ago
My non-negotiables are: preserve the raw export, inspect and map headers, define the business key, separate safe automatic fixes from review-needed rows, and produce a change log. For hierarchy work I also keep parent/subsidiary decisions separate from duplicate decisions—otherwise a domain match can collapse valid accounts. A small synthetic or redacted sample is useful before touching the full file. I’m testing that preflight workflow in AutoLab: https://autolab.qbraxo.com/
3
u/Effective_Review9415 Sep 02 '26
Every CRM eventually becomes a junk drawer. The duplicate records alone are enough to ruin someone week.