From the MMA Best Practices, the source of all the pull quotes in this post:

It is fundamental to the concept of control that a subscriber maintains the ability to stop participating and receiving messages from a shortcode program when desired.

As soon as a user subscribes to your program, you must explicitly tell them how to opt-out, and they must be able to do so at any time. It’s an important measure against abuse, as any ethical marketer would agree.

That said, consider the well-intentioned, but rigidly applied opt-out workflow within a complex chat application. How do we discount the false positives?

The notable stipulation is that “Shortcode programs should support mixed case opt-out commands and ignore subsequent non-keyword text.” Consider the challenges of adhering to these restrictions while building innovative applications.

The CTIA seems to believe that SMS is strictly for coupons, as evinced by their dated use of ‘campaign’ as a catchall term to represent any SMS-driven program. For those of us building real, robust SMS applications (and who consequently take opt-outs more seriously than marketers because it reflects not mere attrition, but a failure of service), it’s an anachronism, if not an insult. A topic for another day.

Keywords you’re required to respond to with an opt-out:

You’re allowed to initiate opt-outs based on other keywords of your choice, but must respond to at least the five keywords above. And, apparently for consistency, you must send an opt-out confirmation message in response to any of these keywords, even if the user isn’t subscribed to any program at all. For instance, a user may text in STOP as their first message to your system and you must send back a proper opt-out response, pretending that everything is normal. The same applies to users texting into a programs that sends only one-time messages. If they text in STOP after that (even though there’s no subscription to end), you must pretend to opt them out. It’s all very Victorian.

Needless to say, but they say it anyway, “The STOP command should never result in an error being sent back to the subscriber.”

A STOP request should result in a message (MT) sent to the subscriber:

…This should not be a premium message. This message should reference the specific program the subscriber has opted-out from. No further messages should be sent to the subscriber from this program, including marketing messages for any related or unrelated programs.

Opt-out confirmation message

Multiple choice menus

For subscribers who’ve opted into multiple programs, a simple STOP request isn’t sufficiently descriptive. Rather than opting them out of all programs at once, you need to present a multiple choice menu.

You are required to present STOP ALL as the final choice in the menu, and respond to STOP ALL at any time by opting users out of all subscribed programs (even if it’s only one, or, as we learned above, none).

The menu need not include:

• “Msg&Data Rates May Apply” – by the way, this copy changes every once in a while, rarely becoming more elegant; classic committee-generated results. At least it’s now standardized across the carriers. It used to be worse.
• Pricing
• Sponsor contact information

Much like the Help menu, this could look like:

Subscribed to multiple programs. Rply w one of the following to stop:
A) First program
B) Second program
C) Another program
or STOP ALL
More, recessmobile.com

A reply with one of the options would return the appropriate opt-out confirmation message. I would suggest accepting anything from “A” followed by any text as well as the words “First program.” If users are going to the trouble of calling up a menu and replying to it, it’s clear that they want out, so make it easy for them. Subscribers who don’t want to be there will cost you more in the long-term and it’s in yours and your users’ best interest to do more than merely follow the letter of the law here.

This isn’t a common worfklow, though. Most systems aren’t sophisticated enough to pick up on these types of open-ended responses, so you’re typically stuck with something that more closely resembles the example in the MMA handbook:

Farm League Baseball: which service to stop?
4 Sports txt STOP SPORT or
4 Horoscope txt STOP HORO

And subscribers would reply with “STOP HORO” to end the Horoscope program. This is just lazy user experience design and engineering, not worthy of being a canonical example. Not to mention that they ignore their own requirement of including STOP ALL as the final option. Quod licet Iovi, non licet bovi.

Additional notes

For those doing IVR (those automated phone trees) opt-ins:

Any IVR system that offers the possibility to opt-in to a mobile service must also offer the possibility to opt-out. This should be available through the IVR, customer service, a web site, or SMS.

And be aware that users will try to opt-out by non-standard means (so much for the universality of STOP). Users text in crazy, crazy things.

Content providers should periodically scan their MO logs for subscribers that are clearly trying to unsubscribe to a service, but are not following the programmed rules. And then take the action to end their subscription based on those MO logs.

Log everything:

The content provider (or the aggregator) should record and store all opt-out transactions.

…

Independent of method of entry (SMS, MMS, Web, WAP, IVR) opt-in and opt-out records – including single, double and triple opt-in records – should be retained from the time the subscriber opts-in until a minimum of six months after the subscriber has opted-out of the program (minimum opt-in archiving period is one calendar year). These records should be made available to the aggregator or carrier upon request.

All references are straight from the MMA guidelines and clarified where necessary.

Your program must respond to requests for help. From the MMA guide:

To help subscribers understand their participation, each program should respond with the program details listed below when the subscriber sends the keyword HELP to the program shortcode if they are only subscribed to one service.

Any time a user texts in “HELP” or “HLP” – HLP is optional, but recommended – to your shortcode, you need to return a message containing the following information (italics from the MMA document):

1. Identify of program sponsor (defined as the program name, company name, or brand associated with the campaign)
2. Customer support info (either a toll-free number or web address). For PSMS campaigns, carriers like to see both. Including an email address is just polite.
3. Service description of program.
4. Service price—For example, $0.99 per mobile originated message; $3.99 per month. This applies largely to Premium campaigns. In this case, we’re using a Standard-rate campaign as an example, which means that while we don’t charge anything, the user’s carrier might, and we have to make that explicit.  Neither the wording or the bizarre capitalization is ours – all courtesy of our friends at the MMA.
5. Opt-out information
6. Privacy statement, if applicable.

The message above, reprinted for easy copying:

Recess – company news alerts. More at recessmobile.com or email help@recessmobile.com.

Txt STOP to end. Msg&Data Rates may apply.

T&Cs: recessmobile.com

Another case to be aware of is when a user is subscribed to multiple programs. In those cases, you need to return a list of choices for them to reply to for more information. The menu doesn’t need most of the information described above. You can leave out:

• “Msg&Data Rates May Apply”
• STOP
• Pricing
• Sponsor contact information

An example menu:

Subscribed to multiple programs. Rply w one of the following for info:

A) First program

B) Second program

C) Another program

More, recessmobile.com

Now, you have to determine how you want to handle replies, which can get tricky. Do you want to accept anything that starts with A, B, or C? Do you accept “First program” as a legitimate response? What if you have other keywords active within the same session which overlap with these answers? Do you iterate your multiple choice list?

Additional information, from the MMA:

• Help messages do not need to contain renewal date information.
• Should there be multiple programs running on the shortcode, the subscriber can be directed to a Web site, WAP site, SMS quiz session, or toll-free number that provides a better customer care experience, as long as basic information about the program is in the help reply message. A help menu is preferred over sending the consumer to these places for help. The help menu content descriptions are outlined above.
• Where there is no shortcode initiating access to the service, help must be provided as a link from WAP payment presentation pages. This page containing help should, at a minimum, identify services that are currently opted into, opt-out (cancellation) information, pricing and payment terms. It is recommended that a PC-accessible web site is provided into which a user entering their cell phone number can retrieve detailed information on all live services provided by that program sponsor.

Outside of what you’re required to do, here are some introductory tips for running a successful campaign.