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 →Send shipping and delivery updates when the state changes
Dispatch notices, tracking updates and delivery windows go out when the state actually changes, not on a timer. On the SMS channel the platform spreads a dispatch batch to the limit your provider applies per number, so a whole route does not stall halfway through.
The four updates a customer waits for
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 that drain instead of stalling
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 normalized so a rejection is distinguishable from silence
What stays on your side
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
Your login depends on a code landing before the session expires. Connect the accounts you already pay for and the platform paces each code to the number it leaves from — so a burst of logins drains at the speed your numbers allow instead of queueing behind one shared quota.
Open →Order confirmations
The confirmation is the message your customer keeps — forwarded, screenshotted, quoted back to support. Send it the moment the order lands, on a channel they actually read, and let the log answer for it later.
Open →Appointment reminders
A reminder earns its place by arriving early enough to change a plan and saying only what the person needs to act on: when, where, and how to change it. Send a confirmation at booking and a timed reminder before, on the number they booked with.
Open →Payment reminders
The reminder that arrives before a due date is a service; the one that arrives after is a complaint notification. Send both, keep them transactional, and pace the due-date batch so it drains in a time you can plan around.
Open →Two-factor authentication
A 2FA message is triggered by a login attempt, is time-critical, and — when it arrives unexpectedly — is the earliest signal your customer gets that someone else has their password. Send it fast, word it as a warning, and keep the record.
Open →Account security alerts
A security alert is not a notification — it is the account owner’s chance to interrupt something in progress. Speed and clarity are the whole job, and detail is a liability.
Open →Service and incident alerts
An incident alert arrives when something is already wrong — the worst possible moment to discover your send path is down too. Keep more than one connected account on that channel, and the notice about the outage is not its first casualty.
Open →Customer feedback requests
A feedback request is marketing in everything but name, so treat it like one: one question, sent once, to people who have not opted out. That is what keeps the answers worth reading.
Open →Scope. Whaleal Platform sends 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 and pacing run on the SMS channel while logging covers every channel; consent and content stay with you.