Routing and failover
Routes are ordered by priority and weighted within a connection. The point of the arrangement is that a provider rejecting sends degrades into slower sending, not into silence.
Read the guide →Sending service and incident alerts
An incident alert arrives when something is already wrong, which is the worst possible moment to discover your send path is also down. Redundancy in the messaging layer is what makes the alert dependable.
What an incident message owes the reader
Send an update when the state changes, not on a fixed cadence that produces messages with nothing new in them. A silence that was promised is better than a message that says nothing.
- What is affected, in plain terms
- What the recipient should do, if anything
- When the next update will come
- A link to the live status page
Redundancy is the point
Incident traffic should not depend on a single provider account — the day you need it is the day you cannot afford a second failure. On the SMS channel, traffic can route to another connected account when one stops accepting traffic, and receipts show what actually left.
- Automatic failover between connected SMS accounts
- Per-number pacing so an affected-account send does not stall
- Receipt status recorded so “we told them” is provable
Scope it or lose the audience
Sending an incident alert to every address you hold is how a service message becomes noise. Scope the recipient list to genuinely affected accounts — the platform sends to the list you give it, so the accuracy of that list is on your side.
Questions this usually raises
- Can alerts be sent on WhatsApp as well as SMS?
- You can connect the accounts you hold on each channel. Automatic failover between accounts is implemented for the SMS channel.
- Do we need a second provider to make this work?
- Failover needs somewhere to fail over to, which means more than one connected account on that channel.
- Will alerts respect opt-outs?
- A service or incident notice to an affected account is transactional, so it is not filtered by promotional suppression.
Keep reading
Pacing, quotas and why we queue
Every connection carries a send rate. The platform queues to that rate instead of firing as fast as a provider will accept, because the fastest way to get throttled is to send at the speed that causes it.
Read the guide →One-time passwords
An OTP has three requirements and no fourth: it must arrive, it must arrive before it expires, and there must be a record that it was sent. Everything else about OTP delivery follows from those three.
Open →Order confirmations
A confirmation is the moment a customer stops wondering whether the order went through. It is also the message most likely to be forwarded, screenshot and used as a receipt, which sets the bar for what it must contain.
Open →Shipping and delivery updates
Shipping updates are bursty and unforgiving: nothing for hours, then a batch for a whole route. The failure mode is a batch that stalls halfway through, so pacing and routing do most of the work here.
Open →Appointment reminders
A reminder works when it arrives early enough to change behaviour and says only what is needed to act: when, where, and how to change it. Everything beyond that reduces the chance it is read.
Open →Payment reminders
A payment reminder sits between transactional and promotional, and where you place it decides whether it is a service or a nuisance. The useful rule: if the recipient owes the message, it is transactional.
Open →Two-factor authentication
A 2FA message is an OTP with a security context: it is triggered by a login attempt, it is time-critical, and it is the message most likely to be complained about if it arrives unexpectedly — because an unexpected one means something happened to the account.
Open →Account security alerts
A security alert is not a notification, it is an opportunity for the account owner to interrupt something. That makes speed and clarity the only two things that matter, and detail a liability.
Open →Customer feedback requests
Feedback requests are marketing in everything but name, and treating them as transactional is how a service relationship turns into a nuisance. They are the clearest case for suppression and for restraint on frequency.
Open →Scope. Whaleal Messaging is an orchestration layer over the CPaaS or BSP accounts you already hold. Your contracts, your rates and your sender identities stay yours, and nothing in the middle reprices them. Routing, pacing and logging run on the SMS channel; consent and content stay with you.