How to Create a Customer Win-Back Workflow in HubSpot

The Win-Back workflow is one of the most valuable and versatile models that I have in my HubSpot toolbox 🧰 🤑

It has taken hours of research and development across multiple client use cases, but we've really refined this down to a clean model that is replicable in any instance that tracks customer churn. I've distilled those months of research and iteration so that other fellow HubSpot admins can continue to test this model in their own projects. Each instance has its own unique nuances to consider, but the model can always be adjusted and improved to fit the need.

Add this to your Sales Operations strategy and see how many customers you can win back!

TRANSCRIPT

Hey LinkedIn, it is Liam Redding, senior HubSpot Strategist with Remotish agency. I'm here today to review one of my favorite models that I've been working on building and kind of iterating on across a couple different client portals for the last several months now.

It is one that I've particularly focused on for one of my clients. But this is one of my favorite models, I think it's replicable across the majority of instances. Everybody kind of has some process if you're in business where you need to win your customer back. As long as we're tracking when that kind of threshold is met, when we need to win the contact back, then we can trigger win back workflows in order to accomplish that goal. So we've built out a couple different versions of these, particularly for one of my clients. And we've really refined it down and they had a great idea to expand this beyond originally was just a 30 day model and into a 365 day win back, and what that would look like. So this video is an overview of how to build out a 365 day win back model. One of my most valuable models, this has taken me months and months and hours of time to develop and iterate upon. And I'm giving this view and like a five minute video. So hopefully you guys take away some of these insights back to your portals and you can build out something similar.

So in this example, I have set the customer status as any of churn. So you could also say, you know, churn date as well and make sure that it's been X amount of days since they've churned so that like when they churn, you don't immediately put them in win back that you give them a little bit of time. And then the goal of this is to get the customer status back to active, right. So that's going to be our workflow goal. And anytime a contact meets that status, they're going to be pulled out of the workflow and they will no longer be able to trigger actions, right.

So the first thing that we're going to do in a winback workflow, we're going to date stamp the contact, and we're going to set a couple properties that we use for internal reporting. And really, all three of these are going to be used for reporting. So we're going to date stamp the date that they enrolled, you can use that as a filter on your report. And we're going to set the Met goal that's either yes or no, just to track whether or not they've actually been won back at this point, we're setting that up front, so that every time a contact could potentially come back down, and you would want this to have reenrollment. Because context, status could move back to churn. Anytime somebody comes down this workflow, it's going to reset them back to No. And then it's going to set their wind back status. So when back status is any of day one through 365, dormant and won back. The reason why we have it broken out in days is because if you were to try to build a 365 day win back workflow in one single workflow, it's going to just be too much data for your computer to handle. And it's going to start to crash. Like once you get over like 300, 200 actions and a workflow starts to get to the point where your computer can't really open it, I have a pretty good computer and I've seen that problem before. So you want to try to keep your workflows concise, to the point. So we're gonna actually spread these out, and it's going to be a multiple workflow workflow.

So then we're going to delay until a day or time that's just to control when the email sends are occurring to make sure that we're not sending in the middle of the night. And then we're going to check between an if then branch, this really kind of depends on your individual use case. But this is just a kind of an example would be: you have for this customer status becoming churn, there's three products, they're all independent of one another. If one contact can only belong to one product, we then split out between those three instances or outcomes, we're then going to send an email for each of those products, trying to win that customer back and drive them back towards that reconversion point. And then each of those would be contextual based on the product, right.

You can also then add an SMS, we don't have SMS turned on in the sandbox portal. So I don't have the ability to add that as an action. But you could also add SMS, then you're going to do a two day delay. And then we're going to assign in this example, a task for the contact owner to do the 365 day win back call for day one through 30. Right. So every month they're gonna get an email, they're gonna get an SMS and they're gonna get a call, we don't really want to touch you know–that three touch points is pretty good in a 30 day window. So you don't want to make these too overly complicated in terms of like adding multiple delays adding a bunch of communication, it should be short, simple, to the point, email, SMS, task, maybe one other thing if it's particular you your use case, but you need to try to keep this as simple as possible. Then after that task, I forgot to add these you're gonna go to action. So the reason why is if you had a large work workflow like let's say this is instead of three products you have like 10 products and this is a 10 branch if then branch. These go to actions are going to reduce the amount like instead of cloning these, the delay and the enrollment and other workflow for every branch, we can just go to action, that's just the best practice for automation.

And then this is where you break it out into your next 30 days, right, so we're not going to do day one through 60 all in one workflow, we're going to do day one through 30 in one workflow, and then at the end of that, we're going to set this 28 delay, so two plus 28, that's going to be 30 days. And then you have this goal, any of active, if at any point in their journey, while they're enrolled in this workflow, and they're sitting in this 28 day delay, they become active is going to pull them out of the workflow, they will never be enrolled in the next one, right, and all of the workflows are going to have the same goal criteria. So if you say they're transitioning from one workflow to another, and during that transition, they become active, the next workflow is going to identify that and they're not going to receive any of the communications.

So you're going to do this for day three through 31 through 60, is gonna be the same except we're going to remove the triggers. And then they're just going to be enrolled from the first workflow. Again, you don't need to set all the date enrolled, because that's for the first day that they started their winback process, we just need to set the wind back status to day 31 through 60. You're going to do the same thing, same model.

And then you should add your go to actions here. The way that it's broken out is day one through 30, day 31 through 60, 61 through 90, 91 through 180, 181 through 365. When you get to 181 through 365, I didn't create all those and nest all those workflows, because it would take too long, and it doesn't really serve a purpose for this video. But on that 365th day, if they go through that final long delay, and they still have not been won back, we're going to set their status as dormant, we can create what contact lists off that. And we can also create a master list for all of those products and use that as suppression to make sure that somebody who becomes dormant then can't be re enrolled in this workflow, right.

One final thing we have is the 365 day met goal. So the goal of these workflows is for the contact’s customer status to become active, right. And we could say that a contact for this win back workflow, essentially the goal of it is to date stamp when we win back that contact to mark met goal for 365 win back from no to yes. And then the status to won back. These are static properties. These are going to be overwritten, sorry, they're not static, they're fluid, they're going to be overwritten as a contact, maybe continually go through this process. One thing you may want to consider for win back, depending on your use case is potentially building out like some kind of custom object to track that statically. So you can see every instance of that occurring across the context record.

Backup to the trigger here, we know that in these win back workflows, our goal criteria is customer status is any of active, so we've used that in combination with that win back status. So if it's anything other than won back, and it's known, then we know if it's if the customer has become active and the status is known, then we want to write them as being won back. The reason why we don't use the workflows, so you could say, you know, they met the goal for day one through 30. The issue here is you can't use that for re-enrollment.

So you have to play around with the re-enrollment here to make sure that you actually can build this in for your moment if the instance exists where contacts could come down your workflow multiple times. So that's just one additional thing to consider. Again, this is one of my most valuable models. I use it across a lot of my portals. If you're looking for an expert to help build these out, we certainly specialize in this and can customize these type of builds. While they are great for you know, a template to follow a lot of the times where it gets tricky is each of those individual use cases and building that model out customized to your business operation. So that's what we do. If you guys are interested in Remotish agency, Liam Redding, HubSpot Strategist. And I hope that all the other fellow HubSpot Strategists out there, you know, have another model to work with and have some interesting ideas. Please let me know all your thoughts, comments, concerns in the comments below and I appreciate you taking the time to watch this video!