Setting up auto responder automations can be tricky.
This is especially true if you want to do something your auto responder does not lend itself to doing easily, yet they give you the tools to do it anyway on the off-chance you’ll be able to see a way to pull it off.
ActiveCampaign provides marketers with a lot of email campaign set-up flexibility. Certainly enough to invite undue complexity in your automation campaigns if you are not careful.
I am going to tell you how I recently implemented one of these tricky automations. It could prove useful to you if you plan to run traffic to a webinar registration page and use the webinar to promote an upcoming event of any type.
The event could be a launch, or a workshop, or basically anything which going is to happen on a specific date in the near future.
It is the specific date that makes all of this tricky and provides the reason you might want to stick around to find out how this works.
In other words, we won’t be discussing an evergreen type campaign where whatever it is you are promoting can always be accessed or purchased for the next N days regardless of when you opt into the auto responder sequence.
No. The value of N in our scenario is going to be entirely dependent on the date on which the opt-in takes place.
So let me give you an explicit example. That way you can visualize what we are hoping to do.
From Webinar Registration, To Webinar Campaign, To Workshop Campaign
Let’s say our ultimate goal is to sign people up for a workshop. The workshop represents a live event hosted by someone, so it has a fixed date in the not so distant future.
In our case we are going to assume the workshop runs for six weeks (on a weekly attendance basis) and that a new workshop is scheduled every two months on the first Tuesday of the month.
To get people to join our workshop, which is kind of expensive, we are going to have to woo them. We cannot simply drive cold traffic, or probably even warm traffic, to the workshop registration page and expect to get much traction.
Instead we are going to have to warm up our prospects.
Here’s how we intend to do it, based on an actual model I worked on recently.
First, we drive our cold traffic to a ASK Method-style quiz which requires an opt-in for the prospect to get their quiz result. We could drive traffic straight to a webinar opt-in page, but the expectation is that our quiz will do a better job of finding us quality leads, and has the added bonus that we can attempt to persuade our audience at a later date to attend the next webinar if they pass on the current one.
So we will use the quiz to get prospects onto our list. Then we will promote a free webinar to those prospects, and to those who register for the webinar we will promote the workshop once the webinar has run.
For an evergreen sequence the webinar might be a replay which is promoted for M days after opt-in before it is presented to the subscriber. If the goal is to promote an always-available product when the webinar is over, a “limited time discount” campaign might be promoted for another N days beyond the webinar. The automations required to do this are simple to implement because there are no fixed dates to take into account.
But in our case there are two fixed dates. The date of the live webinar, and the date of the live workshop.
The simplest approach, if the webinars and the workshops are recurring, is just to ignore the fixed dates, and send promotional emails that basically say “Click here to see when the next webinar/workshop is scheduled…” or “Click here to be notified when our next webinar/workshop is scheduled…”
This kind of campaign lacks event specificity and therefore lacks urgency. We reject it.
How To Deal With Events That Have Fixed Dates
We are going to treat the fixed dates as vitally important parts of our campaigns. When someone hops onto our list we are going to tell them that the next webinar is scheduled on such and such a date, which happens to be M days from the time they opted in, and we are going to send a sequence of messages synchronized to coincide with the approaching webinar.
I could explain how to set up such a pre-webinar email campaign (automation), but I have already covered it in the related article How To Convert Cold Traffic Into Zoom Webinar Registrants And Attendees.
In that article I explained how the time remaining before the start of the webinar is determined during the registration (opt in) process and the prospect is suitably tagged in our ActiveCampign auto responder so that they immediately begin receiving messages from a SINGLE automation which sends only the relevant messages (at the relevant times) given the time remaining before the webinar.
If the plan is to run weekly webinars then you do not need many messages for your automation and you do not have to consider too many variations on what it might send someone. If the webinar is scheduled for Friday and they opt in on Saturday then you could send them messages on Saturday, Tuesday, and Thursday (“It’s happening tomorrow!”).
But if they register on Thursday you are going to send far fewer messages, and likely just one message when they opt in: “It’s happening tomorrow, don’t forget!”. You can leave to Zoom (assuming that’s your webnar platform) the job of sending reminders the next day as the hour approaches.
We can borrow the same pre-webinar promotion automation and use it here.
That leaves us with the auto responder campaign for the workshop.
Technically, this is an identical challenge to the one already tackled for the automated pre-webinar sequence. The main difference is that there now exists the opportunity to send a LOT more more messages, and the span of the pre-workshop sequence is also much more variable.
For the particular scenario I am going to consider (because it tracks the actual campaign I worked on) we are going to have 18 messages which promote the workshop and one post-event message (“Hey, you did not register for the workshop. How come?”).
So we have a pool of 19 messages.
Because the workshops happen every two months we are going to assume we might have people registering for a webinar and finding they are up to 7 weeks away from being able to apply for a slot in the next workshop (we will not be taking new applications any closer to the workshop than one week).
If the workshop is to be held any sooner than one week after they register for the webinar we will assume that this is too short a period to convert them and we will send messages promoting the following workshop. So our pre-workshop sequence will last between one week and 7 weeks.
We will also cap our promotion at 7 weeks duration regardless of whether or not workshops are separated by exactly two months (we have to cap it somewhere and if the spacing between workshops changes this is expected to be an anomaly, not a frequent occurrence – an besides we can alway introduce a delay in the automation kick off date if we need to synchronize because of an increase in the spacing between successive workshop dates).
As it turns out, planning for this potentially many-message, multi-weeks workshop promotion with a fixed start date, is quite tricky.
Let’s see why.
Planning Your Mailing Sequence(s) – The Schedule Representation
Here’s why scheduling the messages is tricky.
People have a tendency to put off doing the things they think they might want to do (like apply for an expensive workshop) until the last minute. So we would like to send them those urgent last-minute messages as close as possible to the actual cut-off time for application submission.
There are two ways to handle this.
I will explain in detail the first one, which only a mad purist like myself might try to implement (and which I did implement). Then at the end of the article I will tell you about a much simpler variant that only occurred to me in hind-sight (isn’t this always the case?!)
Here’s the first approach.
Given that we might be sending pre-workshop messages between 7 days (one week) and 49 days (7 weeks) before the final day that a workshop application can be submitted, we can envision automations which last from between one day and 49 days.
Let’s assume that the length of successively longer automations differ by exactly one day (because we are going to introduce sending delays in each sequence which are multiples of a day – for example, the first message goes out on day 2, the next goes out on day 5 after a 4-day delay, etc).
This means we could send as many as 49 variations of the message sequence.
Some of them will be short and contain relatively few messages, while others will be long and contain all of the (19) messages. Some sequences will carry the same messages as other sequences, but because of their differing overall duration, will varying a little in the spacing between messages.
The advantage of this approach which involves a sequence length tailored to the amount of time remaining before the workshop is that you can elect to ALWAYS send the last grouping of messages in a fixed date range – say from 4 days before the last day for workshop applications, and zero days from the last day. Because all you do here is allocate those messages to those dates and then work backwards to fill the remaining duration of the sequence with other messages.
During a launch, when there is a deadline after which purchases at the introductory price cannot be made, it is not unusual for half of the total sales for the promotion to occur on the last day (assuming a number of last-minute messages are sent out to remind people about the deadline).
So there is an advantage to implementing a real “this is the last minute to act” element in your sequence. This is why organizing your message sequence so that the last message always occurs on a FIXED date might be the preferred approach.
Here’s an example of 3 message sequences of duration 7 days, 14 days, and 21 days (where M1 to M19 represent the 19 different messages we might send):
7 DAY SEQUENCE (8 MESSAGES)
ID: workshop_sequence_id_07
DAY 1 2 3 4 5 6 7 8
MESSAGE M1 M2 M14 M15 M16 M17 M19
M18
14 DAY SEQUENCE (9 MESSAGES)
ID: workshop_sequence_id_14
DAY 1 2 3 4 5 6 7 8
MESSAGE M1 M2 M3 M4
9 10 11 12 13 14 15
M14 M15 M16 M17 M19
M18
21 DAY SEQUENCE (12 MESSAGES)
ID: workshop_sequence_id_21
DAY 1 2 3 4 5 6 7 8
MESSAGE M1 M2 M3 M4
9 10 11 12 13 14 15 16
M5 M6 M7 M14
17 18 19 20 21 22
M15 M16 M17 M19
M18
Some points to keep in mind as you try to understand these sequences:
- Day “1” here represents the first day after the webinar. Day “2”, two days after the webinar, is when the first message is sent. This is the case for all the sequences (all 49 of them). So the first sequence, of duration 7 days, finishes on day “8”. The 14-day sequence finishes on day “15”, and so on.
- Messages 17 and 18 are sent on the same day (and in practice a lot more messages might be sent on that day), which is the last day that the subscriber can take action (make a purchase, submit an application, etc).
Remember, the mailing sequences can be as long as 49 days in our scenario, so you are seeing here just 3 possible sequences out of 49 possibilities when it comes to the sequence duration.
Also, which specific messages you choose to add to any given sequence are up to you, and there is obviously an extraordinarily large number of ways to do this. But you can see by looking at these 3 sequences that there is a pattern to what we are doing…
We begin the sequences with M1 and attempt to add M2, M3, etc, until we run out of sending opportunities and have to switch the the closing messages of the sequence, which are messages M14 through M19.
The guiding principle in distributing messages throughout the sequences is that we do not want to send too many or too few messages, so we “eyeball it” while trying to keep things as regular as possible.
This allocation of messages might be referred to as the “schedule” representation of our intended automations. Depending on when a new subscriber registers for the webinar they are going to be assigned one of the 49 possible email sequences, the delivery dates of which are all scheduled together in a particular sequence.
This is the natural way of thinking about automations. The only problem here is that we have 49 of them, which does not lend itself to setting things up in a very efficient way.
It is however straightforward to implement automations of this type.
That is because they consist of a linear sequence of “send a message” and “wait so many days before doing it again” events. The complication is that there are a lot of these automations and each message appears in multiple automations. Some messages appear in all of them.
So, can we do better than to brute force it and set up 49 separate but very similar automations?
It might occur to you that perhaps instead of 49 automations we might squeeze them all into one very clever single automation.
In priniple this is possible, but in practice it is not.
When I wrote about setting up automations for the much shorter pre-webinar sequence containing a maximum of just 4 messages delivered over a period of 2 days to 2 weeks I mentioned that the 8 different sequences I came up with could be squeezed into a single automation. It was messy, but it could be done.
However, looking at that automation months later I found myself wondering what I could possibly have been thinking at the time I set it up.
Because it now looked completely nonsensical to me (although after studying it again for a peroid I was able to unearth and confirm the logic). If you adopt a similar approach to “simplifying” your automations it will not be long before you realize you cannot get very far with this “compacting” strategy. When you have more than a few messages to deal with it gets incredibly messy very quickly.
So to handle the current set of automations – each of which could contain almost 5 times the number of possible messages – I took a different, and in the end, much simpler approach.
Simplifying Your Automations – The Message Representation
Because it is commonplace to want to send messages every few days, or weekly, rather than daily, you are going to end up with many more automation sequence possibilities (in our case 49 of them) than messages to be sent out (we have 19 in our scenario).
Instead of setting up one automation per sequence and allocating one of those sequences to the subscriber we could do the following.
We could set up one automation per message and allocate them all to the subscriber. Some of these 19 automations will not deliver their message because that message will not be one of the messages appearing in the intended sequence.
As an example, the 7-day pre-workshop sequence workshop_sequence_id_07, which is assigned when someone registers close to the advertised workshop date, only contains 8 messages. So only 8 of the automations will send off their message at the appropriate time. The other 11 automations will do nothing.
Here is how I arrived at the structure of my single-message automations.
First I wrote down the sequence of message sends ordered by day, to see which of the “scheduled sequences” would be sending out a message, and the identity of the message. Here is what a part of that sequencing looks like for days 7 through 9:
DAY MESSAGE SEQUENCE
7 M18 workshop_sequence_id_07
M17 workshop_sequence_id_07
M16 workshop_sequence_id_08
M15 workshop_sequence_id_09
8 M19 workshop_sequence_id_07
M18 workshop_sequence_id_08
M17 workshop_sequence_id_08
M16 workshop_sequence_id_09
M15 workshop_sequence_id_10 workshop_sequence_id_11
M14 workshop_sequence_id_12 workshop_sequence_id_13
M4 workshop_sequence_id_14 ... workshop_sequence_id_39
9 M19 workshop_sequence_id_08
M18 workshop_sequence_id_09
M17 workshop_sequence_id_09
M16 workshop_sequence_id_10
M4 workshop_sequence_id_40 ... workshop_sequence_id_49
Thus, you can see that if a subscriber is intended to receive the messages in sequence workshop_sequence_id_09 they will get message M15 sent on day 7, message M16 sent on day 8, and messages M17 and M18 sent on day 9. There are 49 days to consider, so what you can see here is just a part of the overall message timetable.
Once the timetable is written out this way we can shuffle it so that it is ordered by message number rather than the day of sending. Then it looks something like this (shown for messages M3, M4, and M5):
DAY MESSAGE DELAY SEQUENCE 6 M3 4 workshop_sequence_id_12 ... workshop_sequence_id_49 8 M4 6 workshop_sequence_id_14 ... workshop_sequence_id_39 9 M4 1 workshop_sequence_id_40 ... workshop_sequence_id_49 10 M5 8 workshop_sequence_id_16 ... workshop_sequence_id_35 11 M5 1 workshop_sequence_id_36 ... workshop_sequence_id_39 12 M5 1 workshop_sequence_id_40 ... workshop_sequence_id_49
The delay shown here is just the number of days which have lapsed since the first message was sent out on Day 2. Thus, message M3 goes out on Day 6 (4 days after the first message). This is the case for sequences workshop_sequence_id_12 through workshop_sequence_id_49.
Therefore, we can create a one-message automation, call it A3, to handle message M3.
This automation waits 4 days from the time the first message is sent out (handled by a separate automation). Then if the subscriber’s assigned “sequence” is one of workshop_sequence_id_12 through to workshop_sequence_id_49 the automation sends them message M3.
In practice the sequence assignments are handled as auto responder tags and each webinar registrant (subscriber) will receive exactly one of them.
In the case of message M5, handled by automation A5, the message will be sent out on day 10, 11, or 12, depending on which sequence was assigned. And only if the sequence is one of workshop_sequence_id_16 through workshop_sequence_id_49.
The end result of implementing our automations this way is that we only need 19 of them rather than 49.
In fact, we can squeeze automations A16, A17, A18, and A19 into a single automation because they are essentially identical in structure. This is because messages M16, M17, M18, and M19 appear in every sequence and the delay between each of them is the same in every sequence. This makes it easy to compact A16 through A19 into just the one automation.
So in the end we only need to set up 16 automations, each of which contain the scheduling for just one message. This is less than one third of the number of automations we would have had to set up if we were to build one automation per message sequence rather than per message.
Not bad.
The bonus is that setting up these automations is extremely simple.
Algorithmically it goes like this: Wait a certain number of days (e.g. 6) then check whether the subscriber has been assigned one of a group of tags (e.g. workshop_sequence_id_14 through workshop_sequence_id_39). If the answer is yes, then send the message (e.g. M4) and end the automation. Otherwise wait for another number of days (e.g. 1) and check another set of tags before deciding whether to send the message and end the automation. Keep repeating this process until you run out of sets of tags to inspect for a match.
So the end result is simple-to-implement automations, and relatively few of them.
But can we do better?
How To Further Simplify Your Automations
It occurred to me after I set up the automations in the manner described above that there was another approach I could have taken.
By assuming the date of the last day for which applications could be processed was fixed, and that I wanted my message sequences to synchronize with this day, I ended up with a starting set of message sequences which ranged in length from 7 days to 49 days. By switching over to the message representation of these sequences I was able to implement just 16 automations to perform the message deliveries.
But what if I was prepared to allow the date of that “last day” for applications to vary a little depending on day of week the subscriber opted-in?
Let’s say the last day is ordinarily Friday in a specific week of the year. Using the scheme outlined in this article, if someone opts in on the Monday of the previous week they will be allocated a specific sequence of messages lasting 12 days and culminating on the “last day” (well there’s a follow up message, but let’s ignore that one).
What if we instead assigned our subscriber a 7-day sequence culminating on the Monday ahead of the “last day”?
To them, Monday would be advertised as the last day. And what if we assigned that same 7-day sequence to everyone who opted in that particular week? Someone who opted in on the Tuesday would regard the following Tuesday as the last day of the promotion. It is the same degree of “last day” urgency, just the advertised date differs.
So instead of assigning message sequences that depend on the number of days remaining before the last day that an application can be submitted, we assign message sequences that depend on the number of weeks remaining (everyone who opts in during a specific week gets the same sequence, lasting for the same duration).
This reduces the initial set of message sequences by a factor of seven (from days to weeks).
This will not change the number of message-based automations you come up with (if the number of messages does not change). But it will significantly reduce the number of tags you need to deal with when setting up the automations (because there will be fewer message sequences). So it will save you time.
Whether you figure this is worth doing, I don’t know. But it does represents another option to consider.
Comments are closed.