New leads not tracked because of deduplication

This is a topic of endless debate, but I personally think campaigns/program membership can be a solution here. Obviously you want reports on net new names to your system, and created date or lead source reporting can be sufficient. But for new inquiries from existing records, you might want to think about building campaign membership reports that show members who've been added or responded to a campaign in the past week or month. 

If you use SFDC campaign reports, your sales team can use these as a method of reporting, and you can sync your Marketo programs with these camapigns, so that you can update the data automatically. 

So if you have a webinar for instance, when the event concludes, your event provider will sync with Marketo, which will sync with a camapign code, and your sales team can then use the reporting of that campaign's membership in SFDC to determine their follow up activities.

Just a thought!

We split everything into two categories... net new and all time. It can get kind of fuzzy, since reporting on created date makes things so much easier, but say you want to know how many demo request forms are submitted this month, you could create a report in Marketo saying "Filled out Form = Demo Request" and add a date constraint for this month. Set the "Leads Created At" to all time and you'll see just the submits from this month.

If you're looking to purely analyze this in SFDC, that will be a little trickier, but you can do things like set up custom fields to say "Last Form Submitted" and "Last Form Submit Date" -- then have Marketo change those fields each time a form is submitted, then run SFDC reports off of them. If you're consistent with your naming, you could group/filter by either to see how many of each form is submitted and in what time frame. Then you could break that down further by looking at their created date and see how many net new submitted, vs older leads.

Hope that helps!

One way around this is to not have a report for all actual new leads/records in the system, and instead define something like a "Marketing Qualified Lead" and have an associated date, like MQL Date that gets automatically updated whenever a record go into the MQL status.

This way, sales gets a report of all MQL leads by MQL date - some of which might be brand new and some of which might be old leads that have recently become MQL (by filling out a form again, or their lead score went up past some threshold, etc).

Hope that helps!

Hi everyone,

Thanks for your feedback. Sadly, I don't think any of the proposed solutions will work for our situation. See below, and if you have any other suggestions that would be greatly appreciated!

Jeff, reports on campaign members are very very limited on what we can pull in and run metrics on. For example, If I want simple number about how many of these inbounds were sales accepted I wouldn't be able to pull in lead status, only campaign member status.  I've tried running these in the past.

Matt, adding a new field would be ideal except that would force sales to look at two reports, one for contacts & one for leads.  We work mainly off of contacts because we're B2B and need contacts to be associated to accounts when prospecting.  But all brand new leads that fill out key forms, will be added as a new lead. So our inbounds are mainly leads, but about 10% of inbounds are already existing contacts.

Grant,  we do have the MQL status in place and our SDRs work off of those too, but Inbound MQLs are higher priority than others. RIght now the issue we're having is making sure those Inbound MQLs don't get missed and that we can run 1 salesforce report pulling all inbound information whether they currently exist as a contact or are a brand new lead.

After doing more research here is the solution/process I am looking to implement:
1. Any key form fillout creates a lead (even if it is a duplicate)
2. Designated SDR gets a notification then does some digging, and manually dedupes in SFDC if needed
3. Designated SDR reassigns the lead/contact to the right person
4. Marketing can easily run a SFDC lead report on all inbounds

There were a lot of comments about avoiding duplicates in other discussions, but currently I didn't see any way that would work around it. Thoughts?

Melissa,

Thanks for your answers. It gives me more specific information about how you're running things - especially the part about most exisiting records being Contact and most inbound records being Leads. The approach I suggested won't work in this scenario, because you'll inevitably need to create more than one report for this.

Jeff's suggestion about the campaign reporting would also be a good one - but it would once again require two separate reports, one for Campaigns with Leads and the other for Campaigns with Contacts.

Unfortunately, without some custom SFDC work there is no way to run a single report on both Leads and Contacts with the full detail that you require. There are also apps that can work around this.

I wouldn't recommend going with the form that will create a new record everytime - because it won't actually solve your problem, and instead move it somewhere else (now you have to manually search and merge records).

Agreed campaign members is a limited table to run reporting on, but it is one of the few places you can see leads and contacts together, and with a bit of love from a SFDC admin, it can be customized somewhat to get at some of the custom fields you want to see. 

Hi Melissa,

Have you implemented this flow already to create duplicate leads?  How is it working out for you?

We're up against a simliar discussion with Sales and my team and I can think of every reason why we shouldn't do this but I'd like to hear from someone who has successfully implemented this dupe model.  I've learned this is similiar to how SFDC internally manages their own inbound queue.  Contacts who respond to campaigns are created as new leads. 

It sounds like an alert to me and we've tried the task route which is not working on the contact reporting side.  Any feedback from the group would be helpful.

Thanks
Praveena