Use case · Billing

Send the reminder before the payment fails

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.

Three moments worth a message

The first one does most of the work. A reminder that arrives before the date is a service; one that arrives after is a complaint notification.

  • Before the due date — the reminder that prevents a failure
  • On a failed payment — the notice that says the payment did not go through
  • After a grace period — the last notice before the consequence is applied

Due dates cluster — pace the batch

Customers choose the same few billing dates, which turns reminders into a batch. The platform paces a batch to what the provider allows per sender number, so a due-date run stretches predictably instead of failing partway through.

  • Per-number pacing so a billing-date batch drains in a known time
  • Delivery receipts recorded per send, where the provider reports them
  • Failures retained with the provider’s reason

Send a link to the bill, not the bill

Amounts and account details are exactly the kind of content that should be resolved behind a login rather than carried in a message. Send a link to the bill, not the bill.

Questions this usually raises

Is a payment reminder promotional?
It is transactional when the recipient owes the message — a due date or a failed payment. It becomes promotional when it carries an offer, and the consent rules follow the content.
Can reminders be scheduled ahead of time?
Scheduled and bulk sending exist as console features; their behavior is documented in the help center.
What happens to reminders if a provider stops working?
On the SMS channel, traffic can route to another connected account rather than failing outright.

Keep reading

5 min

Pacing, quotas and why we queue

Every connection carries a send rate. The platform queues to that rate instead of firing as fast as a provider will accept, because the fastest way to get throttled is to send at the speed that causes it.

Read the guide →
4 min

Who decides whether a message is marketing

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 →
Use cases

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 →
Use cases

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 →
Use cases

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 →
Use cases

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 →
Use cases

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 →
Use cases

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 →
Use cases

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 →
Use cases

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.