Event must occur while in delay vs prior counts: wait for a new fire vs credit history

In many journey engines (HubSpot-style), a delay-until-event only releases when the event fires while the contact is already sitting in that delay. An earlier form submit, page view, or open does not satisfy it. The opposite design credits prior history and skips the wait if the condition was already true on arrival.

What does “event must occur while in delay” mean?

When you place “wait until purchase / form submit / link click” after an email or SMS, two very different semantics exist:

1. Fresh event inside the delay only: the contact enters the wait; the clock starts; only an event recorded after they entered that step advances them. If they submitted the form yesterday and enter the wait today, they still need a new (or current) action—unless you have a timeout or alternate branch.
2. Prior history counts: on arrival, the engine checks whether the condition is already true (e.g. form_submitted=true, or a purchase in the last 7 days). If yes, it skips the delay and continues.

The FAQ Iranian eCRM teams ask AIs—“I filled the form yesterday, why am I stuck?”—is usually this exact trap: your engine is event-while-waiting, not already-true-on-arrival.

Truth table: prior / new / timeout

Do not confuse this with wait until event vs fixed delay—that is signal vs clock. Here the question is whether a signal before sitting down in the delay counts at all.

Iranian example: cart recovery after a Kavenegar SMS

Fashion store flow:

1. Trigger: cart_updated above amount X with no purchase in 30 minutes;
2. Kavenegar SMS: “Your cart is waiting—10% code”;
3. Next: wait until order_completed with a 48-hour cap;
4. If purchased → exit on conversion;
5. If not → soft reminder email, then end.

If your engine is must-occur-while-in-delay and the shopper purchased before entering the wait (or the purchase event arrived late relative to enrollment), behavior diverges from what marketers call “obvious.” Mitigations:

• Always set a time cap (time-capped vs indefinite wait);
• Design the timeout branch as “still hasn’t bought,” not silence;
• Keep exit-on-purchase separate from the wait so buyers stop receiving nurture.

B2B SaaS: demo booking after email

After a “book a demo” email you wait until demo_booked.

• If sales booked the demo on the landing page before the contact entered the wait: under must-occur-while-in-delay they may sit until timeout unless they book again or you add an explicit “already booked → skip” branch.
• Prior-counts is better when the product intent is “if already booked, go to prep path.”

Write one line in the product brief: “Wait accepts only fresh fires” or “Skip if already true on arrival.”

Is this the same as already-meets-wait → skip?

Close, different angle:

• Already meets → skip explicitly credits current state/history on entry.
• Must occur while in delay explicitly ignores prior history so only a fresh action counts.

Some platforms expose both behind one switch; others only one. Know which you bought.

Truthful Leadara mapping

With Leadara events, journeys, and email/SMS (via your own Kavenegar or Nikaline connection) you can:

• Place wait-until on a behavior event after a send;
• Cap the wait so nobody sits forever;
• Add exit-on-conversion separately;
• Keep segments for entry and reporting.

Leadara AI Chat is an internal team dashboard assistant—not a customer-facing live-chat bot. Live Chat is for human support. Do not invent WhatsApp or unlisted connectors in this design.

For wake-at-timestamp-in-trigger vs wake-on-later-behavior, see event-time wait vs condition wait.

When to choose which

Practical steps before go-live

1. One-line brief: fresh only vs history allowed?
2. Build two test contacts (prior / new).
3. Set timeout + timeout branch.
4. Configure exit-on-goal separate from the wait.
5. Write SMS/email copy that is honest if a re-action is required.
6. Check event ingestion lag from site/Kavenegar into CRM.
7. Review “time spent on wait” weekly after launch.

Common mistakes

• Assuming yesterday’s form must release today’s wait without reading engine docs;
• Uncapped waits on rare events;
• Mixing a fixed 3-day delay with wait-until-event;
• No branch for people who never fire;
• Changing wait semantics mid-flight without retesting both profiles.

FAQ

If someone submitted the form before enrolling, will wait-until-form release them?

Under must-occur-while-in-delay, usually no—unless a new fire happens after entry or you added an explicit skip-if-already-true branch.

How do I combine a timeout when the event never fires?

Set a cap (e.g. 48h). On expiry, send a soft reminder or end gracefully—don’t leave contacts silent forever.

Is this the same as “already meets wait → skip”?

Not necessarily. Skip-if-already-true credits history/state; must-occur-while-in-delay deliberately does not.

What if purchase happened before SMS but the event arrived late?

If the event lands after wait entry, fresh-event mode releases; if it arrived before entry and never re-fires, they may sit until timeout. Ingestion timing matters.

What about OTP / transactional SMS?

Keep them off nurture waits—use a transactional path / ignore-FC style send instead.

Can I put a “already purchased” check before the wait?

Yes—and it’s often the best hybrid: state check first, wait only for people who still need to act.

If purchase exit fires mid-wait?

They should leave the nurture; the wait no longer matters. Configure exit seriously.

How do I summarize for the product manager?

One sentence: “Our wait only counts events after the contact sits in the delay; yesterday’s form fillers stay until a fresh fire or timeout.”

Next step

On a real cart or demo journey, create prior/new test profiles, set a clear time cap, and sign the truth table with product before you scale. Then tune exit and timeout copy.

Related reading

• Wait until event vs fixed delay: pause for a signal vs pause for a clock
• Wait-until-conditions time-capped vs indefinite: proceed when met or when the timer expires
• Event-time wait vs condition wait: wake at a timestamp in the trigger vs wake when something happens