Best Practices for managing Lifecycle of multiple users at same company?

[CalebNYC]

Hi all - looking for some input on best practices...a few points for context to start:

• We're a SaaS platform w/ Managed Services offering
• Contacts in our CRM who are at the same company may have their own accounts, OR may all be connected to one account together - this can be a handful of users, or 100s of users.
• Not ALL leads at a company are involved in the deal negotiations, so many are NOT associated with the Deal record
• Customer lifecycle is automatically updated for anyone connected to the Deal, but not for the other contacts at that company. 
• As you'd imagine, Customers receive different marketing emails than other lifecycle stages.

What we're currently thinking through is how to manage situations with 100s of users all connected to the same account.  Tagging them all as Customers seems like the way to go, but does throw off the "data" as it shows a much higher # of "customers" than accounts.

Any thoughts on how others are managing?  Custom Field?  Another approach? 

Thanks in advance for the input here!

[karstenkoehler · Accepted solution]

Hi @CalebNYC,

This depends a bit on your marketing. If you're marketing to all contacts associated to a company like customers, it would make sense to update all of their Lifecycle stage values. It's the best option in my opinion.

One way to automatically do this is via syncing the Lifecycle stage between deal, company and contact. You can find these options under Settings > Objects > Companies / Deals:

And yes, you're correct, this would then throw off contact-based reporting. The best option for this is simply reporting on companies ( = accounts), instead of contacts.

That way, it's perfectly fine if the deal is associated with select contacts only. The Lifecycle stage will be updated for all contacts and you can easily enroll them in your customer marketing.

Let me know if that answers your question!

[CalebNYC]

Thanks Karsten.  This is a potential solution (and marking as such), but there are still use cases that don't quite fit (e.g. large organizations with multiple offices/locations, each using their own account.)  Will give it a bit more thought before implementing, but appreciate the input here.

Cheers,

Caleb