Adding a Deal Stage and Possible Consequences

[#1]

Hi,

If we wanted to add a deal stage what potential impacts would there be on the existing pipeline and on reporting?  

Specifically, I'm being asked to vet adding a Closed Nurture stage that will help separate out deals and associated companies that need to be put into nurture vs. those that are truly Closed Lost.  I have seen other posts about this topic on here but some of the pushback I am getting about using Lead Status is that we can't make it a required field upon deal closing since it isn't a deal property.

Any thoughts are appreciated.

Thanks!

[#2]

Ok, so HubSpot contact lead status and company lead status are fully customizable properties. You could add an equal lead status property to the HubSpot Deal object, then require that property at a particular deal stage.

That being said, not sure including lead status on a deal is best solution since, as the name implies, it's a lead status that really applies to a contact &/or a company and which may not translate nicely to all associated deals.

A more flexible and less invasive option may be to create a custom deal property -- e.g., deal.nurture.status [because 'Deal Status' is already a default HubSpot deal property]. One of the deal.nurture.status optional values might be 'Nurture'. In that case we can build a company workflow that says something like ...

If deal.nurture.status === "Nurture" set company.lead.status to "Nurture".

This is a very different and more surgical solution than that typically employed to 'copy lead.status' between companies and contacts. And, it eliminates the need for yet another deal stage which can clutter our deal board view and add to reporting complexity.

Perfect? No. Workable? Sure.

[#3]

Thanks @MFrankJohnson , as usual!   This makes perfect sense.  The only item would be updating the deal.nurture.status property when the associated company is no longer in nurture (either from a new deal being created or permanently lost from no response, etc.)   This is probably going to have to be a manual update to those deals to take them out of nurture correct?

[#4]

Great point @SteveMatlick ... hadn't considered an 'exit strategy'. Sill wrapping my mind around potential pitfalls surrounding the modification of contact.lead.status or company.lead.status based on deals at scale.

However, you are correct -- i.e., probably a manual update. If not, maybe add some sort of safety net workflow that checks for company.lead.status <> 'Nurture' and possibly resets that deal.nurture.status property after 8-10 hours for all associated deals. That way, it's handled by the next business day, but not so soon as to disrupt the current day's sales operations.

Bottom line, best to have a single source of truth for lead.status in the portal. That way, AE's aren't constantly bumping into each other or errorneously engaging contacts who really should be in nurture status.

Again, just a thought ... still intersted in hearing from others on the potential consequences of adding a custom deal.nurture.status, and if there may be a better solution for your use case.

ping: @Josh @ConnorSlivensky et al.

[#5]

I guess it depends on how nurturing is implimented. If it's through a workflow (or series of them) you could use completed workflow as a trigger to change the status.

Or if you could get a series of properties to create a list you could have a list for unenrolling them or dropping them from a list so they no longer meet enrollment critera.

I think my first solution would be the cleaner of the two but it really depends on what you have to work with.