SMS & WhatsApp

Connecting a Messaging Provider

Messaging is the single outbound path for text and WhatsApp messages — from workflows, from campaigns, and from the platform's own two-factor and password-reset paths.

Where to find it

Architect Panel → Communication:

• SMS & WhatsApp Accounts — the console — providers, credentials and sending numbers
• GOV.UK Notify Templates — template mappings where you send through Notify
• Message Log — every message, its state and its cost

Architect Panel → Activity:

• SMS Log — the platform-side sending record

Seven providers

• AWS End User Messaging SMS — the current AWS route for text.
• AWS SNS — the legacy AWS route, still supported.
• AWS End User Messaging Social — AWS's WhatsApp route.
• Meta WhatsApp Cloud API — WhatsApp direct from Meta.
• Twilio — text and WhatsApp.
• ClickSend — text, and physical letters.
• GOV.UK Notify — text, email and letters for public sector organisations.

Every provider ships disabled and without credentials. Enable the one you use and supply your own — nothing starts talking to an external service because an update was applied.

Setting one up

1. Open Communication → SMS & WhatsApp Accounts and add an account for your provider.
2. Enter the credentials. Use a service identity rather than a personal account — provider credentials tied to an individual stop working when they leave.
3. Configure the sending number or sender ID.
4. Send a test to your own handset before wiring it into anything.
5. Enable the Inbound Message Drain task under Automation → Tasks. Dispatch runs through it, so messaging that appears to do nothing at all is almost always this.

Sender IDs cannot receive

An alphanumeric sender ID — your organisation's name rather than a number — looks smarter and cannot be replied to. It is also not permitted in every country.

If you want two-way messaging, and for casework you almost always do, provision a real number. People reply whether or not you invited them to, and a reply into a void is worse than not offering the channel.

WhatsApp is not SMS

WhatsApp requires pre-approved message templates for anything you initiate, and a session window within which you may then reply freely. Approval takes days, not minutes.

Plan for that: a campaign scheduled before templates are approved simply will not send, and the failure arrives at the worst moment. Get templates approved before you build the process around them.

GOV.UK Notify

If you already use Notify for email, adding text and letters is a mapping exercise rather than a new supplier relationship. GOV.UK Notify Templates maps your platform templates onto Notify's, which is necessary because Notify holds the content its end.

Worked example

A council already sends email through GOV.UK Notify. Adding text is a second account on the same Notify credentials, with the platform's reminder templates mapped to Notify templates. A separate Twilio account with a dedicated two-way number is added for the housing repairs service, because tenants need to reply and Notify's sender does not accept replies. Two accounts, two purposes, separate reporting.

Recommendations

• One account per purpose where you want separate reporting or separate numbers.
• Use a real number if replies matter.
• Get WhatsApp templates approved early.
• Check the trigger before enabling any automated send — a workflow firing on every save of a busy datastore is expensive and irritating in equal measure.

Sending Messages and What They Cost

Once an account is configured, sends come from several places and all land in the same log.

Where to find it

Architect Panel → Communication:

• Message Log — every message, its state, its segments and its cost

Architect Panel → Commercial:

• Campaign Manager — bulk sends to a selected audience
• Campaigns — the campaign records themselves

Architect Panel → Automation:

• Workflow Builder — send actions at a workflow stage

Where sends come from

• Workflows — a send action at a stage. This is how most operational messaging works: an appointment reminder, a status change, a code.
• Campaigns — a bulk send to a selected audience, from Campaign Manager.
• Platform paths — two-factor codes and password resets use the same accounts.

Segments, and why your bill is bigger than you expected

This is the single most useful thing to understand about SMS, and it surprises nearly everyone.

A text message is billed per segment, not per message. A message using the standard GSM-7 alphabet fits 160 characters in one segment. Exceed that and it is split, and concatenated messages carry overhead — so the second segment starts at around 153 characters, not 161.

