Customer notifications in October: short links in SMS, SIM checks and Twilio Cohorts

In October several pieces came out about messages to customers: Unisender on links in SMS and B2B mailings, Twilio on SIM swaps, SMS pumping and cohorts for bulk sending, HubSpot on transactional email. For a business owner there are two questions here: what each notification costs, and whether the money will go to fraudsters. In the customer portal of the PDR company in the US notifications go out by push and SMS, so I look at this news from my side.

A link in an SMS and the price of a segment

Unisender on October 20 went over SMS arithmetic: 160 characters in Latin script or 70 in Cyrillic, and a single Russian letter in a Latin text cuts the limit to 70. A long message is split into segments, and each one is billed separately. A link with UTM tags takes from 25 to over 100 characters: the example in the article is exactly 100, which is two Cyrillic SMS before any text. A link split across two messages may not open on the phone. So links are shortened through a short domain.

Unisender on October 24 published the story of a marketer at Micro-IT: emails written in the director's name, the list split by role, reading no longer than two minutes. Average open rate 33 to 35%, up to 47% on segmented emails. After a conference in Minsk, a follow-up email chain brought requests for a trial connection.

Twilio on October 19, in a text about email blasts, advises sending only to a list collected with permission and segmenting from the first email. HubSpot on October 15 separated transactional email from marketing email: an order confirmation or a password reset responds to an action that has already happened. HubSpot advises splitting the sending infrastructure: complaints about a marketing campaign shouldn't delay a password reset, and unsubscribing from ads shouldn't switch off receipts.

SIM swaps, SMS pumping and cohorts

Twilio on October 19 showed in Rust how to find out through the Lookup API whether a number's SIM was changed recently. In a SIM swap the attacker moves the victim's number to their own card and receives their calls and SMS, including one-time codes. Lookup returns the date of the last SIM change and a flag for whether there was a change in a given period, for example 48 hours. Twilio warns that SIMs get changed for honest reasons too, so this signal has to be weighed together with others.

On October 14 Twilio described SMS pumping: fraudsters feed a range of numbers from one carrier into a form that sends SMS and get a share of the traffic revenue. Lead forms, transactional notifications and chatbots are all exposed. Lookup v2 returns a risk score from 0 to 100, and for US and Canadian numbers Twilio doesn't recommend using that score: such fraud is rare there.

Twilio Cohorts has been in private beta since October 14: customer profiles, segments and bulk sending inside Twilio. You pass a single CohortID to the Email API or the Bulk Messaging API, and you don't need to write rate-limited queues on your side.

Example: a car rental and the “your car is ready” SMS

Take a car rental. An hour before handover the customer gets an SMS, “Your car is ready, documents and photos are here,” with a link to the portal. If the link carries 100 characters of UTM and the text is in Cyrillic, the rental pays for two or three SMS instead of one. If the “get a code by SMS” form on the website has no limit, at night someone will pour a range of numbers from one carrier into it, and the SMS bill will grow before the accountant notices. A customer notification is designed like a payment: with a limit, a log and a check of the recipient.

How it works for us

At the PDR company in the US I have been responsible for the server, telephony and documents since 2021, and Twilio is in this project's stack. In 2026 the customer portal appeared: an online timeline for the order, signing a document with a finger, which produces a PDF, photos, push and SMS notifications, in English and Spanish. Notifications are tied to the order, like a transactional email at HubSpot: the action first, then the message. I haven't connected the SIM check or the SMS pumping score in this project. I would add the SIM check where a code from an SMS gives access to money or documents.

For Mailwizz I collected email bounces and a summary by domain into a 26-column table: a rolling seven-day window of campaigns, Hard, Internal and Soft bounces, delivery rate. The “delivered” status there meant only the absence of a bounce, with no confirmation of landing in the inbox. The event-based emails on Mailgun and Apps Script exist as a project design; I haven't tested them in operation.

What I would do

For SMS, get your own short domain and count segments before sending: the text plus the link should fit in one segment.

Separate transactional messages from mailings: a different sender, a different domain or IP, and unsubscribing from ads doesn't touch them.

On every form that sends SMS, put a limit per number and per range, a sending log and a number check through Lookup if your customers are outside the US and Canada.

Store the “delivered” status as the provider's fact, without equating it to “read,” and look at bounces once a week, as in the Mailwizz summary.

I wrote about the log's place in the chain in the article how to reliably connect documents, CRM and tasks. Directions: a CRM connected to the team's work and Google Workspace as a connected working environment. The full project: technical partner to a PDR company in the US; on email there is a project design for emails on Mailgun and Apps Script and the Mailwizz bounce summary. Neighboring reviews: a messenger as a source of leads and the Yandex outage in October and depending on a single window. Earlier I wrote about number validation and campaign readiness before sending SMS. If notifications go out from several services and nobody knows what it costs per month, tell me which events trigger them. Discuss your task.