Debating Strategies for Handling Re-MQLs in RevOps | RevGenius

Join the Community

Debating Strategies for Handling Re-MQLs in RevOps | RevGenius

danita f.
·
·
Anastasiya S. if Contact already existed and reached Status = MQL, then we created new Lead record with Status = MQL and assigned to BDR for follow up. We made sure that the linked Contact data was shown on the Lead for ease of use. This enabled consistent reporting of MQL follow-up/SLAs, and conversion rates from MQLs thru funnel to meetings and opportunities. When Lead was converted to new opportunity, then Lead was merged back into existing Contact. Can provide more details if you're interested.
smitha k.
·
·
Hey Anastasiya, I can totally relate to the challenge you're facing with re-MQLs—it’s such a nuanced issue, and I’ve heard this same concern from so many RevOps leaders we've spoken to. We’ve had discussions with over 80+ leaders, and many have raised data duplication as one of their biggest pain points. It’s a real issue, especially when trying to balance a clean handoff to SDRs and keeping data accurate in Salesforce. In our conversations, a common approach is to create a new Lead for each re-MQL. While this does introduce the potential for duplicate records, many teams find that it makes their workflow with SDRs a lot smoother and the attribution much cleaner. Of course, automating the deduplication process is essential to prevent it from getting out of hand. On the flip side, updating the existing Contact does reduce duplication, but it often complicates trigger logic and reporting, especially when the Contact is AE-owned post-opportunity. So, I understand the dilemma you’re facing—each choice has its trade-offs. Here’s where we’ve seen teams succeed: automating these workflows with automated lead routing, engagement scoring, and dynamic follow-ups can streamline the process and reduce manual effort. It’s not a one-size-fits-all, but introducing automation can certainly help keep things running smoothly without all the headaches of data discrepancies. At DataviCloud, we’re laser-focused on data health and improving data quality across the lead-to-deal journey. We offer solutions that support data integrity while also helping teams manage lead-to-deal timelines, engagement quality, and pipeline forecasting—all of which can help keep your data clean and actionable without the burden of duplication issues. If you’d like to dive deeper into how this can fit into your workflow, I'd be happy to discuss it further. Let me know what you think! Best regards, Smitha.
🤔1
Anastasiya S.
·
·
Thank you so much for your reply! We explored replicating the SDR handoff process on Contacts too, but we’re leaning toward creating a new Lead each time someone re-MQLs, mainly because:
Ownership gets messy on Contacts — once there’s an Opp, the Contact is usually owned by the AE, and routing it back to SDRs for re-engagement can get complicated.
Outreach.io is lead-centric by default — triggers and sequences on Contacts tend to be fragile, while Leads just work out of the box. Curious — what outreach tool are you using?
Comp gets tricky — SDRs may miss SQL credit unless they manually link Opps to Contacts and link it correctly. With Leads, attribution happens automatically when they convert.
We’re using RingLead to dedupe and match records, and we track fields like Re-MQL Reason and Original Contact ID to keep reporting and attribution clean. Totally agree — avoiding duplicates is ideal if you can make the full Contact-based workflow work well. Out of curiosity, what’s your tool stack? And what kind of lead volume are you handling on a quarterly basis?
Ben A.
·
·
I encountered something very similar to this recently. What I did was I replicated everything they wanted from Leads and why they wanted to use leads and applied everything to contacts so it works practically the same (without the downside of duplicate entries or deleting records). It really depends on your workflow and integrations. I guess the question is why creating a new lead every time someone reMQL gives you a clean handoff to SDRs, outreach automation and easier reporting? Can it be done with using contacts instead? Why updating existing contacts leads to fragile triggers and missed outreach? Won't attribution tracking be harder if you have duplicates on your database? I think it would be better to avoid duplicate records as early as you can even if it will require a much bigger lift...
👍1