Wait until a date property vs relative duration: birthday/renewal day vs 'wait 3 days'

Date-property waits align the next action to a stored calendar/datetime field (on the date, N before, or N after, with optional time-of-day and an unknown-date branch); relative-duration waits pause everyone for the same N days/hours regardless of personal dates.

What is wait-until-date-property vs relative duration?

Two wait tools that teams constantly mix up:

1. Wait until date property: e.g. birthday, subscription_ends_at, policy_renewal_date. The engine waits for “the day of,” N days before, or N days after—sometimes with a time-of-day. Empty fields need an unknown branch.
2. Relative duration: “wait 3 days” after purchase or after an email. Same for everyone; ignores personal calendars.

Classic question: “Birthday email or the same 3-day drip?” Birthday = date property; post-purchase drip = relative.

Related but different: date-property flow vs metric-triggered flow—that’s the whole flow trigger; here it’s a Wait step inside a journey.

On / Before / After table

Don’t confuse relative waits with business-days-only—that’s closer to delay-until-weekday vs fixed N-days. For live signal vs fixed clock see wait until event vs fixed delay.

Iranian insurance & subscription example

Insurance / SaaS subscription: profile field renewal_date.

• 7 days before: “renewal is coming” email;
• 1 day before: Kavenegar reminder SMS;
• Day after successful renewal: thanks message;
• If renewal_date empty: go to “complete your date” branch—never wait forever.

Store: after purchase, relative wait 3 days → review ask; customer birthday stays on a separate date-property journey.

If the user changes birthday while waiting, some engines reschedule and some freeze the time captured at entry—document this in QA.

Truthful Leadara mapping

With Leadara profile/segments, journeys, and email/SMS you can design calendar waits (renewal, birthday) and relative waits after purchase events. Always define the empty-date branch. Leadara AI Chat is an internal team assistant, not a customer live-chat bot. Don’t invent WhatsApp.

When to choose which

Practical steps

1. Standardize the date field (name, timezone, format);
2. Define the empty-field branch;
3. Write On/Before/After + Tehran send time;
4. Test changing the date mid-wait;
5. Keep relative drips separate from calendar campaigns in reporting;
6. Exit on successful renewal so reminders stop;
7. After month one, report empty-date rate.

Common mistakes

• “Birthday” as a fixed 3-day delay from segment entry (everyone gets the same day);
• No unknown branch;
• Assuming birthday edits always reschedule;
• Mixing business-days with date-property waits;
• One journey mixing relative + birthday without separate metrics.

Growth-team walkthrough

1. Segment “active sub with renewal_date filled”;
2. Enter 30 days before renewal (or wait-until before 7 days if that’s your wait model);
3. Value email;
4. SMS 1 day before;
5. If renewed → exit;
6. If not → relative wait 2 days + last offer;
7. End or human follow-up segment.

FAQ

What if the date property is empty?

You need an unknown branch: ask to complete, exit, or default path. Infinite wait is forbidden.

Does changing birthday while waiting reschedule the send?

Platform-specific. Build two profiles—one stable, one edited—and write the behavior into the runbook.

When should I use business-days-only instead?

When support only answers on business days or you must avoid Friday-night sends—not as a substitute for birthday date properties.

How is timezone frozen?

Some engines lock timezone at delay entry. Test traveling contacts.

Can I stack relative and date waits?

Yes: e.g. 3-day relative after purchase, plus a separate annual birthday journey on date property.

Loan installment reminders?

Date property due date + Before N; relative only for follow-up after a missed-payment event.

What time for birthday SMS?

On date with time-of-day (e.g. 10:00 Tehran) beats midnight—respect quiet hours.

Leadership summary?

“Birthdays and renewals bind to date fields; purchase drips use relative delay. Empty dates get their own branch.”

Next step

Clean one renewal_date or birthday field, add an unknown branch, and ship an On/Before journey separately from your post-purchase relative drip.

Data cleanup before calendar journeys

Before waiting on birthday or renewal_date:

1. Measure empty-date rate;
2. Normalize formats (string vs timestamp, Jalali vs Gregorian);
3. Filter absurd dates;
4. Document default Tehran timezone;
5. Name the data owner (support vs payment gateway).

Without cleanup, calendar journeys create support tickets faster than revenue.

Two journeys, two dashboards

Keep birthday/renewal journeys separate from post-purchase relative drips so metrics don’t smear. Weekly report: Calendar waits vs Relative drips.

Sample Kavenegar copy

• Before 3 days: “Your plan ends in three days—renew here…”
• On birthday: “Happy birthday—a small gift is in your account”
• Relative +3 after purchase: “If you liked the order, leave us one line”

Align send time with quiet hours; midnight birthday texts feel wrong.

Related reading

• Date-property flow vs metric-triggered flow: calendar anniversary vs live behavior event
• Delay-until-weekday vs fixed N-days: send only Mon/Wed/Fri vs always wait exactly 2×24h
• Wait until event vs fixed delay: pause for a signal vs pause for a clock