Using Custom Salesforce UI to Drive Lifecycle Stages

[Sean_Richards]

I read somewhere in a thread that some people were using Salesforce UI (e.g. buttons and apex) to drive their lead lifecycle progression via the user experience, as opposed to relying on field values being changed by reps.

Can any one who has had any experience implementing this kind of thing let me know?

I am keen to know more about which steps, which UI's, which UI elements, if you used buttons/apex, or some other solution to achieve this.

Mainly this is to help us "control" the flow allowable for end users to use, to move people down the lifecycle stages.

We don't want to allow a SAL to go back to MQL, etc.

Please weigh in if you know what I am talking about. 

I thought that maybe you (Grégoire Michel ) were the one who mentioned this somewhere? Or maybe it was you Justin Norris‌?

We're about to refactor our lifecycle and I am considering that this would be a great way to "protect" the success path and detours.

Thank you all in advance.

Sean

[Grégoire_Miche2]

HI Sean Richards‌,

I did. We recommend the usage of Flows in Salesforce, that enable to create wizards without having to code. The the wizards can have multiple steps, ask questions conditionally to previous answers, and fire multiple updates. For example we will create a "qualify lead" wizard that will ask whether the user wants or accept or dismiss the lead, then if dismissal is chosen, ask for what reason, and based on the reason, the wizard will determine the new lead status, may set a recycle duration, etc... If the lead is accepted, the wizard will confirm whether it's for a new opportunity, an existing one or for account management, will also check fo existing account / contact and ask for confirmation to attach to existing or create new ones, and then the proper conversion.

Another type of wizard if for the creation of opportunities on existing accounts, to force the attachment of at least one contact.

-Greg

[Sean_Richards]

Thanks so much for coming back to me on this Grégoire.

So in the case of the "qualify lead" wizard, what fires off this Flow to execute? Or is it more that from an MQL lead queue (or contact list) the reps can open the lead/contact then press a button to launch that wizard?

Any chance you have any screenshots you could share to get me started reverse engineering it and customising for our scenarios? If not, no stress, I think this will still get me going in the right direction.

I really like both examples you provide. I do have a plugin customised at the moment that forces Contact Roles. It's working well. Every week I get a report emailed to me with Oppty's without Contact Roles and it's always returning zero  Lucky I have a small sales team that I can keep trained.

Much appreciated!

Cheers,

Sean

[Justin_Norris1]

Sean Richards I've worked on some similar things to Greg, and it's also my preferred way of managing lifecycle stage changes in SFDC. It's a way better sales UX, which makes it a lot easier for reps to take the desired behavior.

The first time we used a Visualforce page with custom buttons that triggered apex. More recently we refactored the solution in Lightning and used flows and custom components. It's helpful that non-developers are able to modify flows, but you don't get 100% of the functionality that apex provides (one example we ran into issues on was recreating a background lead conversion action). 

This approach is especially valuable when using tasks to inform sales of MQLs (which I prefer to do for a number of reasons), as you can bring together al the relevant information on the person, company, and specific inquiry in one place and then provide an easy way to automate all the follow-up actions that are needed right from the task layout - e.g. update the original lead/contact, create a new opportunity, search and add to existing opportunity, etc.

(Side note - all this being said, if you want to prevent sales from changing someone from SAL --> MQL, you can restrict the picklist options available to them or use a validation rule for this purpose.) 

[Sean_Richards]

Hi Justin,

When you talk about using tasks to inform sales, can you share a little more about how this process works? We currently promote a lead to MQL status and assign it into a Lead Queue call "MQL Queue" which then get manually triaged by our SDRs. How do you do it? 

Also, this process we have is not going to survive because we're about to refactor our lifecycle to establish a shared Lead Status across Leads and Contacts so obviously Contacts won't be able to be assigned to the Queue.

I get that we could simply lock down picklist values, but I am looking at going that next step and really making it cleaner. As you sometimes need to have values available for edge cases (or user mistakes), but don't want people to use those values. A wizard based approach seems way cleaner in the long run. Any chance you can send me some screenshots of the flows? sean.richards@schoolbox.com.au if possible.

I totally understand that Flows are limited compared to Apex. We have coding capabilities but haven't dived into Apex land yet, not to say we can't/won't. 

What were you trying to achieve with the "background lead conversion action"?

Thanks as always for sharing this insight!

Sean

[Justin_Norris1]

Hey Sean Richards‌ - 

When you talk about using tasks to inform sales, can you share a little more about how this process works?

It can be as simple as creating a task for the record owner using the Marketo flow step when the person reaches MQL. 

