How To Use Wait Steps In Marketing Automation

Wait steps are the pauses between actions in an automated customer journey. A contact might enter after subscribing, buying, abandoning a basket or reaching a product milestone; the wait determines when they can progress to the next check, message or update.

They look simple, but they affect relevance, measurement and contact pressure. A poorly chosen delay can send a reminder after someone has already converted, make an email arrive at an inconvenient hour, or collide with another campaign. A well-designed wait gives the recipient reasonable time to act and gives the business a clear point at which to reassess what is now true about that person.

Different platforms use different names—delay, time delay, wait, hold or pause—but the underlying choices are broadly the same. The important task is to define what the contact is waiting for, what should happen if they act during the wait, and whether they are still eligible to receive the next message once it ends.

What a wait step does

A wait step holds an enrolled contact at a point in a workflow before allowing the next action to run. That next action could be an email, SMS, push notification, CRM update, webhook, audience check or branch.

For example, a basic welcome flow may be:

1. Contact signs up for marketing emails.
2. Send a welcome email immediately.
3. Wait two days.
4. Check whether the contact has visited a key product page.
5. Send a follow-up only if they have not yet done so.

The wait is not the strategy by itself. It creates the interval in which the contact can read, browse, purchase, reply, complete onboarding or simply decide they are not interested. The decision point after it is what makes the journey responsive rather than a pre-scheduled sequence.

Most automation tools support a mixture of fixed-time, calendar, event and data-driven waits. For instance, HubSpot documents delays for a set period, a calendar date, a date property, an event occurrence, a day of the week and a time of day. HubSpot’s workflow action documentation is a useful illustration of how varied these apparently simple pauses can be. (Hubspot source)

Choose the type of wait that matches the customer’s situation

Wait for a fixed duration

A fixed-duration wait holds each person for the same elapsed period after the previous step. “Wait 24 hours after account creation” and “wait three days after the first email” are fixed waits.

Use this when the interval itself matters. A product trial may need a day or two for the customer to encounter the relevant feature. A delivery-status email may need to wait until an order feed has had time to update. An abandoned-basket reminder may be appropriate after a short interval, provided stock, price and consent status are checked before it is sent.

Be precise about the unit. “One day” may mean 24 elapsed hours, whereas “the next calendar day at 10am” is a different rule. The difference is material for someone who enters at 23:30, and around daylight-saving changes. If the business requirement is “the next morning”, configure a calendar- or time-based rule rather than approximating it with a 24-hour delay.

Wait until a specific date or time

Date-based waits are useful where the schedule is externally fixed: a renewal date, event date, product launch, appointment, birthday or end of a trial. They can also be used to restrict routine communications to a sensible sending window.

For a webinar, the logic might be: register, send confirmation immediately, wait until seven days before the event, send preparation details, then wait until one hour before the event. This is more robust than counting backwards from registration, because people register at different times.

Decide which time zone applies. For a live online event, one event time zone is normally appropriate. For a retail promotion, local recipient time may be more useful. Document the choice, including how contacts with missing or unreliable location data are handled. Avoid treating inferred time zone as exact personal information.

Wait until an event happens

An event wait holds a contact until they perform a defined action, such as completing a profile, viewing a page, making a purchase, attending a webinar or using a feature in an app. It is particularly helpful in onboarding because it lets the customer set the pace.

It should almost always have an expiry or fallback path. A journey that waits indefinitely for “completed setup” can become a hidden graveyard of contacts, with no subsequent communication and no clear reporting. A better structure is:

• Wait up to seven days for the setup-complete event.
• If it occurs, move to guidance for active users.
• If it does not occur, assess whether a helpful reminder is justified, then end or move to a lower-frequency educational path.

Event waits depend on sound instrumentation. Confirm the event fires once the action is genuinely complete, carries the correct customer identifier, and is available to the automation platform quickly enough. Do not use an email open as the sole proof that a person read or acted on a message: mailbox privacy features and image blocking make opens an unreliable behavioural signal.

Wait until a data condition is true

