Handling SMS opt-outs (STOP and START) in Salesforce

What an SMS opt-out is

An opt-out is a person telling you to stop texting them. Carriers and messaging providers expect business senders to honor it straight away, and most people expect the same. Handling it well is part of keeping your numbers in good standing, not just good manners.

Salesforce doesn't give you this out of the box. The standard Contact fields cover email, fax and phone calls (Email Opt Out, Fax Opt Out, Do Not Call), but not text messages, so an SMS integration needs its own record of who opted out. A checkbox on the Contact is tempting and usually wrong:

• Opt-outs belong to a phone number. The same number can sit on a Contact, a Lead and an Account, and a person can have two numbers.
• They can belong to a sender. If you text from several business numbers, you need to know which one received the STOP.
• They need a history. When, how and from where someone opted out, and when and how they opted back in, is the evidence you'll want later.

A useful model stores one row per phone number (in E.164 format) and business number, with the source, the date and any notes.

The standard keywords

Twilio recognizes three families of keywords. They're the de facto standard for US and Canadian business texting:

By default, Twilio also acts on these keywords itself on US and Canadian long code and toll-free numbers: it sends a standard confirmation reply and refuses further messages from that sender to the opted-out number, returning error 21610 if you try. A Twilio Messaging Service can customize the keywords and replies with Advanced Opt-Out.

So why track opt-outs in Salesforce at all? Because Twilio's block only helps at the last moment. Your users need to see an opt-out before they write a message, outreach previews need to leave opted-out people out, opt-outs received on one number may need to apply to others, and requests made by phone or email never reach Twilio.

Whole-message matching

Keyword handling matches the whole message, ignoring case. STOP and stop are opt-outs. Stop please, stop texting me and Can you cancel my 3pm? are not, because the keyword isn't the whole message.

That has two consequences worth planning for:

• Natural-language requests need people. Train the team that reads replies to treat "please stop" or "take me off your list" as an opt-out and record it by hand. Depending on the rules that apply to you, a request in the person's own words may need to be honored just like a keyword.
• Your prompts can trigger keywords by accident. "Reply CANCEL to cancel your appointment" makes a customer opt out of all texts, and "Reply YES to confirm" can opt someone back in. Ask for replies in the customer's own words, or use codes that aren't keywords.

One number or all of them

If you text from more than one business number, such as a sales line and a service line, decide how far a STOP reaches. There are two reasonable policies:

"All numbers" is the cautious default: a person who texts STOP rarely expects a different number from the same company to keep texting them. Whatever you choose, write it down and apply it the same way to people, outreach and automation. Manual opt-outs, taken by phone or email, usually apply to every number.

Opting back in

A person who texts START, YES or UNSTOP to the number they opted out from is asking to receive texts again. Two details matter:

• It applies to the number they texted. If they opted out from two numbers, a START to one lifts only that one.
• A START doesn't undo a manual opt-out recorded for every number after a phone call. Someone should review those, with evidence.

Don't opt people back in on your own initiative, for example because a Contact was imported again from a list. An opt-in should come from the person.

Manual opt-outs and documented consent

People ask to stop in every channel: on a call, by email, at the counter. Those requests never pass through Twilio, so someone has to record them. A good manual process captures the phone number, which numbers it applies to, who recorded it, when, and a note on how the request arrived.

Removing an opt-out deserves more care than adding one. Before you text someone who opted out, you should be able to show that they asked to hear from you again: how, when, and who recorded it. Limit removal to a small group, and keep the history.

Check at request time and again at send time

Messages are often created well before they're sent. A reminder is scheduled on Monday for Friday, an outreach audience is built in the morning for an afternoon send, a recurring outreach runs every week, a flow queues a message during a busy moment. If the person opts out in between, a check made only when the message was created lets it through.

So check twice:

1. When the message is requested, so the user or the flow gets an immediate, clear answer.
2. Right before it's handed to the provider, so anything that changed in between is caught.

Record blocked attempts rather than dropping them silently. An admin should be able to see that automation tried to text an opted-out number, and why it didn't.

Opt-out instructions in outreach

Many senders end marketing and outreach messages with a line such as Reply STOP to opt out. It tells people how to stop, and A2P 10DLC campaign registration asks how people can opt out. The line counts toward the message length: Reply STOP to opt out. is 22 characters plus a line break, which can push a message into a second segment.

Whether you need it on a particular message, and how often, depends on the message type and the rules that apply to you. Many teams include it in the first message to a new contact and in every promotional message.

What software can't do for you

A good integration enforces the rules you set, every time. It can't:

• Decide whether you have consent to text someone in the first place. That's collected and recorded where you capture the number: a web form, a signed document, a conversation.
• Reliably interpret free text. People write "no more please" and "wrong number". Someone has to read replies.
• Know about opt-outs in other systems, such as a previous texting tool or a marketing platform, unless you bring them across before your first send.
• Tell you which rules apply to your messages. Country, state or province, industry and message type all matter.

How ConnectSMS handles opt-outs

ConnectSMS applies the practices above inside Salesforce. It recognizes Twilio's standard keywords when a reply is just the keyword, ignoring case and a trailing period or exclamation mark, and it also honors opt-outs Twilio reports. It doesn't act on HELP, which Twilio answers, and it doesn't detect phrases.

• Always enforced. Opt-outs can't be switched off. They're checked when a message is requested and again before it's sent, for people, outreach, Flow, Apex and REST alike.
• Scope is a policy setting: Block all of our business numbers from messaging that phone (recommended) or Block only the business number that received the STOP.
• START lifts the opt-out for the number that received it.
• Manual opt-outs are added in ConnectSMS Setup under Opt-outs with Add opt-out: a phone number, Stop messages from (all business numbers or one), and a note. Sending stops at once, including queued and scheduled messages.
• Removing an opt-out is for admins and asks How and when did they agree to receive messages again?, with a confirmation that the consent is documented. Consent changes are recorded in the audit log.
• Users see it. The composer shows Opted out: this message can't be sent, the inbox shows the opt-out state, outreach previews count opted-out people separately, and automation gets the error code OPTED_OUT.
• Outreach has an Add opt-out instructions option that adds Reply STOP to opt out. on its own line.

ConnectSMS gives you controls; you remain responsible for consent and for the rules that apply to your messages. Consent and opt-outs in ConnectSMS.