However, I find it more flexible to update relevant lead/contact fields in Marketo with the various data points you want included in the task, then update a date stamp field that triggers a process or apex in SFDC to create the task, pulling from those fields. This way you can populate custom fields on the task that Marketo can't access or use more complex logic if needed. 

This process assumes that you are routing leads to a named owner by the time they reach MQL. If you are triaging out of a queue, it won't work as you can't assign tasks to queues. 

Some benefits of using tasks generally are: 

• Allows sales to work on both leads and contacts from one consistent view, without switching objects. 
• Allows you to notify sales about multiple inquiries from the same person even if they are already in a later lifecycle stage.
• Provides a more flexible way to track lifecycle and SLAs, particularly as the funnel grows more complex and less linear - i.e., multiple products, cross-sell and up-sell, etc. 

You do need a well-designed process and buy-in (including executive level) from sales.

Any chance you can send me some screenshots of the flows?

They are in a client environment, and I can't share that unfortunately. However, I would suggest that building the flows themselves is the more straightforward part (although not without challenges).

The more challenging piece is usually designing how you want the process to work and getting alignment with all your stakeholders.

In particular, make sure you define the reporting you want in detail up front, so you can ensure that your process will supply the data for those reports.

This is an early stage wireframe of the task UI from one project, which at least gives a sense of how the sales experience can work. 

What were you trying to achieve with the "background lead conversion action"?

If the person is a lead and you want to create an opportunity, you have to first convert them. With the flow we just had to hand them off to the standard lead conversion process and then pick it up after, but apex could handle this more seamlessly as I recall. 

[Sean_Richards]

Great conversation here and thank you for your detailed response Justin. Loving it.

However, I find it more flexible to update relevant lead/contact fields in Marketo with the various data points you want included in the task, then update a date stamp field that triggers a process or apex in SFDC to create the task, pulling from those fields. This way you can populate custom fields on the task that Marketo can't access or use more complex logic if needed. 

This process assumes that you are routing leads to a named owner by the time they reach MQL. If you are triaging out of a queue, it won't work as you can't assign tasks to queues. 

Understood. We need to deprecate the Queue anyway but were considering just assigning them to our API user who owns all records not owned by people. We don't have a requirement at this stage for complex lead routing by territory etc, although we'll probably grow into that need. Funny thing is, we do have a single person who triages, so I'll have to think if it improves things to just assign to them, given that's the reality, why not.

Some benefits of using tasks generally are: 

• Allows sales to work on both leads and contacts from one consistent view, without switching objects. 
• Allows you to notify sales about multiple inquiries from the same person even if they are already in a later lifecycle stage.
• Provides a more flexible way to track lifecycle and SLAs, particularly as the funnel grows more complex and less linear - i.e., multiple products, cross-sell and up-sell, etc. 

I like the position on keeping the sales working process the same across both objects and agree that tasks provide the ability to abstract that. Our current plan was to move the MQL Queue to a report, then duplicate it for Contacts. Same for Working (SAL) People, just have two lists, then bring it all together for reps on a single SF Dashboard.

RE: Multiple inquiries: We are still able to handle multiple fast track inquiries as we've abstracted our MQL Alert from our fast track form Alerts, which means we actually fire two alerts if the person makes an inbound fast track inquiry and MQLs. And we're cool with that as it also means we get the benefit of instant alerts if a repeat inquiry is submitted.

I also agree that tasks provide a excellent object to build that SLAs and have a range of different tasks types etc.

Q: Do you use SF record types on tasks? If so, can you share the scenarios?

The more challenging piece is usually designing how you want the process to work and getting alignment with all your stakeholders.

In particular, make sure you define the reporting you want in detail up front, so you can ensure that your process will supply the data for those reports.

We're pretty lucky and dynamic at this time so alignment with sales won't be hard, in fact, this is more of an improvement project than a start from scratch. We audited our lifecycle programs across Marketo/SF over the last two days and estimate about 3 weeks work for two of us to complete the refactor. That's before we then add these Flow based wizards etc.

We agree that defining reporting requirements from the start is key to mapping the processes and functionality needed to deliver the data for them.

I think the main thing for us would be:

• Reps to see their pending follow ups (SLA), discovery/qualification tasks (for MQLs) with is also an SLA, their current working leads (with amount of time in that working state, i.e SLA)
• Sales manager, same but with oversight over the team

I really appreciate you sharing, particularly that wireframe, it's good food for thought. I can see myself investing a lot of time on this next iteration. 

We had never thought about Flows to drive these processes, so you've unlocked a new Pandora's box for me!