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 normalisation, which is the part that usually breaks.
Read the guide →Sending 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.
One question beats five
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
Suppression and frequency come with the send
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
Send time is the variable you control
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
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 →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 →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.