شاخه On-Send در برابر On-Delivery: ادامه وقتی به پنل سپرده شد در برابر وقتی گوشی تحویل گرفت

شاخهٔ On-Send به‌محض اینکه جرنی پیام را به پنل ESP/SMS می‌سپارد جلو می‌رود؛ شاخهٔ On-Delivery فقط وقتی ارائه‌دهنده تحویل موفق به گوشی/اینباکس را گزارش کند جلو می‌رود—و در بعضی طراحی‌ها هر دو شاخه می‌توانند پشت‌سرهم برای یک نفر fire شوند؛ پس باید ادامهٔ موازی یا finish صریح روی مسیرهای ناخواسته را طراحی کنی.

On-Send و On-Delivery دقیقاً چه فرقی دارند؟

بعد از قدم ارسال ایمیل یا پیامک، مسیر ادامه می‌تواند به سیگنال‌های کانال وصل شود:

• On-Send: «به پنل سپرده شد.» هنوز یعنی مشتری دیده؟ نه. یعنی API پنل قبول کرد / صف ارسال گرفت.
• On-Delivery: «دستگاه/اینباکس تحویل گرفت» طبق گزارش provider (مثلاً DLR پیامک کاوه‌نگار).
• کنارش اغلب On-Failure هم هست: رد، بلک‌لیست، شماره باطل، bounce.

واقعیت ایران: send ≠ deliver برای SMS خیلی رایج است—پوشش، شماره اشتباه، فیلتر اپراتور. اگر فقط On-Send را «موفقیت» حساب کنی، گزارش دروغ می‌گوید.

نزدیک به فلو پیامکی در برابر کمپین و تراکنشی در برابر پروموشنال؛ اینجا تمرکز روی شاخه بعد از ارسال است.

تایم‌لاین ساده

journey send step
   → provider accepted          ← On-Send
       → handset/inbox OK       ← On-Delivery
       → rejected / failed      ← On-Failure
   → (optional) open/click later ← engagement جدا، نه Delivery

On-Open برای ایمیل ≠ On-Delivery. Delivery یعنی رسید؛ Open یعنی باز شد.

جدول مقایسه

مثال ایرانی

فروشگاه—فال‌بک SMS به ایمیل

SMS کد تخفیف سبد: اگر On-Delivery در ۲ ساعت نیامد یا On-Failure آمد → ایمیل همان آفر. اگر فقط On-Send را موفقیت بدانی، هیچ‌وقت فال‌بک نمی‌رود در حالی که مشتری پیام را ندیده.

تراکنشی—رمز یک‌بارمصرف

اینجا On-Failure فوری مهم است؛ On-Send برای ادامهٔ UX اپ کافی نیست اگر تحویل شکست خورده. با سیاست تراکنشی جدا از پرومو حرکت کن.

SaaS—اعلان تمدید

On-Delivery → ۲۴ ساعت بعد یادآوری ملایم اگر باز نکرد. On-Send alone برای «حتماً خبر دارد» کافی نیست.

مشکل دو شاخه‌ای

بعضی موتورها اجازه می‌دهند هم On-Send و هم On-Delivery برای یک نفر ادامه پیدا کند—یعنی دو مسیر موازی. اگر هرکدام ایمیل بعدی بفرستند، دوبار پیام می‌گیری. راه‌حل‌ها:

1. روی مسیرهایی که نمی‌خواهی، finish/exit صریح بگذار.
2. فقط یکی را برای ادامهٔ اصلی انتخاب کن (معمولاً Delivery برای فال‌بک، Send برای متریک داخلی).
3. با journey attribute «already_continued» گارد بگذار.

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

1. فقط می‌خواهی بدانی سیستم ارسال را قبول کرد → On-Send برای متریک/ادامهٔ غیرحساس.
2. می‌خواهی فال‌بک کانال یا وعدهٔ «رسید» بدهی → On-Delivery / On-Failure.
3. Open/Click را با Delivery قاطی نکن.
4. برای پرومو، Fatigue را در نظر بگیر؛ برای تراکنشی Failure را جدی‌تر بگیر.
5. اگر مشتری گیج شد Live Chat انسانی؛ AI Chat ربات لایو مشتری نیست.

نگاشت به Leadara

• Journeys + Email/SMS: بعد از ارسال، روی سیگنال‌های واقعی provider شاخه بزن—نه روی خیال «حتماً دیده».
• SMS از Kavenegar/Nikaline: Failure/delivery را برای فال‌بک به ایمیل یا وب‌پوش استفاده کن.
• Web push: وقتی SMS fail شد می‌تواند کانال دوم باشد اگر کاربر اجازه داده.
• Events: اگر فقط event-centric فکر می‌کنی، باز هم delivery یک سیگنال کانال است—ببین event-centric در برابر contact-centric.
• کانکتور جعلی نساز؛ همان پنل کاربر.

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

• On-Send = مشتری دید.
• هر دو شاخه بدون finish → پیام تکراری.
• On-Open را Delivery فرض کردن.
• نادیده گرفتن On-Failure برای OTP/تراکنشی.
• بلست کمپین را با فلو شاخه‌دار یکی کردن.

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