Some systems allow waits based on a property or attribute, such as “wait until renewal date is known” or “wait until account owner is assigned”. This can be useful operationally, but it needs data-quality safeguards. Define what happens when the value is absent, malformed or updated after enrolment. Braze notes, for example, that a personalised delay can fail where the supplied variable is empty or invalid. (Braze source)

Where an attribute is supplied by another system, the most reliable design is often to validate it before enrolment rather than asking a live journey to wait indefinitely for data that may never arrive.

Put a decision after the wait, not just another send

A common weak pattern is email, wait, email, wait, email—with no check on whether the first message achieved its purpose. That can turn a useful sequence into background noise.

Instead, use waits to create reassessment points. After an interval, evaluate the condition that matters to the journey:

• Has the contact purchased the item or started the trial?
• Has the order been cancelled, refunded or returned?
• Has the person unsubscribed or withdrawn the relevant consent?
• Has another lifecycle programme already sent a higher-priority message?
• Is the product, offer or appointment still available?

In a basket journey, a purchase check before every reminder is essential. In an onboarding journey, use the product event that shows the person has completed the intended milestone. In a win-back journey, suppress people who have recently made a meaningful purchase or received a service-related message. The right condition will vary, but the principle does not: later messages should react to current facts, not just the facts that were true at entry.

Some platforms distinguish between eligibility at journey entry and eligibility at message send. That distinction matters. Braze, for example, documents delivery validation at the message step and notes that audience membership and frequency caps can be evaluated when a user reaches that step. Braze’s Canvas troubleshooting guidance shows why teams need to understand the exact point at which their chosen platform performs those checks. (Braze source)

Set the interval from the customer task, not a generic sequence template

There is no universal “best” wait length. The suitable interval comes from the decision the recipient can realistically make and the urgency of the situation.

Journey purpose	What the wait should allow for	Useful check before the next step
Welcome and onboarding	Time to access the product or use the first feature	Whether the activation milestone has happened
Abandoned basket	Time to finish checkout without interruption	Purchase, stock status, price and consent
Event registration	Time until the relevant event milestone	Registration status, cancellation and attendance
Subscription renewal	Time to review terms, payment details or usage	Whether renewal has already completed or failed
Re-engagement	Time to consider the first message without repeated pressure	Recent meaningful activity and other recent sends

Start with operational knowledge: average time from sign-up to activation, typical lead time before an event, fulfilment timings, or the period in which a service team can resolve an issue. Then test carefully. A test of timing should hold the message, audience, exclusion rules and success definition as steady as possible. Otherwise it is hard to tell whether a different result came from the wait itself or from several changed variables.

Use conversion metrics appropriate to the purpose, such as completed activation, purchase, attendance or support deflection. Do not optimise purely for clicks. A shorter wait can produce more immediate clicks while increasing complaints, unsubscribes, duplicate messages or lower-value conversions later in the journey.

Account for contact pressure across the whole programme

A contact can be in several journeys at once. Someone who starts a welcome series may also qualify for a promotional campaign, a post-purchase flow and an account notice. Each individual workflow can look reasonable while their combined inbox experience is excessive.

Before a message follows a wait, consider global frequency caps, suppression windows and message priority. Transactional or service-critical communications usually need different treatment from marketing messages, but their presence should still inform the overall experience. A failed-payment notice followed immediately by a cheerful cross-sell is rarely helpful.

Where the platform supports it, give journeys a documented priority and define which programme wins a conflict. Braze’s message-prioritisation documentation describes how it can look ahead to potential future messages in a journey when applying caps, while some conditional or personalised steps limit that look-ahead. (Braze source) The exact mechanics differ by platform, so test the rules rather than assuming a frequency cap solves every collision.

Deliverability is part of this design. Repeated, poorly timed marketing messages can reduce engagement and increase complaints, which are unhealthy signals for permission-based sending programmes. If a sender is recovering from poor engagement or provider concerns, it may be sensible to make wait steps and contact-pressure controls part of a wider review of audience quality, authentication, sending patterns and provider feedback. That is the kind of operational work Email Foundry can support; it is not a reason to use automation to push messages more aggressively.

Define exits, re-entry and changes while people are waiting

