Event-time wait vs condition wait: wake at a timestamp in the trigger vs wake when something happens

Event-time wait advances when the wall clock reaches (or passes) a timestamp carried on the triggering event (for example appointment_time minus one day). Condition wait advances when the person later matches attributes, fires another event, or joins a segment—optionally with a max-time path so they never park forever.

What is the difference between event-time wait and condition wait?

Both are waits, but the wake-up source differs:

• Event-time wait: clock-based. The enrollment event carries appointment_at; you configure “SMS 1 day before appointment_at.” The engine sleeps until that instant.
• Condition wait: state/behavior-based. “Until invoice_paid,” “until VIP segment,” or “until purchase event”—with or without a cap.

This is not the same question as wait until event vs fixed delay—that contrasts a future signal vs a fixed duration from now. Here the signal can be a timestamp already on the trigger, not necessarily a new post-entry event.

Also do not confuse it with date-property flow vs metric-triggered flow: that is about what starts a flow; this is a mid-journey wait step.

How does each mode work?

Event-time wait

1. Person enrolls with an event that includes a timestamp (appointment_at, class_starts_at, remind_at).
2. The wait applies an offset (−24h, −2h, or exact time).
3. When the clock hits (or if they booked late and the moment already passed—send now / skip / short path per your rule), they advance.

Condition wait

1. Person enters the step.
2. The engine waits for a later condition: next event, property change, segment join.
3. With a time cap you also get a “not met” path—see wait-until-conditions time-capped vs indefinite.

Concrete Iran examples

Clinic — appointment reminder

Event-time: enroll on appointment_booked; wait until appointment_at − 1 day; SMS via Kavenegar/Nikaline. If someone books for tomorrow while offset is “2 days before,” you need an explicit late-booking rule.

Condition: after the visit, wait until payment_completed or “complete file” segment before the satisfaction ask.

Online education — class start

Event-time on session_starts_at − 2h. Condition on lesson_1_completed before unlocking lesson 2 messaging.

Ecommerce — scheduled delivery slot

Event-time on delivery_slot_start − 3h. Condition on order_delivered before review request.

When to choose which

1. Calendar moment already on the event → Event-time.
2. Must wait for the user to do something → Condition (cap when needed).
3. QA late bookings—most reminder bugs live there.
4. Keep quiet hours separate from Event-time; appointment clock ≠ permission to SMS at 1am.
5. Live Chat stays human for reschedules; AI Chat is an internal team assistant only.

Leadara mapping

• Events: store appointment_at / remind_at on the enrollment event.
• Journeys: wait until clock for SMS/email; separate wait until payment/segment conditions.
• Email / SMS: reminder copy from appointment properties; condition-path copy from current state.
• Segments: make VIP / complete-file conditions explicit.
• Do not invent connectors—SMS goes through the user’s provider (Kavenegar/Nikaline).

Common mistakes

• “2 days before” offset with tomorrow bookings and no edge rule.
• Treating Event-time as “fixed 24h after entry.”
• Indefinite Condition waits for payment with no cap.
• Assuming already-true conditions always skip—test it.
• Mixing profile birthday anniversary flows with appointment timestamps on events.

One-line takeaway

Event-time = wake when the clock hits a timestamp on the trigger; Condition = wake when something becomes true later.

Next step

Open one live appointment reminder. Ask: calendar-on-event or later user action? Model them separately in Leadara and test the late-booking edge.

FAQ

What if the appointment is sooner than the wait offset?

Document send-now, skip, or short-path. Without a rule, support gets surprised.

Can event-time wait use a different event than the trigger?

Some products only read the enrollment timestamp; others allow another field. In Leadara, wait on properties you actually store.

Do people who already meet a condition skip the wait?

Often yes at wait entry—verify with a test profile.

How do quiet hours interact with event-time?

Separately. The appointment instant can land inside quiet hours; add shift or hold rules.

Birthday / purchase anniversary — which wait?

If the date lives on a profile property, that is closer to a date-property flow than mid-journey Event-time.

Do I need a cap on Event-time?

Less than on Condition; the “already past” edge matters more than a TTL.

Is appointment SMS transactional or promotional?

Usually operational/transactional—do not blindly apply promo frequency caps.

Step-by-step for growth

1. Name the time field (appointment_at).
2. Lock the offset with product (−1 day, −2 hours).
3. Write the late-booking edge rule.
4. Keep payment/attendance as separate Condition waits.
5. Build in Leadara; test tomorrow, next-week, and already-past appointments.
6. Watch delivery, no-show, and late-edge share for two weeks.

Metrics to watch

• Reminder SMS delivery rate
• No-show after reminder
• Late-booking edge path share
• Time-in-condition-wait and expired share

PM reporting language

Say “−24h reminder: 82% delivered, no-show 18%→11%,” not “we automated appointments.”

Programmer-shaped sketch

enter event_time_wait(ts_field, offset):
  target = event[ts_field] + offset
  if now >= target: advance(due); return
  sleep_until(target); advance(due)

enter condition_wait(cond, cap=None):
  loop:
    if cond(profile): advance(met); return
    if cap and expired: advance(expired); return

Acceptance tests before publish

1. Appointment in 7 days + −1 day offset → message ~24h before.
2. Appointment tomorrow + −2 day offset → documented edge path.
3. Payment Condition with 48h cap → met or expired.
4. Quiet hours block or shift midnight SMS.
5. Human Live Chat for reschedule; AI Chat remains internal-only.

Channel checklist

• Reminder SMS: short, clear date/time
• Condition email: do not repeat SMS if SMS is enough
• Web push only if the user is actually reachable there

Designing late-booking without spamming

When the target time is already past or too soon, prefer a single short confirmation (“نوبت شما فرداست”) over sending the full −2-day nurture sequence compressed into one minute. Ops should see a distinct edge metric so product can shorten default offsets later.

Interaction with exits and goals

If the user cancels the appointment, a global exit or conversion-style exit should clear both Event-time and Condition waits. Otherwise you will SMS reminders for cancelled slots—the classic support ticket.

Ops one-pager

Paste into the journey ticket:

• time field = …
• offset = …
• late edge = send-now | skip | short-path
• condition waits after = …
• quiet hours policy = …
• channels = SMS/email

Designing late-booking without spamming

When the target is already past or too soon, prefer one short confirmation over compressing a full −2-day nurture into a minute. Track the edge path as its own metric so product can shorten default offsets later.

Interaction with exits and goals

If the user cancels the appointment, a global exit should clear both Event-time and Condition waits. Otherwise you SMS reminders for cancelled slots.

Versus waiting for a brand-new event

Wait-for-new-event listens for a post-entry fire. Event-time may need no new event—only the clock on the trigger. If the brief says “wait for event” but means a timestamp, you will build the wrong step.

Clinic ops checklist

• Is the time field named consistently in webhook/SDK?
• Was the offset tested in Asia/Tehran?
• Does cancel wire into an exit?
• Does SMS show the date clearly without inventing product features?
• After the reminder, do you have a separate Condition for attended vs no-show?

SaaS renewal vignette

Event-time on renews_at − 3 days for card reminder email. Condition on card_updated before “renewed” creative. If you only use Condition and ignore renews_at, everyone wakes on a blunt fixed delay and you miss the renewal edge.

Extra FAQ detail for PMs

Ask engineering one question before launch: “If appointment_at is 18 hours from now and offset is −24 hours, what exact branch runs?” Write the answer in the journey ticket. That single sentence prevents half of reminder incidents.

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
• Date-property flow vs metric-triggered flow: calendar anniversary vs live behavior event