Azmarq · Fallback Solutions
Reach that survives failed sends, quiet hours, and device gaps
WhatsApp-first programs with SMS, RCS, email, and voice as thoughtful failover — driven by delivery events, consent, and journey logic — not blind duplicate blasts.
Why fallback
One channel is a hope. A path is an operating system.
India GTM hits WhatsApp quality windows, DND, DLT sender rules, RCS device reach, and flaky last-mile delivery. Fallback Solutions is how Azmarq keeps OTP, utility, and campaign intent alive across that reality — without treating every contact like a megaphone target.
Silent OTP death
Code sent once on a failed route → user abandons signup
Campaign vanity
WhatsApp-only blast looks big; unique people reached is smaller
Support blind spots
Alert never arrives; customer calls angry with no context
Compliance risk
Dual-send spam to force reach → opt-out and quality damage
Channel paths
Pick a hop. See how it should behave.
WhatsApp → SMS
WhatsApp → SMS
When a template or session message isn’t delivered — or the customer isn’t active on WhatsApp — rewrite the intent as a short SMS utility alert so OTP, shipping, and appointment moments still land.
- Ideal for OTP, COD confirm, and time-bound alerts
- Keep copy channel-fit (SMS ≠ long WhatsApp script)
- DLR webhook fires the hop — not a blind dual-send
- Reply can still open a WhatsApp or inbox thread later
Live hop (illustrative)
01
Send on WhatsApp
Primary template / rich / session
02
Watch delivery event
Webhook: failed · expired · unsupported
03
Hop to SMS
Channel-fit rewrite · same intent
04
Close the loop
Inbox / verify / suppress further spam
Triggers
What should actually start a failover
Good fallbacks are event-led. Bad ones are “send everything twice.”
01
Delivery failure
Undelivered / expired / rejected events from the primary channel trigger the next hop.
02
Capability miss
RCS not supported on device → SMS. WhatsApp not opted-in → alternate consented channel.
03
Quiet hours / DND
Hold or reshuffle to a channel and time window that stays India-compliant.
04
Timeout without engagement
No read/reply within a wait step — branch to a lighter SMS or email reminder.
05
Quality / template pressure
When WhatsApp quality risks rise, protect the WABA and shift non-critical volume thoughtfully.
06
Customer preference
My CDP channel opt-ins decide which fallback is even allowed for that contact.
In journeys
Fallback is a branch — not a second campaign tool
Customer Journeys own waits, DND-aware timing, and channel steps. Fallback Solutions is the discipline of wiring those steps so a failed WhatsApp send becomes an SMS (or email / voice) hop with the same goal — then returns replies to Unified Inbox.
Journey skeleton (illustrative)
- Trigger: CTWA lead / order event / OTP request
- Step A: WhatsApp utility or session message
- Wait: delivery event or N minutes
- Branch: delivered → continue · failed → SMS/email/voice
- Goal: verified · confirmed · replied → stop further hops
Consent & DND
Failover never excuses bad outreach
Opt-ins travel with the profile
My CDP channel preferences gate which fallback is even eligible — WhatsApp, SMS, email, voice.
India timing stays honest
Quiet hours and DND-aware waits apply across hops so you don’t “fix delivery” by breaking the clock.
Sender discipline
SMS fallbacks still need proper sender IDs / DLT where required — Messaging portal owns that reality.
Module map
What runs the fallback stack
| Capability | How it runs | Module |
|---|---|---|
| Orchestration | Waits · branches · channel hops | Customer Journeys |
| Consent & preference | Opt-ins · attributes · segments | My CDP |
| Primary chat | Templates · session · quality | WhatsApp Business |
| Classic reach | Sender IDs · DLT · reports | Messaging SMS |
| Rich SMS-inbox | RCS with SMS fallback | Google RCS |
| Mailbox & voice | Transactional email · Voice OTP | Email · Voice 360 |
| Event signals | DLR · inbound · status | Webhooks |
| Human close | Tickets · ownership · AI handoff | Unified Inbox |
Single-channel hope vs Azmarq path
Single channel
- —One failed send = abandoned user
- —Teams dual-blast to compensate
- —No shared consent truth
- —Replies scatter across tools
Fallback Solutions
- ✓Event-led hops with channel-fit copy
- ✓Unique-person reach over vanity sends
- ✓My CDP preferences on every hop
- ✓Inbox ownership when humans matter
Next in the Azmarq story
FAQs
Fallback Solutions — FAQs
Straight answers for teams evaluating this module inside Azmarq CPaaS.
Talk to salesRules and journey patterns that move a send to SMS, RCS, email, or voice when the primary channel (often WhatsApp) can’t deliver — so OTPs and campaigns don’t silently fail.
It’s how Azmarq channels work together inside Journeys, OTP, and Messaging — confirm packaging with sales for your plan entitlements.
No. My CDP preferences and India-aware timing still apply across every channel hop.
Delivery failure events can trigger the next channel instead of polling — see the Webhooks developer page for the integration pattern.
Usually no. Prefer event-led hops after failure/timeout so you don’t spam or burn sender reputation. Dual-send only when the use case truly requires parallel reach.
Yes where Indian regulations require them. Messaging SMS portal controls sender setup — fallback doesn’t bypass compliance.
Yes. When the customer replies on an enabled channel, keep ownership in Unified Inbox so failover isn’t a dead-end blast.
Design reach that survives the real world
We’ll map primary + fallback channels to your journeys, OTP flows, and wallet packaging — without pretending one channel is enough.
