5 Marketing Automation Examples With Exit Rules

A shopper leaves a cart, a new subscriber waits for a useful first email, and a sales lead sits in an unclaimed queue. Each situation invites an automated message. Yet a message is only one part of the decision. The harder questions are who should enter the workflow, what should happen next, and when the workflow should stop.

The most useful marketing automation examples answer those questions together. A workflow starts when a record meets its enrollment conditions, then performs actions such as sending a communication or changing a record. Rules for re-enrollment determine whether the same person can enter again. HubSpot’s workflow documentation describes the enrollment and re-enrollment choices, while its actions guide covers communications, record changes, delays, and branches. The design choice is yours: define the event, the eligible person, the useful response, and the reason to end the response before you write the email.

The five workflows below are designs you can adapt, not accounts of campaigns that produced a claimed result. They cover an early relationship, an expression of interest, a shopping interruption, a sales handoff, and a first product experience. Each is useful under different conditions.

A welcome sequence should help a subscriber take the next step#

Imagine someone subscribing after reading a practical guide. A welcome email can acknowledge the subscription, but a run of promotional messages would spend the new relationship before learning what the person came for. I would begin with one email that delivers the promised resource or points to the relevant starting place. A second email is justified only if it answers a likely next question that the first one leaves open.

This is a straightforward example of automation because the entry event is clear: the contact subscribes. Mailchimp’s classic automation types include a welcome message and an onboarding series triggered by signup, with later emails following the earlier ones on a schedule. The documentation shows that a sequence is possible; it does not establish that every subscriber needs one. For a newsletter whose promise is simply regular updates, a single welcome message may be the entire workflow.

The working design might read: when a new eligible subscriber joins, send the promised item; after a pause, send a short explanation of how to use it; then stop. If a subscriber already received that introduction, exclude them from a second copy. That exclusion matters when contacts enter from more than one form or when an existing contact subscribes again. The workflow should reflect what the person has already received, not merely which form was submitted most recently.

Re-enrollment deserves an explicit decision. HubSpot notes that records are enrolled the first time they meet workflow criteria by default, while re-enrollment can be configured. For a first welcome, I would generally keep re-entry off. A new signup event should not restart an introductory series for somebody who already knows the product. If the business wants to welcome people to a genuinely separate program, that is a different promise and deserves its own eligibility rule. HubSpot’s trigger guide makes the repeat-entry choice visible; it cannot decide whether the repeat message would be welcome.

The cost of this restrained approach is that you have fewer scheduled chances to ask for a sale. In return, every email has a reason to exist. If readers consistently need a third explanation before they can use what they requested, add that explanation because it solves a specific problem, rather than because the automation builder has room for another step.

A resource follow-up should change with the contact’s answer#

Suppose a person requests a guide comparing two approaches. A fixed series can send the guide and then a follow-up, but it cannot tell whether the person wants implementation details or is still deciding what the approaches mean. This is where a branch is more useful than another timed email. HubSpot’s actions guide describes branches that direct enrolled records down different paths according to criteria, alongside delays and communication actions.

An illustrative flow would send the guide first. If a contact then supplies a relevant preference through a form or a reliable contact field, the next message can address that stated preference. If the preference is unknown, the safer path is a general explanation or no further message. The branch should depend on information the contact actually supplied or an event the system records. It should not turn a missing value into a confident claim about the person’s needs.

This example also shows why the enrollment condition and the branch answer different questions. The request for the guide tells you that delivery is appropriate. It does not tell you which follow-up is appropriate. A contact may meet the first condition while lacking the information required for the second. If the branch uses an old or empty field, the automation can send a polished answer to the wrong question. The technical branch will function; the conversation will still feel careless.

I would choose this workflow only when the alternate paths contain meaningfully different help. If both paths merely change the opening sentence before making the same pitch, the added logic creates more ways to get the message wrong without giving the reader much value. A single, clear follow-up is the better choice until the contact data supports a real distinction. The cost of branching is ongoing attention to the field or event that chooses the path; when that input loses meaning, the branch loses meaning with it.

Cart recovery should stop when the purchase happens#

An abandoned cart is a tempting trigger because the shopper has selected something concrete. Mailchimp’s abandoned cart guide describes a commerce trigger, a configurable wait before an eligible contact enters the flow, and an email containing the cart information and a link back to it. Those details make the response specific to the unfinished checkout. They do not reveal why the shopper left. The person might have been interrupted, might still be comparing options, or might no longer want the item.

I would start with a single reminder that makes returning to the cart easy. The entry rule should identify the store and the cart event, and the send rule should check that the contact is eligible for that message. Before any later reminder, check for a recorded purchase and end the recovery path when one appears. The next message after a purchase should not ask the customer to finish buying what they just bought. A delayed commerce event can still create an awkward late message, so the workflow depends on how promptly the store and messaging system exchange purchase information.