On-Send = سپرده به پنل؛ On-Delivery = گزارش رسید به دستگاه/اینباکس—و موازی‌شدن شاخه‌ها را عمدی طراحی کن.

گام بعدی

یک فلو SMS زنده را باز کن. بپرس: ادامهٔ مسیر روی Send است یا Delivery؟ اگر فال‌بک داری، Failure/Delivery را تست کن و مسیر Send را finish کن اگر نباید موازی برود.

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

هر دو On-Send و On-Delivery برای یک نفر fire می‌شوند؟

در بعضی طراحی‌ها بله—پس finish صریح لازم است.

On-Failure را کی شاخه کنم؟

OTP، تراکنشی، و هر جا فال‌بک کانال ارزش دارد.

On-Open همان On-Delivery ایمیل است؟

خیر. Delivery رسید؛ Open بازشدن.

DLR پیامک همیشه می‌آید؟

نه. برای تصمیم‌های سخت، timeout «اگر تا N ساعت Delivery نشد» هم بگذار.

وب‌پوش به‌جای ایمیل؟

اگر permission دارد؛ وگرنه ایمیل.

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

شاخه‌های غنی معمولاً در فلو/جرنی معنی‌دارترند تا بلست یک‌شات—ببین فلو در برابر کمپین پیامک.

AI می‌تواند به جای Failure جواب مشتری را بدهد؟

در لایو چت Leadara پاسخ مشتری انسانی است؛ AI Chat کمک داخلی تیم است.

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

1. هدف شاخه را بنویس: متریک داخلی یا فال‌بک؟
2. یک سیگنال اصلی انتخاب کن (معمولاً Delivery/Failure برای فال‌بک).
3. مسیرهای موازی ناخواسته را finish کن.
4. timeout برای DLR گمشده بگذار.
5. با شماره تست fail و deliver واقعی QA کن.
6. نرخ Send در برابر Delivery در برابر Failure را یک هفته ببین.

متریک‌ها

• Send rate در برابر Delivery rate
• Failure reasons top
• نرخ ورود به فال‌بک ایمیل
• پیام تکراری ناشی از شاخهٔ موازی

زبان گزارش

بگو «SMS سبد: ۹۶٪ Send، ۷۸٪ Delivery، ۹٪ Failure→ایمیل؛ ۰ دوگانه‌پیام بعد از گارد»، نه «ارسال موفق بوده».

اسکچ

after send(message):
  on_send: maybe continue_internal()
  on_delivery: continue_fallback_ok_path()
  on_failure: continue_fallback_other_channel()
  guard: if continued: finish other branches

تست پذیرش

1. Delivery موفق → فقط مسیر Delivery (اگر همان طراحی است).
2. Failure → فال‌بک ایمیل، بدون مسیر خوش‌بینانه.
3. Send بدون Delivery تا timeout → مسیر «نرسید».
4. گارد مانع دو پیام موازی شود.
5. Open جدا از Delivery اندازه‌گیری شود.

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

• SMS: DLR و خطای پنل را می‌خوانی؟
• ایمیل: bounce جدا از delivered؟
• وب‌پوش: permission قبل از فال‌بک؟

نکته برای بلک فرایدی

در پیک ترافیک، Send بالا و Delivery پایین‌تر دیده می‌شود. داشبورد را از قبل روی Delivery/Failure sensitize کن تا تیم «همه چیز سبز است» فکر نکند در حالی که مشتری‌ها پیام را نگرفته‌اند.

ارتباط با رضایت و Live Chat

اگر SMS کد تخفیف نرسد و مشتری در Live Chat بگوید «کد نیومد»، اپراتور انسانی باید بتواند resend یا کانال عوض کند. اتومیشن Failure باید همان مسیر را از قبل ساخته باشد تا چت فقط استثناها را بگیرد.

ماتریس تصمیم برای تیم رشد

مثال عدد فرضی برای آموزش تیم

از ۱۰٬۰۰۰ SMS سبد: ۹٬۶۰۰ Send، ۷٬۸۰۰ Delivery، ۹۰۰ Failure، ۳۰۰ بدون DLR تا ۲ ساعت. اگر فقط Send را موفقیت بدانی، «۹۶٪ موفق» می‌گویی در حالی که ۲۲٪ مشتری احتمالاً آفر را ندیده. همان ۲۲٪ باید وارد ایمیل/پوش شوند.

نکتهٔ合规 و رضایت

پیام تکراری از شاخهٔ موازی علاوه بر آزردن، برای پرومو ریسک نارضایتی و لغو اشتراک می‌آورد. گارد already_continued را مثل کد اجباری بدان نه اختیاری.

مطالب مرتبط

• فلو پیامکی در برابر کمپین پیامکی: چرا پیام رویدادمحور بهتر از بلست است
• تفاوت ایمیل و پیامک تراکنشی و پروموشنال چیست؟
• اتومیشن event-centric در برابر contact-centric: استریم رفتار در برابر رکورد شخص