Event-based email sequences: entry, reentry, and exit rules
Build an email sequence around customer actions. Define entry events, exit checks, duplicate handling, and reentry rules before writing the messages.
1. Choose one observable customer action
A scheduled newsletter goes out on a date. An event-based sequence responds to something a person did: requested a guide, started registration, or booked a call. A segment such as interested prospects is too vague to serve as an event definition. A recorded demo request with a contact identifier gives the team something it can implement and test.
Start with one transition. In an illustrative consulting business, someone downloads a guide but has not booked a consultation. The sequence explains the appointment and helps them choose a time. Purchase follow-up, repeat purchases, and reactivation deserve separate rules. Combining them makes it difficult to explain why a particular person received a particular message.
2. Define the event contract
Record the event name, source, timestamp, and contact key. Decide which system wins if records disagree. A form may submit twice, while a salesperson may create a second contact manually. The automation needs a way to recognize that these records describe the same person or request.
The example below is a planning worksheet, not a recommended sending schedule. Choose delays based on the customer's decision process and the expectation set when they signed up.
| Condition | Action | Check before sending |
|---|---|---|
| Guide requested | Deliver the guide | Contact is eligible for this communication |
| Two days later | Explain the consultation | No booking exists |
| Three more days later | Answer a preparation question | No booking, refusal, or unsubscribe |
| Booking recorded | End invitation sequence | Confirmation belongs to a separate flow |
3. Check the exit condition before every send
An entry check is not enough. A person can book between the first and second email. If the platform only checked booking status at enrollment, the next invitation may be obsolete. Check the current state before sending and create an explicit exit after the target event.
HubSpot documents different unenrollment behavior for different workflow types. Verify the actual configuration in your platform rather than treating an exit rule as a generic checkbox. Also test synchronization delays. A booking system may take time to update the email platform. Define how the sequence handles a booking that arrives during a waiting period, and confirm which pending messages are canceled.
4. Make reentry an intentional choice
Downloading the same guide again does not necessarily signal a new buying cycle. Without a reentry rule, a duplicate form, field update, or contact import may restart the sequence. HubSpot treats re-enrollment as a separate configuration decision; initial enrollment criteria do not answer every repeat-entry question.
Write the rule in plain language: allow a new sequence after a new request only if the earlier sequence has finished and no consultation is booked. Add a waiting period if there is a reason for one. If several products have separate sequences, set an overall communication policy as well. Test two identical events arriving close together and inspect the number of actual enrollments.
5. Draft messages against the decision path
Give each message one job. Delivering a resource, explaining what happens on a call, and answering a preparation question are different jobs. Repeating the same invitation three times is not a substitute for useful information. Include the purpose, subject line, main copy, destination, and cancellation condition in the draft.
The email-sequence tool can help draft subjects, content, intervals, and exit conditions from your brief. It does not connect event data or send messages. Before launch, run test contacts through the normal path, booking after the first email, duplicate submission, and unsubscribe. Write down the expected and actual message count for each test.
6. Measure completed transitions and incorrect sends
Email opens do not tell you whether the sequence helped people book. Track enrolled contacts, confirmed target events, and progression to the next step. Keep operational failures visible: messages sent after booking, duplicate enrollments, and unsubscribe events. Those checks help separate a copy problem from a data problem.
A comparison with last month does not establish causation. Acquisition sources, seasonality, and the offer may have changed. Start by validating the customer path and recording a baseline. If you later test a message, use an appropriate comparison design while keeping eligibility and exit rules stable. The team should be able to inspect the sequence without reconstructing it from disconnected screenshots.
Put it into practice
Frequently asked questions
How many emails should an event-based sequence contain?
Use enough messages to answer distinct questions before the next action. Start small and add an email only when it has a clear purpose. A completed target action should end invitations regardless of how many messages remain.
Do I need a CRM to run this sequence?
Not necessarily. Your email platform must receive the required events, identify contacts, and evaluate conditions before sending. Verify those capabilities with test records; a platform label does not prove the integration works.