Multichannel notification feels like belt-and-suspenders. If email lands in spam, push will catch it. If push is muted, email will catch it. The math is comforting until you actually measure delivery on both legs and discover the overlap is non-trivial — a meaningful share of users miss both channels for the same notification.
Dual-channel notifications need an audit on both channels independently. Email failure is mostly silent (spam folder). Push failure is mostly silent (muted, OS suppression, opt-out). The 1-3% of users who miss both for a critical event are the ones who churn. Measure both channels, build a third (in-app inbox), and require explicit acknowledgement for high-stakes messages.
Channel coverage in 2026
Real numbers across mid-market SaaS we've audited:
- Email: 92-97% delivered to inbox at major providers (with a properly configured transactional sender). 3-8% in spam, never opened.
- Push (mobile): 60-75% delivered as a visible notification on iOS, slightly higher on Android. The rest are suppressed by OS-level focus modes, app-level opt-out, or device-level mute.
- Push (web): 30-50% delivered as visible. Browser-level permission denials and OS suppression are the major failure modes.
- In-app inbox: 100% delivered (it's your own surface), but only seen if the user logs in.
- SMS: 95%+ delivered, but expensive at scale and inappropriate for low-priority notifications.
Combine email and push, the "both fail" rate sits around 1-4% depending on the user base. For high-stakes notifications (security, billing, compliance), that's the rate at which your customer is unaware of something they need to know.
Fallback patterns that work
The naive pattern is "send email and push in parallel". Better patterns add timing and acknowledgement:
- Email-first, push-fallback. Send email immediately. If no engagement signal in 30 minutes, send push. Cuts duplicate notifications for users who read email promptly.
- Tiered escalation. For critical events, fan out to all channels in parallel. For routine events, channel one at a time with timed escalation.
- Acknowledgement-aware. If the user opens the in-app inbox and reads the notification, suppress the push. If the user opens the email, suppress the next-day reminder.
- Channel-of-record. One channel is authoritative (typically the in-app inbox); others are best-effort notifications about it.
Customer.io, Courier, Knock: orchestration
Multichannel notification is hard enough that several infrastructure companies exist to do it for you:
- Customer.io. Mature, marketing-leaning. Strong on campaign-style multichannel.
- Courier. Developer-first. API-driven, fits well into product-event flows.
- Knock. Newer, opinionated. Strong on user preference management and in-app inbox.
All three solve the orchestration problem (rules engine, channel routing, preference management) but none of them solve the underlying email or push deliverability — that's still on you. They make it easier to fan out and easier to measure; they don't make the channels themselves more reliable.
Most teams measure "was the notification sent" not "was it received and seen". Sent is easy. Received requires per-channel telemetry: email open events (degraded by MPP but still useful), push delivery receipts (where the OS provides them), in-app inbox views. Build the observability before you need it.
Test both channels independently
Email tests via seed inboxes. Push tests via test devices on iOS and Android, with various focus-mode and opt-out states. In-app inbox tests via integration tests in the product.
Run all three on a regular cadence. The failure modes diverge: email fails because of sender reputation, push fails because of OS-level changes (Apple's Focus Modes are a moving target), in-app inbox fails because of UI bugs. Each channel has its own cadence of regression.
Rules engine: which event uses which channel
Not every event needs every channel. A rules engine that maps event types to channel sets is worth the engineering effort:
- Critical (security, billing failure, fraud alert): all channels in parallel; require explicit acknowledgement.
- High (account changes, document ready): email + push, escalate to in-app prominent banner if unread for 24 hours.
- Medium (mention, comment, assignment): push if mobile app, email if not, in-app inbox always.
- Low (digest, summary, weekly recap): email only, no push.
The default-to-all-channels approach trains users to ignore your notifications. Surgical channel selection trains them to act when something arrives.
User preferences and channel sovereignty
Users should control their own channel preferences per notification category. The patterns that work: per-category toggles (security, billing, mentions, marketing), per-channel on/off (email yes, push no), and a do-not-disturb window (silent 22:00-07:00 local).
Honour the preferences strictly. Override only for genuinely critical events (fraud, security) and disclose that you'll do so. The trust this builds is itself a deliverability asset — users who trust your notifications open them, which feeds reputation.