Opt-out handling
Opt-out is two halves: the suppression record, and the check that runs before a marketing message is handed to the provider. Both run through one shared normalization, which is the part that usually breaks.
Read the guide →Ask for feedback without becoming noise
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.
One question gets answered
The response rate collapses with every additional question, and the answers stop being comparable. A short request sent consistently produces better data than a thorough one sent rarely.
- A rating with a single tap
- An optional free-text box, not a required one
- A clear statement of what the feedback changes
- A link to a longer survey for the minority who want it
It is promotional traffic — suppression applies
A feedback request is promotional traffic, so opt-out suppression on the SMS channel applies — a customer who asked not to be marketed to should not be surveyed. The platform applies the suppression it is configured with, per the rules you set.
- Suppression applied to promotional sends
- Opt-out keywords matched exactly, so a request is never silently swallowed by a loose match
- Re-subscription handled deliberately rather than implicitly
Time it after the transaction resolves
The best moment is shortly after the transaction resolves and long enough afterwards that the customer has an opinion. That is a product decision; the platform sends when told to send, and logs what happened.
Questions this usually raises
- Are feedback requests opt-outable?
- Yes — they are promotional traffic, and suppression on the SMS channel applies to them.
- Can feedback requests be scheduled?
- Scheduled and bulk sending are console features. Scheduling a feedback run days after a transaction is a configuration rather than a code change.
- Will a “STOP” in a normal reply suppress someone?
- Opt-out keywords are matched exactly rather than fuzzily, precisely so that collateral wording does not silently suppress a customer.
Keep reading
What the platform does not keep
Message content is not archived. What is kept is metadata — and among that metadata two fields are load-bearing, because without them a bill could not be reconciled.
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 →Shipping and delivery updates
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.
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 →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.