Hi all,
In our organisation, a prospect is considered SQL when they book a meeting with a rep.
On the event they cancel that meeting because they’ve decided that we’re not the right fit, or the timing is not right for them, how are you managing this prospects lead status?
I.e. are you simply moving them backwards to a MQL or Lead or do they stay as an SQL and simply change the Lead Status to reflect the reason, keeping the prospect in SQL? Would love to hear what others are doing!
I also want to try and understand how many prospects are moving backwards, if that’s possible?
Hi @Sohail-Foryabee,
There are different philosophies about this. Which approach you pick depends on how you’re planning to report on this.
One option is to reset or change the lifecycle stage back, yes. This would then correctly reflect the lifecycle stage that matches the contact best on their current level of qualification / where they stand in the buyer’s journey. However, the big disadvantage of doing this is that you’ll lose the “Became a Sales qualified lead date” of this contact (this will be reset) and the contact will disappear from the SQL stage in funnel conversion reports. In other words, it’ll look as if this contact has never been generated. Especially if you have a SLA with marketing, you would have to consider this. It removes the ability to see how many SQLs were disqualified over time. (There are again workarounds for this, by using a workflow that sets a date stamp when you disqualify a SQL etc – but they’re adding a comparably high level of complexity.)
On the other side there is the option to keep the SQL where they are and think of the lifecycle stage as the farthest point a contact has gotten in the buyer’s journey. This is what I prefer. Using lead status or a disqualification reason field, you can easily mark these contacts and stash them away. If you don’t want them to show in certain reports, simply filter them out by lead status or disqualification reason. They would still show up by default in SQL reports and funnel reports – which is great. If you ever want to re-engage them, simply filter for SQLs with those specific lead statuses / disqualification reasons. The main disadvantage is that users need to get familiar with not only checking the lifecycle stage but the lead status / disqualification reason, too, which I think is perfectly acceptable.
Best regards
Hi @karstenkoehler,
This is an extremely helpful response, so thank you.
Will be moving forward with the second option!
+1 for @karstenkoehler’s perspective here, using lifecycle stage as the “furthest point” in the journey.