Part of what makes Infusionsoft so powerful is your ability to be laser targeted with your communication. You can leverage not only what the person has told you about themselves, but also the actions they’ve taken. By using demographic and psychographic information you can really dial in on what might be of interest to a person. And, naturally, the more targeted your communication is, the more impactful it will be.
When you’re using the campaign builder, this type of segmentation is primarily done through using decision diamonds. A decision diamond, or decision node, appears on the campaign canvas when Infusionsoft decides it needs some logic in order to progress. In other words, if you give Infusionsoft two paths, it’s asking “When do I send them where?”
The beauty of the decision diamond is that because you’re setting it up, you get to define the rules. It’s not arbitrary. It’s very much the opposite. You get to predict the potential scenarios and script the various outcomes you’d like to happen. This allows you to be really detailed in your messaging because you know the exact set of criteria that a contact must have met in order to be receiving particular messages.
But, the decision diamonds aren’t exactly user friendly. In fact, they’re one of the more complex elements in the application. As you build rules you’re expected to use logic statements, and time and time again I’ve seen these types of rules trip people up. Let’s look at an example:
If you make the following rules:
Rules for Sequence One
If Contact’s Tags doesn’t contain TAG A or TAG B or TAG C or TAG D.
Rules for Sequence two
If Contact’s Tags contains TAG A or TAG B or TAG C or TAG D.
On the surface, these rules look like they’d be opposites. If they don’t have any of the tags they go into sequence one, and if they do have any of them they’d go into sequence two, right?
Wrong. This is actually a real scenario posed in the community forum, and graciously answered by Infusionsoft Developer Mike Daniels.
The way the first rule actually breaks down is like this:
If Contact’s Tags doesn’t contain TAG A…
OR If Contact’s Tags doesn’t contain TAG B
OR If Contact’s Tags doesn’t contain TAG C
OR If Contact’s Tags doesn’t contain TAG D
It’s as if they are four separate rules. And therefore if the contact is missing any of those tags, then they would go into the first sequence.
So, because you’re saying “doesn’t contain” it means you need to use AND instead of OR. The new rules would look like this:
Rules for Sequence One
If Contact’s Tags doesn’t contain TAG A and TAG B and TAG C and TAG D
Rules for Sequence Two
If Contact’s Tags contains TAG A or TAG B or TAG C or TAG D
Anyway, the logic statements are a little confusing, and I’ve seen some really bright people get tripped up by this stuff. So, that’s where today’s post comes in. I’ve got a little hack for you that my colleague Paul Sokol has elegantly dubbed Cascading Logic (Originally I called it “Strung Out Logic” which makes it sound more like a junkie drug addict and less like a useful strategy…).
So, here’s how it works. Basically you take what would be a complex decision diamond and you break it down into multiple simple decision diamonds. In a row.
This first occurred to me as I was building the teaser campaign I used to introduce Monkeypod back in May. Basically after I announced the blog, I wanted to set expectations about what was next for everyone. But based on the relationship I had with them, or the actions they had taken, I wanted to speak to them differently. This is how it would have looked:
Pretty straightforward, right? I’ve got four categories: Monkeypod Prospects, Not Monkeypod Prospects, Infusionsoft Employees, and Partners.
But the challenge I was running into is that I only wanted people to end up in one of the four buckets.
So, my rules would have quickly gotten complex with things like “Send them here if they have the Uses Infusionsoft tag, but only if they don’t have the Infusionsoft Employee tag, AND if they don’t have the Infusionsoft Partner tag”.
To avoid that I used a cascading logic approach and built this structure:
Each decision diamond had one rule. Send anyone with the partners tag here (Blue) and anyone who doesn’t have that tag stays up top (Yellow).
Then the next diamond looked to see if they were tagged as being an Infusionsoft Employee, and if so it sent them down (green) and if not, they stayed up top (Orange).
Then the final diamond checked to see if they had the Not Infusionsoft User tag, if they did, they dropped down into the final sequence (Purple) and if they didn’t, then they went to the last sequence on top (Red).
By setting it up this way I could speak specifically to the partners. Specifically to the Infusionsoft employees. Specifically to the people who don’t use Infusionsoft and specifically to the people who do (and also aren’t partners or employees).
I didn’t have to second guess my logic at any point, and I didn’t have to worry about anyone ending up in multiple sequences, because every single diamond was a IF A/IF NOT A type combination.
This is also a great way to end up with a catch-all sequence. More than once I’ve heard people asking why they can’t set up some rules, and then for their final sequence just say “If they don’t go anywhere else, send them here”. Well, with this scenario, you almost build that by default.
Anyway, I know this may not work for every scenario, and it might get cumbersome if you have an overly complex decision diamond. But I wanted you to have it in your back pocket in case you ever need it.
If you’ve got questions, please feel free to ask. Or if you’ve got a decision diamond hack of your own, please share!