صبر تا زمان داخل Event در برابر صبر تا برقراری شرط: بیدار شدن روی timestamp تریگر در برابر بیدار شدن با رفتار بعدی

صبر تا زمان داخل Event وقتی ساعت دیواری به timestamp ذخیره‌شده روی ایونت تریگر (یا offset آن) برسد مخاطب را جلو می‌برد؛ صبر تا شرط وقتی بعداً attribute، ایونت تازه، یا عضویت سگمنت برقرار شود—اختیاری با سقف زمانی تا برای همیشه پارک نشود.

صبر تا زمان Event و صبر تا شرط دقیقاً چه فرقی دارند؟

هر دو «صبر»اند، اما منبع بیدارشدن فرق دارد:

• Event-time wait: روی ساعت. مثلاً ایونت appointment_booked فیلد appointment_at دارد؛ می‌گویی «۱ روز قبل از appointment_at پیامک بفرست». موتور تا رسیدن آن لحظه صبر می‌کند.
• Condition wait: روی وضعیت/رفتار بعدی. «تا وقتی invoice_paid true شود» یا «تا وارد سگمنت VIP شود» یا «تا ایونت خرید بیاید»—با یا بدون سقف.

این همان صبر تا رویداد در برابر تأخیر ثابت نیست—آنجا سیگنال در برابر مدت ثابت از الان است. اینجا سیگنال می‌تواند timestamp داخل تریگر باشد، نه لزوماً ایونت تازه بعد از ورود.

نیز با فلو تاریخ پروفایل در برابر فلو رویداد رفتار قاطی نکن: آنجا تریگر ورود است؛ اینجا قدم صبر وسط جرنی است.

هر کدام چطور کار می‌کند؟

Event-time wait

1. مخاطب با ایونتی وارد می‌شود که timestamp دارد (appointment_at, class_starts_at, remind_at).
2. قدم صبر offset را اعمال می‌کند (مثلاً −۲۴ ساعت، −۲ ساعت، یا دقیقاً همان لحظه).
3. وقتی ساعت برسد (یا اگر دیر رزرو کرده و لحظه گذشته باشد—طبق قانون پلتفرم فوری یا skip)، مسیر جلو می‌رود.

Condition wait

1. مخاطب وارد قدم می‌شود.
2. موتور منتظر برقرار شدن شرط می‌ماند: ایونت بعدی، تغییر پراپرتی، ورود به سگمنت.
3. اگر سقف زمانی بگذاری، مسیر «برقرار نشد» هم داری—جزئیات سقف را در صبر تا شرط با سقف زمانی در برابر نامحدود ببین.

مثال واقعی ایرانی

کلینیک—یادآوری نوبت

Event-time: با appointment_booked وارد شو؛ صبر تا appointment_at − 1 day؛ SMS از Kavenegar. اگر کسی نوبت را برای فردا بگیرد و offset «۲ روز قبل» باشد، باید قانون لبه را بدانی: فوری بفرست، skip کن، یا به مسیر کوتاه برو.

Condition: بعد از نوبت، صبر تا payment_completed یا ورود به سگمنت «پرونده کامل» قبل از پیام رضایت.

آموزش آنلاین—شروع کلاس

Event-time روی session_starts_at − 2h برای یادآوری. Condition روی lesson_1_completed قبل از باز شدن درس ۲.

فروشگاه—پیک زمان‌بندی‌شده

Event-time روی delivery_slot_start − 3h. Condition روی order_delivered قبل از درخواست نظر.

کی کدام را انتخاب کنی؟

1. لحظهٔ تقویمی از قبل روی ایونت است → Event-time.
2. باید منتظر کار کاربر بمانی → Condition (+ سقف وقتی لازم است).
3. رزروهای دیر را در QA تست کن—بیشتر باگ‌های یادآوری از همین لبه‌اند.
4. Quiet hours را جدا از Event-time نگه دار؛ رسیدن ساعت نوبت ≠ اجازهٔ پیامک نیمه شب.
5. Live Chat برای کسی که نوبت را اشتباه فهمیده انسانی بماند؛ AI Chat ابزار داخلی تیم است.

نگاشت به Leadara

• Events: appointment_at / remind_at را روی ایونت enrollment ذخیره کن.
• Journeys: wait تا رسیدن ساعت برای SMS/ایمیل؛ wait جدا تا شرط پرداخت/سگمنت.
• Email / SMS: متن یادآوری از پراپرتی همان نوبت؛ مسیر شرط از وضعیت فعلی.
• Segments: شرط VIP یا «پرونده کامل» را سگمنت شفاف کن.
• کانکتور جعلی نساز—SMS از پنل کاربر (Kavenegar/Nikaline).

اشتباه‌های رایج

• Offset دو روز قبل برای نوبت فردا بدون قانون لبه.
• Event-time را با تأخیر ثابت «۲۴ ساعت بعد از ورود» یکی فرض کردن.
• Condition نامحدود بدون سقف برای پرداخت.
• فرض اینکه شرط از قبل برقرار بوده skip می‌شود—رفتار را تست کن.
• قاطی‌کردن تاریخ تولد روی پروفایل (فلو تاریخ) با timestamp نوبت روی ایونت.

جمع‌بندی یک‌خطی

Event-time = بیدار شو وقتی ساعت به زمان داخل تریگر برسد؛ Condition = بیدار شو وقتی بعداً چیزی برقرار شود.

گام بعدی

یک یادآوری نوبت زنده را باز کن. بپرس: بیدارشدن از روی تقویم ایونت است یا از روی کار بعدی کاربر؟ همان را در Leadara جدا مدل کن و لبهٔ رزرو دیر را تست کن.