Every wait step should have an answer to four questions:

1. What ends the wait? An elapsed duration, a date, an event or a data condition.
2. What removes someone from the journey? Purchase, unsubscribe, consent change, account closure, cancellation, hard bounce or a mutually exclusive lifecycle event are common examples.
3. Can the person enter again? A replenishment reminder might allow repeat entry after a new purchase; a standard welcome flow usually should not.
4. What happens if the workflow changes? Contacts already held in a delay may be affected differently from new entrants.

This last question is often missed. Platform behaviour during a pause, edit or reactivation is not always intuitive. Mailchimp, for example, says that contacts waiting at a time-delay step can move on when a paused flow is restarted if the pause lasted longer than their configured delay. Mailchimp’s guidance on editing automation flows is a reminder to inspect in-flight contacts before changing a live journey. (Mailchimp guidance)

Keep a short change record for important automations: what changed, when it changed, whether it applies to people already enrolled, and how the effect was checked. This is particularly valuable for renewal, payment, healthcare, travel or other time-sensitive journeys.

Test waits as journeys, not isolated blocks

Testing a message preview is not enough when timing and branching are involved. Test representative paths with controlled profiles and realistic event data. Include at least:

• a contact who takes the desired action during the wait;
• a contact who does nothing and reaches the fallback;
• a contact who becomes ineligible, unsubscribes or purchases while waiting;
• a contact who receives another campaign during the interval;
• contacts entering close to the chosen send-time boundary and, where relevant, a daylight-saving change.

Verify the actual timestamps, not merely that the workflow diagram looks right. Check which time zone was applied, whether event data was received in time, the branch chosen, the suppression logic and the message history. Journey-preview tools can help with this: Braze states that its path preview shows when a user would progress through message and delay steps without requiring teams to wait through the configured delays. (Braze source)

Finally, monitor live performance after launch. Look for queue build-up at waits, unexpected exits, recipients qualifying for conflicting flows, and gaps between a customer action and the system recognising it. A wait step is working when it makes the next action more appropriate—not merely later.

Common mistakes to avoid

• Using a delay as a substitute for a condition. “Wait three days, then send” is weaker than “wait up to three days for purchase; otherwise reassess and send only if appropriate.”
• Confusing elapsed time with calendar time. A 24-hour delay is not automatically “tomorrow morning”.
• Leaving event waits without a timeout. Contacts can remain stranded when the expected event never arrives.
• Checking conversion only at entry. A contact’s status may change while they wait.
• Ignoring other sends. Journey-level timing does not control programme-level pressure by itself.
• Editing a live workflow without considering queued contacts. Review the platform’s behaviour and the affected population first.
• Treating engagement proxies as proof of intent. Use reliable product, purchase or preference events whenever possible.

Used thoughtfully, wait steps create room for the customer rather than simply extending a campaign calendar. They are the points at which an automation can pause, learn what has changed and decide whether any further message is genuinely useful.

Frequently asked questions

What is the difference between a wait step and a delay step?

Usually none. Platforms use different labels for a pause between workflow actions. The important distinction is the configuration: a fixed duration, a calendar date, an event-based wait or a condition-based wait can behave very differently.

Should a wait step be based on hours or calendar days?

Use elapsed hours when the interval itself matters, such as 24 hours after sign-up. Use a calendar-day or scheduled-time rule when the requirement is tied to a recipient’s day, such as the next business morning or Tuesday at 10am.

What should happen if someone converts while waiting?

The journey should normally check the relevant conversion or status before the next marketing send and either exit the person or move them to a more appropriate path. For example, a basket reminder should not be sent after a completed purchase.

How long should an automation wait before sending a follow-up email?

There is no single correct interval. Base it on the recipient task, the urgency of the message, normal decision time, other communications they may receive and the evidence from controlled testing. A follow-up should have a clear purpose beyond sending another reminder.

Sources and further reading

• HubSpot workflow actions: delay options — HubSpot
• Braze: create a Canvas — Braze
• Braze: message prioritization — Braze
• Braze: preview user paths — Braze
• Mailchimp: edit a marketing automation flow — Mailchimp