I'm trying to set up an easy way for us to track SQLs per month, I'm trying to do this on the contact level and turned on the HS automation where the Lifecycle stage of the company syncs with the Lifecycle stage of the contact.
What happens is that once a company object becomes an SQL, I am getting multiple contacts under the same account also be tagged as SQLs, and this causes specific periods of time to double count SQLs since they are coming in the form of multiple contacts.
Would the best solution to this be count SQLs per company name, or is there any tweak that can be done in Hubspot in order to remove dubplicate SQL contacts which are under the same company?
Tracking SQLs by contacts is fine, but if you want to track contacts at a company that become SQLs at different times, you would want to turn off the "Sync Lifecycle Stages" option. In this scenario, contact A at ACME Corp becomes an SQL in August, and contact B at ACME Corp becomes an SQL in September, you would have 1 for each month.
If you consider all contacts at a company as SQLs at the same time when the company becomes an SQL, it will make more sense to leave that option for syncing on and reporting at the company level.
Josh
Did this post help solve your problem? If so, please mark it as a solution.
Josh Curcio HubSpot support and inbound marketing for OEMs, contract manufacturers, and industrial suppliers. HubSpot Diamond Partner & HubSpot Certified Trainer
Echoing @Josh, you likely will want to turn off the lifecycle stage sync between contacts and companies since it sounds like you have multiple contacts with different roles associated with your companies today.
This sounds like it could be a solid use case for association labels (more info in this HubSpot Knowledge Base article). There are some newer workflow features that could potentially help you automate here, but you can use association labels to better define the relationship between records and target records of a specific relationship type for updates, automation, etc.
Tracking SQLs by contacts is fine, but if you want to track contacts at a company that become SQLs at different times, you would want to turn off the "Sync Lifecycle Stages" option. In this scenario, contact A at ACME Corp becomes an SQL in August, and contact B at ACME Corp becomes an SQL in September, you would have 1 for each month.
If you consider all contacts at a company as SQLs at the same time when the company becomes an SQL, it will make more sense to leave that option for syncing on and reporting at the company level.
Josh
Did this post help solve your problem? If so, please mark it as a solution.
Josh Curcio HubSpot support and inbound marketing for OEMs, contract manufacturers, and industrial suppliers. HubSpot Diamond Partner & HubSpot Certified Trainer
Hi Kristen, thanks for the reply. I have read this knowledge base article - the issue is that if we are using a third party tool to source contacts, once a company becomes SQL'd, we are having all contacts under that company become SQLs. So if we are counting SQLs per Company it would be 1, if we are counting them by Contacts it could be 35.
Not sure if this just means I cannot report SQLs on the contact level or not, but just wanted to ensure I wasn't missing something.
It sounds like this duplicate contact behavior is a result of this automation since any changes to the Lifecycle stage value on aprimary companyrecord will be applied to associated contact records.
You may want to consider turning off this setting temporarily if this automation is causing discrepancies in your reporting.
I wanted to invite our subject matter experts to see if they have insight.
Echoing @Josh, you likely will want to turn off the lifecycle stage sync between contacts and companies since it sounds like you have multiple contacts with different roles associated with your companies today.
This sounds like it could be a solid use case for association labels (more info in this HubSpot Knowledge Base article). There are some newer workflow features that could potentially help you automate here, but you can use association labels to better define the relationship between records and target records of a specific relationship type for updates, automation, etc.