Mass Texting for Business: Consent, Segmentation and Delivery Operations

Most bulk SMS programmes fail for reasons that have nothing to do with the sending tool. The list was assembled from sources with no usable consent record. Promotional and service traffic share one sender and one queue, so a marketing batch delays a delivery notification. Nobody can say what the message actually caused, because reporting stops at delivery receipts.

This is what to get right before, during and after a bulk SMS programme.

When bulk SMS is the right channel — and when it is not

SMS suits messages that are short, time-bound and needed by someone who has asked to hear from you: an appointment reminder, a delivery window, a shift offer, a service disruption, a payment due notice, an occasional offer to a customer with an active relationship.

It suits things badly when:

• The message needs length, formatting, attachments or a considered read. Email is better.
• The recipient relationship is cold or the consent record is thin. SMS is an intimate channel and the complaint cost is high.
• The content is sensitive. Ordinary SMS is not end-to-end encrypted; content is visible to intermediaries in the delivery chain and sits in plain text on the handset, often on a lock screen. Nothing confidential belongs in the body.
• The send is essentially a broadcast to everyone because segmentation is hard. That is the pattern that produces opt-outs and carrier filtering.
• A cheaper, already-consented channel would do the same job. Reach for SMS when immediacy or reliability of arrival genuinely matters.

Separate promotional, service and urgent operational traffic

This is the single structural decision that most affects a programme. Treat traffic class as a first-class attribute — set on every message, and driving sender selection, route selection, queue, throttle, time-of-day rules and consent requirements.

• Promotional. Requires marketing consent. Subject to frequency caps and quiet hours. Lowest queue priority. First to be shed when capacity is short.
• Service or transactional. Tied to an existing transaction or relationship. Higher priority, tighter delivery deadlines, generally exempt from marketing frequency caps but not from suppression.
• Urgent operational. Outages, safety, time-critical logistics. Highest priority, separate route capacity, and a documented rule for what qualifies — otherwise everything becomes urgent.

Mixing these on one sender and one route means a promotional batch can delay service traffic, and a promotional complaint can damage the sender reputation that service traffic depends on. Some markets also impose different registration or content rules by category, so the separation is not purely internal hygiene.

Audience source, consent evidence and suppression

Ask of every list: where did these numbers come from, what were people told at the point of collection, and can you produce that evidence per record?

What to store per contact, per programme:

• Timestamp, source (form, checkout, keyword, verbal capture, import), the exact wording shown, and the identifier of the collecting system.
• Which traffic classes the consent covers. Consent for delivery notifications is not consent for promotions.
• Opt-out timestamp and mechanism where applicable.

Suppression is a system, not a list:

• One suppression store, checked at send time by every sending path — including one-off exports, ad-hoc sends and third-party tools.
• Opt-outs propagate immediately and everywhere. A recipient who replies STOP to a marketing message and then receives another marketing message the next day has produced both a complaint and a compliance problem.
• Handle the standard opt-out keywords for each market plus the misspellings and free-text variants people actually send, and confirm the opt-out once.
• Suppress hard-failure destinations (invalid, unreachable) after repeated failures rather than retrying them across every campaign.
• Decide and document whether a service-class message can go to a marketing opt-out. Sometimes it legitimately can; that decision should be explicit, per programme, and reviewed.

Requirements vary by market, carrier and programme type. This is operational practice, not legal advice — verify current rules for each market you send into.

Segment for relevance, not list size

The instinct to send to the whole list is what makes SMS expensive and unwelcome. Useful segmentation dimensions:

• Recency and state of the relationship — active customer, lapsed, never purchased.
• Where the recipient is in a specific process — booking pending, payment due, order in transit.
• Prior engagement with SMS specifically, including previous opt-outs at campaign level.
• Locale, language and time zone, which determines both content and sending window.
• Whether an alternative channel already reached them with the same message.

A smaller, well-targeted send that mentions something specific to the recipient will nearly always outperform a broadcast, and it protects the sender reputation and the opt-out rate that all your other traffic depends on.

Frequency controls and quiet hours

Frequency capping is an internal customer-experience and governance control, applied because too many messages damage the channel. Legal and carrier restrictions are a separate matter and must be checked per market and programme.

Implement caps centrally so they cover every sending path:

• A global cap per recipient across a rolling window, plus per-programme caps.
• Caps applied to promotional traffic; service and urgent traffic normally exempt, by explicit policy.
• Quiet hours evaluated in the recipient's local time, derived from a stored locale rather than inferred from the number prefix alone.
• A decision for capped messages: drop, or defer to the next permitted window. Deferral is right for offers, wrong for anything time-bound.
• Cap and quiet-hour decisions logged, so you can explain why a recipient did not receive a message.

Sender registration and recognisable identity

