Hola! ¡Tenemos nuestra Comunidad en Español!

Moving lifecycle stage backwards?

Highlighted
Regular Contributor

I need to measure the number of contacts in each stage of the sales & marketing funnel (always looking at a group of leads created during a specific time period and seeing how those leads converted). We're considering allowing leads to move backwards in the funnel which confuses EVERYTHING.

 

We're a Salesforce-first organization that uses leads and opportunities. The funnel is made up of lead rating values and opportunity stage values (Raw, MQL, SQL, Discovery, Evaluation, Negotiation, Signature).

 

The reason we are considering allowing contacts to move backwards is because if a lead reaches SQL stage or later and then drops off, we want to be able to reengage them as Raw and track them through the funnel again. But this causes so many problems:

 

  1. I couldn't base the time period off "create date" because re-engaged leads need to be included based on when they were bumped back to a previous stage, not when they were created.
  2. SQLs and opportunities aren't actually leads in Salesforce, they're contacts. So if a Contact needs to go backwards in their funnel stage, I'd have to use a new "Contact Rating" value. Then, to measure Raw leads and MQLs, I'd be pulling 2 reports: a lead report with lead rating, and a contact report with contact rating.

That's why I'm considering using Hubspot, which doesn't differentiate between leads and contacts. I could create a custom "Funnel stage" or "Lifecycle stage" field that is synced to the Lead Rating and Contact Rating value, but report on it in a single report in HubSpot.

 

But I've read that HubSpot lifecycle stages also aren't meant to go backwards and that they make it pretty difficult to do in workflows. Obviously I'd have a custom lifecycle stage field so that doesn't matter as much but it seems like moving backwards is highly discouraged.

 

I'm wondering what experiences other people have had moving leads/contacts backwards in their funnel (or deciding against it) and what advice you have. Thanks!

 

 

 

 

10 Replies
Esteemed Advisor

Hi, @JTChal. It's not that you can't do this - check this help article for more details on using workflows to clear the lifecycle stage value then setting it to its desired 'backwards' value - it's that the property (and its associated analytics) are tied to the forwards-only behavior. [Please note workflows are only available with Professional subscriptions of Marketing or Sales, or an Enterprise subscription of the Marketing product.]

 

As a result, there are a few caveats to this sort of approach. If the restrictions in that help article are something you've accounted for, or not impactful to your organization, then you should be fine to proceed using the steps from that knowledge doc.

 

Even if the considerations from that help article aren't in play, you'll want to design your workflows carefully. You won't be able to think of any single workflow as a singularity; any workflow which clears-then-sets the lifecycle stage property must be grouped together and considered, any time you want to make changes to any part of the scheme. This includes considering whether special reenrollment or suppression criteria exists. 

 

You may also want to consider creating helper properties which either create some sort of numeric count, or are datestamped, which the workflows clearing-then-setting lifecycle stage would also be responsible for setting. Plan carefully, think about who in your organization would be impacted by any lifecycle stage, and most importantly, design something comprehensive which is straightforward enough to troubleshoot when you need to change the scheme. This doesn't mean it can't be granular, but if your scheme is both granular and complex, it'll be awfully difficult for anyone to maintain.


Brad Mampe, Salesforce Analyst, Fidelity
I'm probably wrong. I may not be right about that.
Regular Contributor

Hey, thanks for the response. It's great advice to keep the workflow(s) as simple as possible - because you're right, if it's too complicated it'll just be miserable to maintain. But I'm also wondering whether we just shouldn't let contacts move backwards in their lifecycle stage at all. It seems like most tools try to prevent you from moving backwards, which says something. If we want to reengage SQLs that fall off, maybe the better thing to do is to keep them as SQLs and have a time-based workflow to nurture them once they've gone inactive for a certain period of time.

 

 

Reply
0 Upvotes
Esteemed Advisor

You may do better off with a hybrid approach, keeping the default lifecycle stage movements intact, but using a set of custom properties to reflect the "true" lifecycle stage (along with any other datestamps or number-counters and such).

 

People who clear out the lifecycle stage then set them backwards don't care nearly as much about the analytic properties or became a customer properties and the like. If there's some sort of value to those, it may be better off leaving them as is and augmenting that with your own custom scheme. Make sure this is well-communicated to your users, if so.


Brad Mampe, Salesforce Analyst, Fidelity
I'm probably wrong. I may not be right about that.
Regular Contributor

We definitely care about those types of analytic properties, so I think a hybrid approach at a minimum makes sense. I'd still love to get peoples' input on their personal experiences deciding to move contacts backwards or not. It would certainly save a lot of headaches not to move backwards.

Reply
0 Upvotes
New Contributor

<Following>

We are mapping out a hybrid approach currently. I too would like to see a successful process flow with custom fields used to retain historical lifecycle data.

Reply
0 Upvotes
Occasional Contributor

<Following>

We are also struggling with this and are interested to hear how other people handle it.

Reply
0 Upvotes
New Contributor

@JTChal what did you end up doing? We are working through this now.

Reply
0 Upvotes
Esteemed Advisor

@Jonah-kai, if you haven't already found it in your search, @MFrankJohnson left some great feedback in another similar post about how to handle this use case. [There's also more of my own rambling there.]


Brad Mampe, Salesforce Analyst, Fidelity
I'm probably wrong. I may not be right about that.
Regular Contributor

I definitely care about those types of analytical properties, so I think a hybrid approach at a minimum makes sense. I'd love to get peoples' input on their personal experiences deciding to move contacts backward or not. It would certainly save a lot of headaches not to move backward.

Reply
0 Upvotes
New Contributor

We are also a salesforce first organization, and are struggling with this. Where we've landed so far is creating a custom lifecycle stage for "closed lost" which basically helps us understand that this contact wasan Opportunity contact that now needs to be specifically renurtured as a "closed lost" contact. For us, we ONLY convert the person from a lead to a contact (in salesforce) if they are moving into an opportunity. This way, our salesforce org stays clean. All Subscriber, Lead, MQL and SQL live in salesforce as leads and all Customers, Evangelists and Opportunity (and new Closed Lost) all live as contacts.

Reply
0 Upvotes