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.
The reminder is transactional: it confirms something the recipient already arranged. That matters, because opt-out suppression applies to promotional traffic rather than to a reminder someone needs in order to turn up.
Reminder traffic clusters — most of it goes out at the same hour the day before. Because provider limits apply per sender number, a clinic-sized batch can queue behind itself, so the useful planning question is how many sender numbers the reminder hour needs.
A reminder is not a place for clinical, financial or case detail. The platform does not store message bodies — the log is metadata only — but the message itself still travels through your provider and lands on a handset that may be shared. Send a reference the recipient resolves in your own system rather than the detail itself.
The platform asks you to declare what kind of message you are sending instead of inferring it from the text. That one field decides whether the opt-out gate applies — and the honesty of the declaration is yours.
Read the guide →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 →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 →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 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 →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 →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 →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 →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 →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 →