The same logic limits re-entry. A shopper may leave more than one cart over time, so a permanent one-time rule could miss a later, distinct cart. Unlimited repeat entry can send a stream of reminders to someone who repeatedly edits a cart. I would tie re-entry to a new eligible cart event and set a clear limit on how much contact a shopper can receive. That choice costs potential reminders, but it keeps the workflow aligned with a current shopping decision instead of treating every cart change as a fresh invitation to send.

A discount is a poor automatic first move when the cart event alone cannot explain the hesitation. It may reward a shopper who was about to return without an incentive, and it cannot address a checkout problem the shopper encountered. The initial reminder should carry the cart link and the information needed to resume. If a business wants to test another response, it needs a separate reason to believe that response solves the actual interruption.

For this workflow, count a purchase only when it follows an eligible abandoned cart, and watch for messages sent after the purchase record appears. The first number tells you whether the flow is associated with completed checkouts; the second reveals whether its stopping rule is failing. Neither number, on its own, proves that the reminder caused the purchase. The practical question is whether the workflow reaches people who can still use the reminder and stops reaching those who cannot.

Lead routing should hand work to a person who can act#

A form submission can create a lead, but an acknowledgment email does not move the lead to the right human. Salesforce’s lead implementation guide describes assigning a lead to a user or a queue. A queue can hold the record until a member takes ownership. That is a useful automation action, but assignment and follow-up are different events. A lead can have an owner in the system while the person behind the form is still waiting.

An illustrative routing flow starts when an eligible inquiry arrives with enough information to choose a destination. The record goes to a named owner when responsibility is clear, or to a queue when a team must take it. The automation can then create a task or send an internal notification if the chosen platform supports that action. HubSpot’s workflow actions include record and internal communication actions, although availability depends on the account’s settings and subscription. The marketing message to the inquirer should make only the promise the team can keep; an instant acknowledgment is not a substitute for an actual answer.

I would settle the fallback before switching this flow on. What happens when a form lacks the field used for routing, or the named owner is unavailable? Sending every ambiguous lead into an unmonitored queue merely hides the problem. A deliberate fallback owner or queue, with a person responsible for checking it, is more useful than a technically complete rule whose exceptions have nowhere to go.

The choice between a named owner and a queue depends on how work is actually claimed. A named owner gives responsibility to one person at once, which is useful when territory or account ownership is known. A queue lets a team share intake when the right person is not yet determined, but someone must claim the record. I would favor the named owner where the data supports a reliable assignment and use a queue for genuine exceptions. The cost is maintaining the routing data and the human process behind it.

For this example, the revealing times are when the inquiry entered, when it was assigned, and when someone first responded. A quick assignment with no response is a handoff failure, even if the automation ran exactly as configured. If the data needed to choose an owner is frequently missing, improve the intake or simplify the routing rule before adding more branches.

A product tour should guide one task, then get out of the way#

After signup, a new user can see an interface full of options without knowing which action matters first. An automated tour is appropriate when the product has a specific early task worth showing in context. Intercom’s Product Tours guide describes targeting a selected audience on a page and guiding users through interface steps. That makes the product itself the place for the message, instead of asking the user to leave the task and read another email.

An illustrative tour could open for users who reach a setup page and have not yet completed the setup action. The first step identifies the control they need; the next explains the choice they must make; the tour ends after explaining that task, and the user can dismiss the guidance. A tour that marches through every menu may be easy to build but hard to use. The point is to remove the next obstacle, not to display the whole product at once.

The audience rule matters as much as the tour content. A returning user who already completed setup should not have to clear the same instructions again. A user who cannot access the feature should not be directed toward an unavailable control. Because the interface and eligibility data can change, a tour that was helpful when published can later point to the wrong place or show to the wrong people. Keep the target narrow enough that each step still matches what the selected user sees.

I would treat tour completion as a sign that the user reached the end of the guidance, not as proof of lasting adoption. The more useful next question is whether the user performed the task the tour was meant to support, and whether the guidance still appears when that task is relevant. If most users already complete the action without help, the tour may be unnecessary friction. If they cannot complete it even with guidance, the product step itself may need attention.

Choose the first workflow by the decision it can make well#

These examples differ in channel, but the best starting point follows the same rule: automate a decision only when the entry event is clear and the response can be made specific. A welcome email needs a trustworthy signup event. A resource follow-up needs a real preference before it splits. Cart recovery needs a current cart and a purchase stop. Lead routing needs a destination and a person who will take responsibility. A product tour needs a visible task and an audience that can perform it.

If you are choosing one workflow to build first, pick the place where a useful action is already known and a missed or repeated action would be obvious. Write down the trigger, exclusions, next action, stopping condition, and re-entry rule in ordinary language. Then ask what the person receiving the message or task would think had happened. This small exercise often exposes the missing purchase event, stale contact field, or unclaimed queue before any customer encounters it.

Automation earns its place when it carries a clear decision at the right moment. The benefit is consistency: the promised resource arrives, the cart remains easy to recover, the inquiry reaches an owner, or the user sees the next step inside the product. The cost is that every rule depends on the underlying event and record staying accurate. Choose fewer workflows whose conditions you can explain and maintain, and expand only when the next branch or message solves a distinct problem.