Worse, a single character outside GSM-7 switches the whole message to a different encoding where a segment holds only 70 characters. The usual culprits are invisible:

• A curly apostrophe pasted from Word instead of a straight one.
• An en dash or em dash instead of a hyphen.
• An emoji.
• A non-breaking space.

One smart quote can therefore turn a one-segment message into a three-segment message and triple the cost of a campaign. The Message Log records the segment count, so check it on a test send before a bulk run.

Delivery is not immediate, and not guaranteed

A message is queued, dispatched, and then reported on by the provider. The states matter and are frequently conflated:

• Queued — accepted by the platform.
• Sent — handed to the provider.
• Delivered — the carrier says it reached the handset.
• Failed — it did not, with a reason.

None of these means read. Build any process depending on a message on the state you actually have — an appointment reminder is a courtesy, not service.

Writing the message

Keep it short, identify yourself, and say what you want. A message that does not say who it is from reads as spam and gets reported, which damages your sending reputation for everyone else on the number.

Include a way to stop. People expect it, the rules generally require it, and it is cheaper than a complaint.

Timing

Do not send outside reasonable hours. A two-factor code at 3am is fine because the user just asked for it. A reminder is arguable. A campaign is not — and where the send is scheduled rather than triggered, constrain the window explicitly rather than trusting whoever sets the schedule.

Worked example

A clinic sends appointment reminders 48 hours ahead from a workflow. The template was drafted in Word and contained a curly apostrophe in "we'll", making every message three segments. Replacing it with a straight apostrophe brought it to one and cut the monthly cost by two thirds, with no change to what the patient reads.

Recommendations

• Test one message and read the segment count before any bulk send.
• Compose templates in a plain editor, not a word processor.
• Never depend on "delivered" as proof anybody read it.
• Constrain sending hours on anything scheduled.

Opt-Outs and Suppression

Suppression is the list of people who must not be messaged. Getting it right is both a legal obligation and what keeps your sending numbers usable.

Where to find it

Architect Panel → Communication:

• Message Opt-Outs — the suppression list
• Received Messages — where stop requests arrive
• Message Log — proof that a suppressed send was not made

Stop requests are automatic

An inbound message saying STOP adds the number to suppression without anyone intervening. That happens whether or not you have configured anything else about inbound messaging — it is not something you have to remember to build.

Suppression is separate from your contact data, deliberately

The list does not live on the contact record. Deleting a contact and re-importing them does not resurrect consent, and it must not.

Re-messaging somebody who opted out because a spreadsheet was re-imported is the classic way an organisation ends up explaining itself to a regulator, and it is entirely avoidable — the suppression list survives whatever happens to your contact records.

Check at send, not when building the audience

Suppression is applied at the moment of sending. You do not need to filter your audience by hand, and you should not try: a campaign audience built with its own exclusion logic will eventually diverge from the real list, and it will diverge silently.

Transactional versus marketing

The rules differ and so should your handling. A two-factor code to somebody who opted out of marketing is normally legitimate; a promotion is not.

Be honest about which you are sending. A message described internally as a "service notification" that exists to encourage somebody to buy something is marketing, and calling it something else in a meeting does not change that.

Review the list

Look at opt-out volumes occasionally. A rise is telling you something about the messages being sent — usually frequency, sometimes tone — and it is far cheaper to learn that from your own list than from a complaint.

Worked example

A housing team runs a rent reminder campaign monthly. Opt-outs rise sharply in month three. The list shows they cluster among tenants already in arrears who were also receiving arrears letters — three contacts a month about the same thing. Reducing the campaign to those not already in an arrears process cut opt-outs to near zero and improved response.

Recommendations

• Never filter suppression by hand. Let the send do it.
• Do not import over the suppression list. It exists to survive imports.
• Separate transactional and marketing sends so consent can be handled differently and honestly.
• Watch the opt-out rate as a quality signal, not just a compliance one.