Lead Status Field vs Funnel Stage Field in SFDC - Do You use Both?

[Iryna_Zhuravel4]

We have these 2 fields in SFDC: Lead status (lead only) and Funnel Stage (both lead and contact).

Lead Status field has the following values: Open, Working, Unqualified, Recycled, Converted; whereas the funnel stage field has all our RCM stage names and there is a set of trigger campaigns in Marketo that updates the Funnel stage field whenever a lead/contact moves to a new stage in RCM, this field is also view only to all our SFDC users (except the Marketo user naturally), so it's more just a window into the RCM rather than a lead lifecycle field.

This system was set up long before my time in the org, but it always seemed disjointed to me - both fields serve a very similar purpose, but lead status is just an incomplete version of the funnel stage field + plus it exists only on the lead object so it is very difficult to get any adequate reporting out of it (my theory is that lead status, sfdc system field, was used before the company got Marketo and was just left there unchanged atfter the funnel stage field was added).

Since the people who set all of this up are no longer with the company, I can't get any background on why lifecycle was set up this way, and keep wondering if I am missing some potential benefits of having these 2 parallel fields, so I thought I would seek out the Nation's collective wisdom and see if anyone else does it this way

I am debating between 2 ways to rebuild the system:

1. Ditch the lead status field altogether and switch to the funnel stage field, make this field editable by sales and use it for all the lifecycle campaigns etc

2. Add contact status field and update the values in lead/contact status fields to refelct our lead lifecycle and leave the funnel stage field unchanged

I am more inclined to go with the 1st solution, seems simpler and cleaner to keep everything in one field; the 2nd solution might be safer and require less reworking of the exisitng infrustructure in Marketo though

So to sum it up: does anyone use lead/contact status field parallel to funnel stage or any other similar field? If so, what are the benefits of maintianing 2 parallel fields? Which solution, 1 or 2, do you think makes more sense to implement?

All thoughts and suggestions are very much appreciated

[Grégoire_Miche2]

Hi Iryna Zhuravel​,

I totally agree with you, you should have only 1 field. A few pitfalls you should avoid :

• Avoid "Vanity" statuses such as "working", "In progress", etc... Statuses must correspond to decisions that someone (marketing or sales) made and give indication about what to do next. These vanity statuses are there not to show a decision but to pretend someone is doing something. If sales want to prove they are working, they should use CRM tasks and events. Good statuses are "Call Ready", "Recycled", "Marketing Qualified", "Sales ready", ...
• Make sure that sales cannot mess up with statuses they should not use or enter contradictory information. For instance, we often encounter leads that have an "opportunity" status but are still unconverted leads. To avoid this, we do not let sales edit the status field. We provide them with buttons for the authorized actions such as accept/convert, dismiss/recycle and discard

So you should have a contact status with roughly the same possible values as in the lead (some statuses may not be needed for contacts, but the SFDC sync rules for picklist values requires that you add them still, otherwise these picklist values will not show up in Marketo).

-Greg

[Anonymous]

One thing I can say is that you may have multiple funnels for various product lines and departments so your lead stage may not really be relevant.  In this case it would be better to have multiple funnel stage fields.

[Grégoire_Miche2]

On top of Jamie's point, if you do have multiple funnels, you can still keep one field, but use SFDC record types so that you can manage different lead processes (with different status field values, but 1 field).

-Greg

[Iryna_Zhuravel4]

Greg, Jamie, really appreciate your feedback, you confirmed everything I had in mind regarding the system I inherited and how to move forward.

