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 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.
The sequence that helps a customer
Send on real state changes, not on a timer. An update that says nothing new trains the recipient to ignore the next one — and a delivery-window message that arrives late is worse than none.
- Dispatched, with a tracking reference
- In transit or delayed, when the status genuinely changes
- Out for delivery, on the day it matters
- Delivered, or a failed attempt with a next step
Batches, limits and failover
A dispatch batch can exceed what one number absorbs. On the SMS channel the platform paces the batch to the per-number limit and can route to another connected account if one stops accepting traffic, so a failed provider does not silently strand half a route.
- Batches spread to the provider limit per sender number
- Automatic failover between connected SMS accounts
- Receipts normalised so a rejection is distinguishable from silence
What stays with you
The accuracy of the tracking data, the decision to notify, and any rules about contacting recipients are yours. The platform carries the message on your account and reports what happened to it.
Questions this usually raises
- Can we hold updates until a window opens?
- Scheduled and bulk sending are console features. For delivery updates, though, sending when the state changes is usually the better pattern.
- Will a delayed provider break the whole batch?
- On the SMS channel, traffic can route to another connected account. That keeps the batch moving; it does not guarantee the destination network accepts every message.
- Do we get told which notices failed?
- Each send carries a status, and failures record the provider’s reason where one was returned. That is the record support works from.
Keep reading
Reading a delivery receipt
A receipt is a sequence of states, not a verdict. Treating an intermediate one as final is the most common way a sending dashboard ends up lying to you.
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 →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 →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.
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.