An unrecognised sender is the fastest route to being ignored or reported. Depending on market this means a registered alphanumeric sender ID, a long number, a short code or a registered number and brand — often with registration lead times of weeks, and rules that differ by market and traffic category.

Practical rules:

• Register early; treat registration lead time as a project dependency, not a detail.
• Keep sender identity stable per market and per programme. Rotating senders to evade filtering damages trust and tends to fail.
• Identify the brand in the first few words, because the sender display may not be enough.
• Where two-way replies matter, use a sender that can receive them, and make sure someone reads them.

Link and domain trust, and landing-page continuity

Links are where trust is won or lost:

• Use a consistent, branded link domain, warmed over time. A fresh or generic shortener domain looks like phishing and can be filtered.
• Never send a bare unbranded shortlink alongside an urgent instruction — that pattern is indistinguishable from a scam.
• Keep no personal data in query strings; use opaque, expiring tokens.
• The landing page must repeat the message wording, show the same brand, and lead directly to the single action requested. A message about a payment landing on a homepage loses most of its recipients.
• Make the page fast on mobile networks, and make sure it works when opened hours later or on a different device.

Encoding, segment length and cost control

Bulk SMS is billed per segment, so segment count is the cost driver. GSM-7 gives 160 characters in a single segment, 153 per segment when concatenated. A single Unicode character — an emoji, a curly apostrophe from a CMS, an accented name in a merge field — flips the whole message to UCS-2, cutting those limits to 70 and 67.

Controls worth having:

• Compute encoding and segment count before submission, store it on the message, and use it in reporting.
• Validate templates at save time, with a warning when a template is near a segment boundary and when merge fields could push it over.
• Test with real, worst-case merge data, not with placeholder names.
• Decide deliberately whether to normalise characters with GSM-7 equivalents, and make the substitution visible to whoever wrote the copy.

Scheduling, burst capacity, throttling and queues

A large send is a capacity event. Provider throughput is limited per account, per connection or per sender, and limits differ by market.

• Know your permitted throughput per route and rate-limit to it rather than discovering the limit through errors.
• Separate queues by traffic class, so a campaign cannot sit in front of service traffic.
• Treat throttle responses as backpressure that slows the queue, not as message failures.
• Spread large sends deliberately. A short burst is not usually the objective; arriving inside a useful window is.
• Set a hard deadline per message and drop rather than deliver late — a shift offer or an event reminder that lands after the event is worse than nothing.
• Keep a documented cancel path for a send in progress, and test it before you need it.

Delivery receipts tell you less than you think

DLR semantics vary by carrier and route. Some routes return optimistic or synthesised receipts, some return final status late, some return little detail. "Delivered" means a network accepted the message for a handset — not that it was read or acted on.

Measure at the application layer instead:

• Completion of the requested action, and time from send to completion.
• Click-through where you use tracked links, joined to the message by correlation ID.
• Replies, complaints and opt-out rate per campaign and per segment.
• Canonical failure categories — invalid destination, unreachable, blocked or filtered, sender not permitted — rather than a single failure bucket.
• Cost per completed action, using stored segment counts.
• The same outcome metrics compared across routes and providers. That comparison is far more informative than comparing delivery percentages.

Route failure, fallback and duplicate prevention

Routes degrade, and usually partially: one market, one carrier, one sender.

• Detect degradation per route, per market and per traffic class — not just as a global error rate.
• Define fallback as a policy per traffic class: which alternative route, after how long, how many attempts, and whether fallback to another channel is acceptable.
• Prevent duplicates on failover. Generate your own client reference before submission, use provider idempotency keys where they exist, and treat a request timeout as ambiguous — the message may have been sent. For promotional traffic, prefer not resending on ambiguity.
• Make callbacks idempotent and tolerant of duplicates and out-of-order arrival, and reconcile messages stuck in non-final states.
• Decide in advance who is permitted to switch routes mid-send and how the decision is recorded.

A pilot checklist, and when to stop

Before a first significant send:

• A single defined audience with a documented source and per-record consent evidence.
• One traffic class, one sender identity, registration complete for the market.
• Suppression checked by the sending path actually being used.
• Template validated for encoding and segment count against real merge data.
• Branded link domain and a landing page that continues the message.
• Correlation IDs in place from business event through to click.
• Throughput limit known; queue separated; hard delivery deadline set.
• Agreed success metric expressed as a completed action, not as a delivery percentage.
• Named owner for replies and for the decision to stop.

Stop conditions, defined before the send rather than during it: opt-out rate above an agreed threshold for the segment; complaints reaching an agreed count; failure or filtering concentrated in one market or carrier; delivery falling far enough behind that messages will land outside their useful window; any sign of sender or link-domain blocking; or reply volume exceeding what the team can answer. Each condition should name the action — pause, reduce rate, switch route, or halt — and the person who takes it.