Delays and follow-ups in a WhatsApp flow

A delay is a step that pauses a flow for a set number of minutes and then carries on. It is the difference between a bot that fires everything at once and one that behaves like a person who knows when to leave someone alone.

Three blocks in the builder involve waiting, and they do genuinely different things. Mixing them up is the most common reason a follow-up either never sends or sends to everybody including the people who already replied.

The three waiting blocks

Block	What it does	Use it for
Wait Before Next Step	Pauses this run for a number of minutes, then continues	Spacing out messages; waiting before a reminder
Has the Customer Replied?	Branches yes or no on whether anything came in since the flow started	Only chasing the people who went quiet
Pause Before Repeating	Stops the same flow running again for this customer within a set window	Preventing a keyword flow firing five times in a row

Only the first one is a delay in the everyday sense. The second is a question about what happened while you waited, and the third is a rule about how often the whole automation is allowed to run at all.

The pattern that makes follow-ups work

A follow-up that chases everyone is worse than no follow-up, because half the recipients already answered and now think you are not reading. The fix is always the same two blocks in the same order:

Put the delay before the check, never after. The check asks whether anything arrived since the flow started, so it is only meaningful once you have given the customer time to arrive.

The rule that decides whether your follow-up can send at all

This is the part that catches people out. WhatsApp lets you send free-form messages only inside the 24-hour customer service window, which opens when a customer messages or calls you and resets each time they do, per Meta's sending messages documentation. Outside it, you need an approved template.

So the delay length quietly decides what your next message is allowed to be:

1. Under 24 hours from their last message — a plain message works, and it costs nothing under Meta's pricing documentation, because service conversations have been free and unlimited since 1 November 2024.
2. Over 24 hours — the plain message silently fails to reach them. You need a template, and a template is billed.

A one-hour reminder is therefore free and easy. A two-day reminder is a template you must get approved first. Design the flow knowing which one you are building rather than discovering it when the run fails.

Choosing a delay length

There is no universally correct number, and anyone who quotes you one is guessing. What there is, is a sensible way to reason about it:

• Minutes for anything conversational — spacing two messages so they do not arrive as a wall of text.
• Under an hour for a nudge in an ongoing conversation, where the customer still remembers what you asked.
• Several hours for a cart or checkout reminder, where you are catching someone who got distracted.
• A day or more only when you have a template, and only when the message would still be welcome.

Whatever you pick, write it down somewhere and change one variable at a time. Two automations with two different delays teach you nothing if you also changed the wording.

Stacking delays

You can chain several delay-and-check pairs to build a two or three step chase. It works, and it is a good way to make a flow feel patient rather than pushy. Two cautions:

First, each run is holding its place in the flow for the whole waiting period, so a three-day chase is a run that lives for three days. If you edit and republish the automation in the meantime, be clear that in-flight runs are not something you should assume will behave exactly as the new version would.

Second, every extra step is another message to someone who has now ignored you twice. Two chases is usually the honest maximum, and the second should read differently from the first — an offer to help rather than a repeat of the same line.

Pause Before Repeating, and why every keyword flow needs it

The third block solves a different problem. Without it, a keyword-triggered flow runs every single time the keyword appears. A customer who writes "price" three times in a row while thinking out loud gets three identical replies.

Pause Before Repeating sets a minimum gap before the same flow will run again for the same person. Five minutes is enough to absorb a burst of messages; a longer window suits anything that sends something substantial.

It also protects your numbers. Your messaging tier limits how many unique recipients you can reach in a rolling 24 hours — the ladder runs 250 → 2,000 → 10,000 → 100,000 → unlimited per Meta's messaging limits documentation — and repeat sends to the same person are pure waste against your quality rating even when they do not count against that.

What there is no block for

Being straight about this saves you an hour of hunting: there is no "wait until Tuesday" or "wait until 9am" block. Waiting is expressed in minutes.

What you can do instead is combine a delay with a business-hours or time check downstream, so the flow waits a fixed period and then behaves differently depending on when it lands. That covers most of what people actually want, which is usually "do not message them at 3am" rather than a precise calendar time.

Testing a flow that waits

The obvious problem with testing a 24-hour delay is that it takes 24 hours. The workable approach:

1. Build the flow with a short delay — one or two minutes.
2. Run it on your own number and confirm both the yes and no branches by replying in one test and staying silent in the other.
3. Change the delay to the real value only once the shape is proven.
4. Do one full-length run before you let it loose on customers.

The full protocol is in testing a WhatsApp automation safely, and the branching mechanics are in branching a flow.

Frequently asked

Does a delay cost anything?

No. Waiting is free; only messages are billed, and only when a template reaches a chat outside the 24-hour window.

What happens if the customer replies during the delay?

The run keeps waiting. The Has the Customer Replied? block is what notices, which is exactly why it goes after the delay rather than being assumed.

Can I cancel a waiting run?

Turning the automation off stops it running for anyone new. For a specific conversation, the reliable way to stop the bot talking over a colleague is the agent-message pattern in handing a chat from bot to human.

How long can a delay be?

It is set in minutes, so long waits are possible. The practical ceiling is not technical — it is that anything beyond 24 hours needs a template under Meta's template rules, and anything beyond a few days is a message the customer has stopped expecting.

Where delays fit in the flows most stores build first

Three of the four highest-value ecommerce automations are really delay patterns wearing different clothes:

Flow	What the delay is for	Typical shape
Cart or checkout reminder	Giving the customer time to come back on their own	Wait, then check, then one message
Order confirmation chase	The customer opened the message but did not tap Confirm	Wait, then check, then one template
Review request	Waiting until the product has actually arrived and been used	Long wait, template only
Restock notice	Not a delay at all — an event you are waiting on	Separate trigger

The last row is the useful contrast. If you find yourself designing a very long delay, check whether what you are really waiting for is an event. Waiting three days to guess that stock has arrived is worse in every way than starting a flow when it actually does.

What a customer experiences during a delay

Nothing. There is no typing indicator, no "we will get back to you", no sign the conversation is still open. From their side the chat simply went quiet.

That is fine for a reminder and bad for a question. If a flow needs to look something up and the lookup takes a moment, say so before the pause — a single line that sets expectations costs nothing and stops people re-sending their message.

Delays and your team

A conversation sitting inside a delay still shows in the shared inbox as an open chat. Someone on your team may see it, decide it has been ignored, and reply by hand — at which point the customer is talking to two things at once.

Two habits prevent it. Set the conversation status deliberately so a waiting chat does not look abandoned, and add the agent-message rule described in stopping a flow cleanly, so a human reply switches the bot off.