One follow up question - I plan to add a SAL stage to our RCM, right now direct transition from MQL is SQL, and it is not exactly right. My concern is that adding a new stage into existing model will throw reporting off for some time, and I currently report on this model (ideally I would have preferred to just build a new model altogether, but then I won't be able to report on it for at least a few months until enough leads and data come in), do you have any advice on how to minimize the damage?

Also Greg, could you share how "buttons for the authorized actions such as accept/convert, dismiss/recycle and discard" work in SFDC? I would imagine they would be just updating the status field like "Accept Lead" button would change status from MQL to SAL, and so on.

[Grégoire_Miche2]

Hi Iryna Zhuravel​,

Regarding you first question, I do not think there is a way to avoid the reporting gap excepted to export the reporting in excel and recompute the reporting as if you had not changed the system. Somewhat similar to what companies do when they change their accounting standards.

With regards to the second point, we use SFDC "Flow" technology to create simple wizards to do a few things such as prompting the user to enter some information in dialogs and executing some process in the background and in a consistent way :

• Accepting a lead implies to convert it and create an opportunity or add the contact to an existing opportunity. So the wizard will do all this, with a few options (such as merging with an existing account or creating a new one, merging with and existing contact or creating a new one, ...). The button launching the wizard (a small VisualForce page launching the Flow) replaces the SFDC standard "Convert" button in all sales & marketing page layouts for leads.
• The dismiss/recycle/discard wizard will ask the reason for dismissing the lead, and based on this reason, will automatically assign a "recycled" or "discarded" status and change the owner of the lead to a lead queue. The button (another small VisualForce page launching the Flow) will also be added to the lead page layouts.

I am not a big fan of SAL/SQL statuses. I prefer Sales Ready and Opportunity. They are clearer about what should happen now. And I do think that when a sales accept a lead, it means they have qualified it and they should convert it immediately.

-Greg

[Anonymous]

Hi Gregoire,

I really like what you've mentioned here. One thing I struggle with is that our sales teams lives in both leads and contacts/accounts -- we actually implemented LeanData to automatically convert leads that match existing accounts. Is your sales organization only using accounts for active opportunities? I'm trying to update our process to have been status definitions (we have many of the vanity definitions you reference), but need to account for contacts/accounts that are suspects/prospects/recycled.

Any advice would be greatly appreciated.

Thanks,
Trask

[Grégoire_Miche2]

Hi Trask,

There is not one size fit all answer to this question. It really depends on your business model and target market. If you sell to Car Makers for instance, the number of potential accounts in the world you can address is limited and create a comprehensive account mapping is key, so you may convert leads as soon as you can into contacts (pay attention to opportunity creation, though, as if opportunity creation is not done on conversion, you will loose SFDC standard opportunity / campaign link).

On the other ends, if you target all types of companies or even individuals on multiple countries, you potential target is made of hundreds of thousands, even millions. Then converting everything without oppies will just pollute your database and make cleansing harder. In this case, you should rather convert only leads that have to give birth to an opportunity.

-Greg

[Josh_Hill13]

This is a great thread. Here are some thoughts, and they are thoughts only, because these are decisions that should be made with Sales and managers.

• lead Status + Lifecycle Stage fields - I've tended to use both and when I do, the Lead Status/Contact Status fields are the ways Sales makes that decision. I like that Greg says that there should be buttons and a wizard for Sales to streamline things and make it clear to them they are making a real Change and Decision. Since SFDC uses Lead Status as a default for lots of things, you may want a separate Lifecycle Field to handle history or other items, esp if you are rebuilding.
• Reporting and Rebuilding - Everyone has this problem. Even in a new build, the funnel reports will be useless for about 3-6 months. To handle this, be sure to explain this to your managers and anyone who uses the report.
• Add Contact Status - unless the Stages are really a problem, I would do a few things instead, which should avoid reporting issues
  • add Contact Status and make the first item the appropriate Stage the record should be in at Conversion.
  • Lead Status - consider modifying the NAMES as appropriate, but not really changing much.
  • Lifecycle Stage - why do you need SAL?
• Rebuilding this - i'm always tempted to do this when I'm in a new system and don't totally agree with what was done previously. I'd urge you to step back and do a full documentation of the RCM/LLC before you do anything. I understand everyone left, so be sure you understand the flows before going to your management to pitch the change.

[Anonymous]

I just want to stress Josh's point that decisions like these should involve your users, as well. When I took over our SFDC and Marketo instances, I had a lot of questions that were not answered in descriptions or documentation of any kind. My initial reaction was always "this doesn't work. It makes no sense. I should change it."

Instead of doing that, I sat down with each of my users, learned how they used the tools. I found that some of them could answer those questions about why we had seemingly random or redundant fields. And a lot of times they were needlessly redundant, but if I had just moved forward, I would have made some changes that would not have worked for my users.

Finally - do NOT delete the field right away. Hide it from users. If you delete the field, you will lose all of the data, and if you find that you need to bring it back for some reason, you're out of luck. Hide the field first, then users will get used to not having it.