# Waits The five wait steps of a flow, what each one waits for, its range and the exits it can take. **Language:** en **Audience:** platform **TLDR:** Flows have five waits: Fixed delay (exact time, 1 minute to 90 days), Timezone delay and Smart delay (an allowed or best hour in the contact's time zone, window up to 14 days, with Wait complete / Unable to wait exits), Wait for delivery (up to 48 hours, Delivered / Not delivered) and Wait for activity (a click, reply or event within a time limit, else No interaction). Waits end approximately on time, within about a minute. **Translation key:** platform.automations.flows.waits **Search keywords:** delay, wait time, quiet hours, send window, best time to send, send time optimization, legal hours, wait for click, wait for reply, timeout **Related pages:** /platform/es/automations/flows/waits, /platform/en/automations/flows, /platform/en/automations/flows/sending-messages, /platform/en/automations/flows/branches, /platform/en/automations/flows/goals-and-exits, /platform/en/automations/flows/limits-and-safeguards **Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt **This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/llms.txt **This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/waits/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/waits.md (Markdown) **Other language (es):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/waits.md Waits decide **when** things happen in a flow. A contact who reaches a wait stays on that step until the wait resolves, and only then moves on to the next step — so a wait is how you leave a day between two messages, keep a message out of the night, send it at the moment each person is most likely to read it, or react to what the contact did with the message they just received. Each contact waits on their own clock: two contacts who entered a minute apart, or who live in different time zones, can leave the same wait at very different moments. The five waits live in the **Wait** group of the step palette. Three of them wait for a **time**: **Fixed delay** counts an exact amount of time, **Timezone delay** waits for an hour you allow in the contact's time zone, and **Smart delay** waits for the hour that contact is most likely to engage. The other two wait for **something to happen**: **Wait for delivery** waits for the delivery report of the message just sent, and **Wait for activity** waits for a click, a reply, an event or an opt-out. Every wait except the Fixed delay splits the flow into outputs, so you decide what each group of contacts does next. ## How waits behave ### Which wait to use | You want to… | Step | Range | Outputs | | ----------------------------------------------------------------------------- | --------------------- | ------------------------- | ----------------------------------------------------------------- | | Leave an exact gap between two steps | **Fixed delay** | 1 minute to 90 days | One: the flow simply continues | | Send only at the hours and on the days you allow, in each contact's time zone | **Timezone delay** | A window of up to 14 days | **Wait complete** · **Unable to wait** | | Send at the moment each contact is most likely to engage | **Smart delay** | A window of up to 14 days | **Wait complete** · **Unable to wait** | | Act on whether the last message was delivered | **Wait for delivery** | Up to 48 hours | **Delivered** · **Not delivered** (optionally **Unable to send**) | | React to a click, a tap, a reply, an event or an opt-out | **Wait for activity** | 1 minute to 90 days | Your branches · **No interaction** | A rule of thumb: put a **Smart delay** (or a **Timezone delay**) right before every marketing message, including the first one; use a **Fixed delay** when the exact gap is what matters; and follow a message with **Wait for activity** or **Wait for delivery** when the next step depends on how the contact responded. ### Durations and precision Durations are set on a slider with fixed stops — minutes at the short end, then hours, then days — rather than typed in. The **Fixed delay** and the time limit of a **Wait for activity** go from **1 minute** to **90 days**. The windows of the **Timezone delay** and the **Smart delay** work differently: their start can be **Right away** and their end goes from 8 hours to 14 days (see each step below). One minute is the minimum. If a step ever holds a shorter wait, its settings show "This wait is shorter than 1 minute, the minimum.": the flow can still be saved as a draft, but it can't be published until you fix it (see [Building a flow](/platform/en/automations/flows/building-a-flow) for how the panel lists what blocks publishing). Waits end **approximately** on time: a wait finishes at its due time or up to about a minute later, plus the usual processing time. That is why the canvas shows durations with a "\~". Don't build a flow that depends on to-the-second timing. ### How consecutive waits add up - **Fixed delays in a row add up.** A Fixed delay of 1 hour, a message, then a Fixed delay of 1 day sends the second message about 25 hours after the contact entered. - **Fixed delays count from the event that started the flow.** The short processing time before a contact enters is absorbed by the first Fixed delay, not added to it: a 1-hour delay right after the trigger fires about an hour after the event. Entry timing is explained in [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry). - **A Fixed delay after a wait with its own clock counts from when that wait ended.** The Timezone delay, the Smart delay, Wait for delivery and Wait for activity end at a moment nobody can know in advance: when the chosen hour comes, when the delivery report or the click arrives, or when their time runs out. A Fixed delay placed after one of them starts counting at that moment. For example, "remind them if they don't click": a message with a link, then a **Wait for activity** of 3 days whose **No interaction** output leads to a **Fixed delay** of 1 day and a reminder. A contact who never clicks gets the reminder on **day 4** — three days of waiting for the click, then one more day. ### What can end a wait early A contact doesn't always stay until the wait resolves: - **An exit event ends any wait.** If the contact does one of the flow's exit events (for example, places the order the flow was reminding them about), the run ends within seconds, wherever the contact is waiting. See [Goals and exits](/platform/en/automations/flows/goals-and-exits). - **Cancelling ends any wait.** **Cancel executions** stops everyone inside a version, and **Cancel execution** stops a single contact. See [Managing flows](/platform/en/automations/flows/managing-flows). - **Pausing doesn't.** **Pause enrollment** — the same action as **Disable** in the flows list — stops new contacts from entering, but contacts already waiting carry on and finish their journey. Publishing a new version doesn't move them either: they finish on the version they entered. - **Test runs can skip time.** In a test run, **Auto-skip waits** skips the waits that count time, while waits that listen for something (delivery, activity) keep waiting until you press **Skip** on the step. See [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing). ### There are no quiet hours on messages A **Send message** step sends as soon as a contact reaches it, at whatever hour that is. Flows have no project-wide quiet hours and no sending window on the message itself: the way to keep messages out of the night is to place a **Timezone delay** or a **Smart delay** right before the send. A **Fixed delay** doesn't avoid night hours — a contact who enters at 23:00 and waits exactly 1 day reaches the next step at 23:00 the following day. ### Duration and cost Each wait adds its longest possible length to the flow's longest path, which can't exceed 180 days; [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards) covers that ceiling and the other flow-wide limits. Waiting itself costs nothing: a contact can sit on a wait for weeks without any charge. Only the messages a flow sends are charged (see [Sending messages](/platform/en/automations/flows/sending-messages)). ## Fixed delay A **Fixed delay** holds the contact for exactly the time you set and then continues. It has one output and no options beyond the duration: no time zone, no allowed hours. - `Wait` — default: `1 day` How long to hold each contact, from 1 minute to 90 days. The panel describes it as "Waits exactly this long, then continues. From 1 minute to 90 days." Use it when the gap itself is the point: a follow-up one day after a first message, a second reminder a week later, or a pause of a few minutes between two steps. Because it ignores the clock, a Fixed delay placed right before a marketing message can deliver that message in the middle of the night. When the hour matters, use a Fixed delay to cover the bulk of the time and put a **Timezone delay** or **Smart delay** after it for the final stretch. ## Timezone delay A **Timezone delay** holds each contact until the **first allowed hour in their own time zone**, inside a window you set. It uses the contact's time zone when their profile has one, and the project's time zone otherwise. The result is the same for everyone in the same place: a message that respects your business hours wherever each contact lives. - `Wait window` — default: `Right away → 3 days` How long each contact can be held before the flow continues, set with two handles. **As early as** is the minimum: the wait never resolves before it; at **Right away** the contact goes on as soon as an allowed hour is reached (at once, if the current hour is already allowed). It goes from Right away to 14 days. **As late as** is the end of the window: from 8 hours to 14 days, and always later than As early as. If the window isn't valid, the error under it calls them "the earliest" and "the latest". - `Allowed hours` — default: `All` The hours of the day, in the contact's local time, when the wait may end. **All** allows every hour; **Daytime** allows 9:00 to 22:59; **Custom** opens a grid of the 24 hours so you can pick your own. - `Allowed days` — default: `All` The days of the contact's week when the wait may end. **All**, **Weekdays** (Monday to Friday) or **Custom** to pick individual days. The step splits in two: - **Wait complete** — an allowed hour was found inside the window and the wait ended there. This is where the message goes. - **Unable to wait** — no allowed hour fits the window. The contact leaves through this output **at once**, without waiting, and the run carries on: you decide what happens next — send anyway, skip the message, or end the flow for that contact with **Exit flow**. An illustration of how the window and the hours combine, with **Allowed hours** set to **Daytime**: a contact who enters at 23:30 with a window of **Right away** to **3 days** is held until the allowed hours begin the next morning and leaves through **Wait complete**. With the same hours but **As late as** set to **8 hours**, the window ends at 7:30, before any allowed hour, so that contact leaves through **Unable to wait** straight away. Place the message **inside** the **Wait complete** branch, not below the point where the two outputs join again: whatever sits below the split runs for contacts of both outputs, including those who couldn't wait (how branches rejoin is explained in [Building a flow](/platform/en/automations/flows/building-a-flow)). For waits longer than 14 days — a win-back message a month after the last order, for instance — put a **Fixed delay** first and the Timezone delay after it. ## Smart delay A **Smart delay** holds each contact and sends at the moment **that person is most likely to engage**, in their own time zone and within the window, hours and days you allow. It is what the industry calls *send-time optimization*; in the panel it is the **Smart delay**. Two contacts who enter at the same time can receive the message hours apart, each at the moment that suits them best. Place it **right before a send**. It works on top of the Timezone delay: same **Wait window**, **Allowed hours** and **Allowed days**, and the same two outputs, **Wait complete** and **Unable to wait**. Its window starts at **5 minutes** by default, so a message doesn't arrive in the same instant as the event that triggered it (you can move it to **Right away**), and ends at **3 days**. ### How the moment is chosen Every allowed hour inside the window is a candidate. If **Follow marketing time-of-day laws** is on, the hours that aren't legally allowed for marketing in the contact's country are removed first. Each remaining hour is then scored with the signals of the selected **Ranking strategy** — when this contact usually buys or interacts, when your store sells most — and later hours lose appeal according to the **Timing preference**. The hour with the best score wins, and the contact leaves through **Wait complete** at that moment. - `Follow marketing time-of-day laws` — default: `On` Skips the hours when the law of the contact's country doesn't allow marketing messages. It only blocks what is actually not allowed, in the few countries with such rules, and applies no restriction when the contact's country isn't known. It doesn't replace your **Allowed hours** and **Allowed days**. Use it in marketing flows only; turn it off for transactional messages such as an order confirmation. - `Timing preference` — default: `Balanced` How fast a later hour loses appeal, on a five-stop scale: **Best time** (waits for the top-scored hour anywhere in the window), **Relaxed**, **Balanced**, **Soon** and **ASAP** (nearer hours win). A cart reminder usually wants **Soon** or **ASAP**; a win-back message can afford **Balanced** or **Relaxed**. - `Ranking strategy` — default: `Recommended` The mix of signals used to score each hour. **Recommended** is a balanced mix and a good starting point for most flows. **Purchase intent** leans on purchase and checkout signals. **Engagement** leans on when each contact interacts. **Custom (advanced)** lets you set the weight of each signal by hand. - `Business signals` Your business patterns: **Industry best practices** (curated send times for your industry, country and season, which work even before your store has data), **Sales peaks** (the hours your store sells most, for the contact's country) and **Checkout peaks** (the hours your store reaches checkout most). - `Contact signals` The contact's own history: **Purchases**, **Checkouts** and **Interactions** (clicks, taps and replies). A contact with no history isn't affected by them. In **Custom (advanced)**, each signal has a weight from **Off** through **Low**, **Medium**, **High** and **Very high** to **Max**. With every signal **Off**, the step sends at the earliest allowed hour of the window. A configuration that matches none of the ready-made mixes opens as **Custom (advanced)**. ![Smart delay settings with wait window, allowed hours and days, timing preference and ranking strategy](/platform/en/automations/flows/images/waits--1-smart-delay.png) The narrower the window and the allowed hours, the fewer candidate hours there are, and the more contacts leave through **Unable to wait**. If that output is busier than you expected, widen the window (a later **As late as**) before you remove allowed hours. As with the Timezone delay, put the message inside **Wait complete**: a message below the point where the outputs rejoin also goes to contacts who couldn't wait, at whatever hour they reach it. For example, a welcome flow: when a contact is created, a **Smart delay** with a window of **5 minutes** to **8 hours** and the **Recommended** strategy, and the welcome SMS inside **Wait complete**. Each new contact gets the message within eight hours of signing up, at the moment they are most likely to read it. An abandoned-cart flow works the same way with a window of 5 minutes to 8 hours, **Purchase intent** and **ASAP**, so the reminder arrives while the purchase is still fresh. ## Wait for delivery A **Wait for delivery** holds the contact until the message the run just sent has a delivery result, and then splits on that result. Place it **right after a Send message step**: it attaches by itself to the last message this run sent, with nothing to pick. It resolves as soon as the delivery report arrives, or as soon as the contact clicks, taps or replies to the message — an interaction proves delivery, so it counts as **Delivered** right away. If there is no delivery confirmation within **48 hours**, the contact leaves through **Not delivered**. If the message already had its final result when the contact reached the step, they go on at once. When an RCS message is replaced by its SMS fallback, the step follows the message that actually went out and decides on its delivery. - `Outputs` — default: `Delivered or not` **Delivered or not** gives two branches, **Delivered** (the message reached the contact, or they interacted with it) and **Not delivered** (no delivery confirmation within 48 hours). **Split by delivery channel** gives one **Delivered** branch per channel you want to handle — **Delivered · SMS**, **Delivered · RCS** and **Any other channel**, each once, at least one — plus **Not delivered**. Each delivery takes its channel's branch; the order doesn't matter. - `Separate output when the message couldn't be sent` — default: `Off` Adds an **Unable to send** output for contacts whose message never went out: no phone, no consent, or the channel is blocked or not set up. Off, those contacts leave through **Not delivered** together with the undelivered ones. When you split by channel, give a branch to every channel the message can be delivered through — for an RCS message with SMS fallback, that means RCS and SMS — or add **Any other channel**. A delivery through a channel with no branch of its own has nowhere to go, and the run stops there. If no message was sent before the step — there is no Send message above it, or the send was skipped — the contact leaves through **Unable to send** when that output is on, and through **Not delivered** otherwise. A Send message step set to stop the run when the message can't be sent ends the run there, so those contacts never reach the wait (see [Sending messages](/platform/en/automations/flows/sending-messages)). Typical uses: try another channel or sender when the result is **Not delivered**, or count the flow's goal only for contacts whose message was delivered, with **Goal reached** inside the **Delivered** branch (see [Goals and exits](/platform/en/automations/flows/goals-and-exits)). **Not delivered** means the network never confirmed delivery; it says nothing about whether the contact read the message. ## Wait for activity A **Wait for activity** holds the contact until they **react to the message just sent** — a tap, a click or a reply — or **do an event**, such as placing an order, and then sends them down a branch according to what they did. If nothing happens in time, they continue through **No interaction**. It turns a flow into a conversation: offer something, and follow up differently with those who clicked, those who answered and those who stayed silent. ### How long to wait - `How long to wait` — default: `3 days` The time limit, from 1 minute to 90 days, counted from the moment the contact reaches the step. If nothing matches in this time, the contact takes **No interaction**. ### How the branches are checked The branches come in two groups, **Specific branches** first and **Fallback branches** after them. They are checked in order, top to bottom, and **the first one that matches wins**. The first reaction that matches a branch resolves the wait; anything the contact does afterwards doesn't change the branch they took. A step holds up to **10 branches** in total, plus **No interaction**, which is always last. Reordering and renaming branches works as in every split step (see [Branches](/platform/en/automations/flows/branches)); name them after what they catch, because the contact journey doesn't show which branch was taken. A new Wait for activity comes with one fallback branch, **Any link click**, and **No interaction**. Mind the order when you add more: a fallback branch is checked after every specific branch, but it still wins against a specific branch that hasn't matched **yet**. If the message has a link and you wait for a purchase, a contact who clicks first goes down **Any link click** before the purchase can be checked — remove that branch if you don't need it. ![Wait for activity settings with a specific branch and the No interaction branch](/platform/en/automations/flows/images/waits--2-activity-wait.png) *Branches are checked top to bottom; the first match wins.* ### Specific branches A specific branch matches a concrete reaction. It holds one or more conditions, added with **Add condition**, and **any** of them is enough for the branch to match. A branch with no condition can't match and blocks publishing. - **Tapped a specific element** — a tap or click on a link or button of the message that carries an **interaction tag**. You choose from the tags of the previous message; tags are added on links and buttons in the message editor. Only **saved** tags appear: after tagging a link, save the draft, or the list shows "The previous message has no interaction tags. Add one to a link or button in the message and save: saved tags show up here." - **Replied with text** — a reply that matches one of your patterns. Matching ignores upper and lower case and leading or trailing spaces, and compares the **whole** reply, so the pattern `yes` doesn't match "yes please". Patterns support `?` for an optional character (`opt?in` matches "optin", "opt in" and "opt-in"), `@` for up to 4 characters (`stop@now` matches "stop now" and "stopall now") and `*` for any text (`yes*` matches "yes" and "yes please"). Tick **Ignore accents when matching** so that "si" and "sí" count as the same answer. - **Did an event** — a behavioural event, such as an order or a checkout, not tied to the message. Choose the event, optional conditions on its data and a **specific data source**: with **Any data source**, which comes preselected, the branch shows an error that doesn't say which field is missing, and the flow can't be published. Only events that happen after the contact reached the wait count. - **Unsubscribed** — the contact opted out through STOP, an opt-out link or your API. Pick **Any** (recommended: covers both an opt-out and a block), **Opt-out** (they refused marketing and can still receive transactional messages) or **Blocked** (a full opt-out: nothing more can be sent to them on that channel). The difference between the two is explained in [How consent works](/platform/en/consent/marketing-preference-vs-suppression). #### Technical details **Which opt-outs the Unsubscribed branch sees.** The branch fires when the opt-out arrives through STOP or an opt-out keyword in a reply, an opt-out link or button in a message, the subscriptions API, or a **Manage subscription** step in a flow. It does **not** see RCS agent blocks, spam complaints, or opt-outs made by hand in the panel or uploaded by CSV: those routes don't produce the event the branch listens for. With **Opt-out** selected, a contact who was already opted out and asks again arrives as a block, so the branch misses them — that's why **Any** is the recommended choice. How opt-outs work in general is explained in [Opt-outs & reactivation](/platform/en/consent/opt-outs-reactivation). ### Fallback branches A fallback branch matches **any** reaction of a kind, whatever the element. They are optional, each type can be added once, and they are always checked after the specific branches: - **Any link click** — any click on a link of the message just sent. - **Any action tap** — any tap on an action button (call, calendar, location, copy). - **Any reply** — any text reply to the message just sent. A STOP is also a reply: if the step has **Any reply** and no **Unsubscribed** branch, a contact who answers STOP goes down **Any reply**. Add an **Unsubscribed** branch when those contacts need a path of their own. Either way, their opt-out is recorded and respected by later sends. ### No interaction **No interaction** is taken when the time limit runs out with no match. It can't be removed and is always the last output. It is also where everyone ends up when nothing could have matched — for example, when the only branches react to a message and no message was sent. ### Reactions belong to the message just sent Taps, clicks and replies count only when they answer **the message this run sent most recently**: a reply to a campaign or to another flow doesn't resolve the wait. So a Send message must come before the Wait for activity for those conditions to ever match. A reaction that arrives between the send and the moment the contact reaches the wait still counts. **Did an event** and **Unsubscribed** are the exception: they aren't tied to the message. If an RCS message is delivered as its SMS fallback, the contact receives a text without buttons, so conditions on tapped buttons and action taps can't happen. To catch the same answer on both channels, put the button's interaction tag **and** a text-reply pattern (for example `yes`) in the same branch — any one of them is enough. ### Example: congratulate those who buy, remind those who don't A message about a product the contact viewed, then a **Wait for activity** of 2 days: - **Branch 1**, renamed "Bought": **Did an event** "Order created", with your store as the data source → a thank-you message. - The **Any link click** fallback branch removed, so that a click doesn't take the wait before the purchase can be checked. - **No interaction** → a reminder. The order resolves the wait within seconds, with or without a click; whoever doesn't buy gets the reminder when the two days run out. One caveat: if "Order created" is also one of the flow's exit events, the exit wins — the contact leaves the flow the moment they buy, and "Bought" never runs. Use the event in one place or the other, depending on whether buyers should get a thank-you from this flow (see [Goals and exits](/platform/en/automations/flows/goals-and-exits)). ## Related - [Sending messages](/platform/en/automations/flows/sending-messages) - The Send message step, its sender, consent policy and what happens when a message can't be sent. - [Branches](/platform/en/automations/flows/branches) - Split steps that route contacts by tag, list, segment, contact field, event, consent or an A/B split. - [Goals and exits](/platform/en/automations/flows/goals-and-exits) - What counts as success and the ways a contact leaves a flow before the end. - [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards) - Flow duration, size and the other limits that apply to every flow. --- This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.