سؤالات پرتکرار

اگر نوبت زودتر از offset باشد چه می‌شود؟

قانون لبه را مکتوب کن: ارسال فوری، skip، یا مسیر کوتاه. بدون سند، پشتیبانی غافلگیر می‌شود.

Event-time می‌تواند از ایونتی غیر از تریگر بخواند؟

بعضی سیستم‌ها فقط timestamp تریگر را می‌بینند؛ بعضی اجازهٔ ایونت/attribute دیگر می‌دهند. در Leadara روی پراپرتی‌ای که واقعاً داری صبر را بنا کن.

کسی که از قبل شرط را دارد صبر را skip می‌کند؟

اغلب بله در ارزیابی ورود به wait—ولی همیشه با پروفایل تست تأیید کن.

Quiet hours با Event-time چه نسبتی دارد؟

جداست. ساعت نوبت می‌تواند داخل quiet hours بیفتد؛ یا صبر اضافه یا پنجرهٔ ارسال تعریف کن.

برای سالگرد خرید کدام؟

اگر سالگرد روی پراپرتی تاریخ پروفایل است، بیشتر به فلو تاریخ نزدیک است تا Event-time وسط جرنی.

سقف برای Event-time لازم است؟

کمتر از Condition؛ لبهٔ گذشته‌شدن مهم‌تر از TTL است.

پیامک نوبت تراکنشی است یا پروموشنال؟

یادآوری نوبت معمولاً تراکنشی/عملیاتی است—فرکانس‌کپ پروموشنال را بی‌خودی رویش نگذار.

سناریوی قدم‌به‌قدم

1. فیلد زمان را نام ببر (appointment_at).
2. Offset را با محصول قفل کن (−۱ روز، −۲ ساعت).
3. لبهٔ دیررزرو را بنویس.
4. شرط‌های جدا (پرداخت، حضور) را Condition جدا کن—داخل همان Event-time قاطی نکن.
5. در Leadara بساز؛ پروفایل نوبت فردا، نوبت هفته بعد، نوبت گذشته را تست کن.
6. نرخ حضور و نرخ «پیام بعد از نوبت» را دو هفته ببین.

متریک‌ها

• نرخ تحویل SMS یادآوری
• No-show بعد از یادآوری
• سهم مسیر لبهٔ دیررزرو
• زمان در Condition wait و سهم منقضی

زبان گزارش

بگو «یادآوری −۲۴س: ۸۲٪ تحویل، no-show از ۱۸٪ به ۱۱٪»، نه «اتومیشن نوبت داریم».

اسکچ

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

تست پذیرش

1. نوبت ۷ روز بعد + offset −۱ روز → پیام حدود ۲۴ساعت قبل.
2. نوبت فردا + offset −۲ روز → مسیر لبه طبق سند.
3. Condition پرداخت با سقف ۴۸ساعت → met یا expired.
4. Quiet hours پیامک نیمه‌شب را نگه دارد یا شیفت دهد.
5. Live Chat انسانی برای تغییر نوبت؛ AI Chat فقط کمک داخلی تیم.

چک‌لیست کانال

• SMS یادآوری: کوتاه، با تاریخ/ساعت واضح
• ایمیل Conditon: وضعیت فعلی را تکرار نکن اگر SMS کافی است
• وب‌پوش فقط اگر کاربر اپ/سایت فعال دارد

طراحی پیام یادآوری بدون اسپم لبهٔ دیررزرو

وقتی target از قبل گذشته یا خیلی نزدیک است، یک تأیید کوتاه («نوبت شما فرداست») بهتر از فشردن کل سکانس −۲روزه در یک دقیقه است. متریک جدا برای مسیر لبه بگذار تا محصول بعداً offset پیش‌فرض را کوتاه کند.

تعامل با exit و هدف جرنی

اگر کاربر نوبت را لغو کرد، exit سراسری یا خروج شبیه conversion باید هم Event-time و هم Condition را پاک کند. وگرنه برای نوبت لغوشده هم یادآوری می‌رود—تیکت کلاسیک پشتیبانی.

تفاوت با صبر تا ایونت تازه

صبر تا ایونت تازه منتظر fire بعد از ورود است. Event-time ممکن است هیچ ایونت تازه‌ای نخواهد—فقط ساعت روی همان تریگر. اگر تیم بگوید «صبر تا ایونت» ولی منظورش timestamp است، در بریف غلط می‌نویسید.

چک‌لیست عملیات برای کلینیک‌ها

• فیلد زمان در وب‌هوک/SDK یکسان نام‌گذاری شده؟
• offset با تایم‌زون Asia/Tehran تست شده؟
• مسیر لغو نوبت به exit وصل است؟
• متن SMS تاریخ را به شمسی درست نشان می‌دهد (اگر تبدیل می‌کنید) بدون ادعای قابلیت ساختگی؟
• بعد از یادآوری، Condition جدا برای «آمد / نیامد» دارید؟

گسترش مثال SaaS

برای تمدید اشتراک: Event-time روی renews_at − 3 days برای ایمیل یادآوری کارت. Condition روی card_updated قبل از پیام «تمدید شد». اگر فقط Condition بگذاری و تاریخ تمدید را نادیده بگیری، همه را همزمان با تأخیر ثابت بیدار می‌کنی و لبهٔ تمدید از دست می‌رود.

مطالب مرتبط

• صبر تا رویداد در برابر تأخیر ثابت: توقف برای سیگنال در برابر توقف برای ساعت
• صبر تا برقراری شرط با سقف زمانی در برابر صبر نامحدود
• فلو تاریخ پروفایل در برابر فلو رویداد رفتار: سالگرد روی تقویم در برابر سیگنال زنده