Delay Step

4 min read

Also known as: Wait Step, Pause Step, Sleep Step

An automation step that pauses workflow execution for a defined duration before proceeding to the next step.

Definition

A delay step is an automation building block that pauses workflow execution for a defined duration — minutes, hours, days, or until a specific date/time — before proceeding to the next step. It's the most basic timing primitive in automation: wait, then continue.

Delay steps are essential for time-sensitive workflows that need pacing: a welcome email at signup, followed by a delay of 2 days, followed by an onboarding tip email. Without delay steps, the entire sequence fires instantly at the trigger event — overwhelming the user and missing the timing logic.

Modern automation platforms support flexible delay configurations: fixed durations (wait 3 days), date-based (wait until next Monday at 9 AM), relative to a property (wait until 7 days before the contract renewal date), and business-hour-aware (wait 3 business days, skipping weekends and holidays).

Why It Matters

Timing is the difference between an automation that feels personal and one that feels robotic. A trial-end reminder sent 3 days before expiration is helpful; the same reminder sent 3 days after expiration is useless. Delay steps are what make timing-aware automations possible.

The biggest mistake is using fixed-duration delays where context-aware delays would be smarter. A 3-day delay between Step 1 and Step 2 is fine for most users, but a user who signed up Friday afternoon receives Step 2 on Monday — possibly bad timing. Business-hour-aware delays handle this naturally.

Examples in Practice

A SaaS onboarding workflow: trigger (signup) → send welcome email → delay 2 days → send tip-of-the-week #1 → delay 4 days → send tip #2 → delay 7 days → send 'are you stuck' email. The delays pace the engagement without overwhelming the new user.

A renewal-reminder workflow: trigger (contract renewal date set) → delay until 60 days before renewal → send executive briefing email → delay until 30 days before → send renewal proposal → delay until 7 days before → send urgency follow-up. Each delay is calculated relative to the renewal date.

A multi-time-zone email program uses business-hour-aware delays: trigger (form submission) → delay until recipient's next 9 AM local time → send welcome email. Recipients in Tokyo receive the email at 9 AM JST, recipients in LA receive it at 9 AM PST — same workflow, different absolute times.

Frequently Asked Questions

What is a delay step?

An automation step that pauses workflow execution for a defined duration before proceeding. The most basic timing primitive — wait, then continue.

What delay types do platforms support?

Fixed durations (wait 3 days), date-based (wait until next Monday 9 AM), relative to a property (wait until 7 days before renewal date), and business-hour-aware (wait 3 business days, skipping weekends/holidays).

Why are delays important in automation?

Without them, the entire workflow fires instantly at the trigger event — overwhelming the user and missing timing logic. Delays pace engagement appropriately for the user's context.

Should I use business-hour-aware delays?

For most B2B email and notification workflows, yes. Fixed delays can land messages at bad times (weekends, holidays, late nights). Business-hour-aware delays ensure messages arrive when recipients are likely to engage.

What's the longest delay I should use?

Some platforms support delays of months or even years (renewal-reminder workflows often use multi-month delays). Practically, very long delays risk workflow staleness — by the time the delay fires, the original trigger may be irrelevant. Add validation logic that confirms the delay's context is still valid before firing the next step.

Can delays be conditional?

Yes — many platforms support 'wait until condition' steps that pause until a specific condition is met (e.g., wait until lead score exceeds 50, wait until lifecycle stage changes to 'customer'). This is distinct from fixed-duration delays.

How do delays interact with timezone?

Naive delays use server time; sophisticated delays support recipient time zones. For email and notification workflows targeting users in multiple time zones, recipient-time-zone delays produce much better engagement than server-time delays.

What happens to enrolled contacts during a long delay?

They wait — the contact stays enrolled in the workflow at the delay step, and the next step fires when the delay expires. If you need contacts to exit the workflow during the delay (e.g., they upgraded to paid mid-trial), use exit criteria configured at the workflow level.

The AMW Suite