Channel On-Send branch vs On-Delivery branch: continue when handed to provider vs when the handset accepts

On-Send advances as soon as the journey hands the message to the ESP/SMS provider. On-Delivery advances only when the provider reports successful handset/inbox delivery. In some designs both branches can fire in sequence for the same person, so you must design parallel continuation carefully or explicitly finish paths you do not want.

What is the difference between On-Send and On-Delivery branches?

After an email/SMS send step, continuation can hook channel signals:

• On-Send: “Accepted by the provider / queued.” Not the same as “customer saw it.”
• On-Delivery: “Handset/inbox accepted” per provider report (e.g. SMS DLR).
• Often also On-Failure: reject, blacklist, invalid number, bounce.

Iran reality: send ≠ deliver for SMS is common—coverage, bad numbers, operator filters. Treating On-Send as success lies in the dashboard.

Related to SMS flow vs SMS campaign and transactional vs promotional; here the focus is the post-send branch.

Simple timeline

journey send step
   → provider accepted          ← On-Send
       → handset/inbox OK       ← On-Delivery
       → rejected / failed      ← On-Failure
   → (optional) open/click later ← engagement, not Delivery

On-Open for email ≠ On-Delivery. Delivery means arrived; Open means opened.

Comparison table

Iran examples

Store — SMS fallback to email

Cart discount SMS: if no On-Delivery within 2 hours or On-Failure → same offer by email. If you treat On-Send as success, fallback never runs while the customer never saw the SMS.

Transactional — OTP

On-Failure matters immediately; On-Send alone is not enough for UX if delivery failed. Keep transactional policy separate from promo.

SaaS — renewal notice

On-Delivery → gentle reminder 24h later if unread. On-Send alone does not prove awareness.

The dual-branch problem

Some engines let both On-Send and On-Delivery continue for one person—two parallel paths. If each sends another email, they get duplicates. Fixes:

1. Explicit finish/exit on paths you do not want.
2. Pick one signal for primary continuation (often Delivery for fallback).
3. Guard with a journey attribute already_continued.

When to choose which

1. Need to know the system accepted the send → On-Send for metrics/non-sensitive continue.
2. Need channel fallback or “it arrived” promises → On-Delivery / On-Failure.
3. Do not confuse Open/Click with Delivery.
4. Promo: watch fatigue; transactional: take Failure seriously.
5. Confused customers → human Live Chat; AI Chat is not a customer live-chat bot.

Leadara mapping

• Journeys + Email/SMS: branch on real provider signals—not on imagined views.
• SMS via Kavenegar/Nikaline: use failure/delivery for fallback to email or web push.
• Web push: second channel when SMS fails if permission exists.
• Events: delivery is still a channel signal—see event-centric vs contact-centric.
• Do not invent connectors; use the user’s panel.

Common mistakes

• On-Send = customer saw it.
• Both branches without finish → duplicate messages.
• Treating On-Open as Delivery.
• Ignoring On-Failure for OTP/transactional.
• Treating one-shot blasts like branched flows.

One-line takeaway

On-Send = handed to the provider; On-Delivery = device/inbox reported success—and design dual-branch continuation on purpose.

Next step

Open one live SMS flow. Ask: does continuation use Send or Delivery? If you have fallback, test Failure/Delivery and finish the Send path if it must not run in parallel.

FAQ

Can both On-Send and On-Delivery fire for the same user?

In some designs yes—so explicit finish matters.

When should I branch On-Failure?

OTP, transactional, and any valuable channel fallback.

Is On-Open the same as On-Delivery for email?

No. Delivery is arrival; Open is opening.

Do SMS DLRs always arrive?

No. Add a timeout path: “if not delivered within N hours.”

Web push instead of email?

Only with permission; otherwise email.

Does this apply to blast campaigns?

Rich branching is more meaningful in flows/journeys than one-shot blasts—see SMS flow vs campaign.

Can AI answer the customer when SMS fails?

Leadara Live Chat is human support; AI Chat is an internal team assistant.

Step-by-step

1. Write the branch goal: internal metric or fallback?
2. Pick one primary signal (often Delivery/Failure for fallback).
3. Finish unwanted parallel paths.
4. Add timeout for missing DLR.
5. QA with real fail and deliver test numbers.
6. Watch Send vs Delivery vs Failure for a week.

Metrics

• Send rate vs Delivery rate
• Top failure reasons
• Email fallback entry rate
• Duplicate messages from parallel branches

PM language

Say “cart SMS: 96% Send, 78% Delivery, 9% Failure→email; 0 duplicates after guard,” not “sends were successful.”

Sketch

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

Acceptance tests

1. Successful delivery → only Delivery path (if that is the design).
2. Failure → email fallback, no optimistic path.
3. Send without Delivery until timeout → “not reached” path.
4. Guard prevents dual messages.
5. Open measured separately from Delivery.

Channel checklist

• SMS: reading DLR and panel errors?
• Email: bounce distinct from delivered?
• Web push: permission before fallback?

Black Friday note

In traffic spikes, Send stays high while Delivery dips. Sensitize the dashboard to Delivery/Failure so the team does not celebrate green Send while customers got nothing.

Live Chat handoff

If a discount SMS never arrives and the customer says so in Live Chat, a human should resend or switch channel. Automation should already own the Failure path so chat only handles exceptions.

Versus engagement waits

Delivery answers “did the pipe work?” Click/open answers “did they engage?” Do not build an Action Path on Send acceptance and call it engagement.

Growth-team decision matrix

Teaching numbers

Of 10,000 cart SMS: 9,600 Send, 7,800 Delivery, 900 Failure, 300 missing DLR at 2h. Calling Send “96% success” hides ~22% who likely never saw the offer—those should enter email/push fallback.

Consent and annoyance

Duplicate messages from parallel branches drive unsubscribes on promo traffic. Treat an already_continued guard like mandatory code, not optional polish.

OTP special case

For OTPs, prefer Failure→visible in-app error plus resend, not a promotional email fallback that leaks codes. Keep transactional templates and journeys isolated.

Related reading

• SMS flow vs SMS campaign: why triggered texts beat blasts
• Transactional vs promotional email and SMS: the operator’s guide
• Event-centric vs contact-centric automation: behavior streams vs person records