Handset Compliance

The CRM Text SMS API manages compliance for the Developer. But it’s important to understand what the FCC and the Mobile Marketing Association require as rules for proper compliance when using SMS to communicate with consumers. You can read more about the Mobile Marketing Association Guidelines here. For those of you migrating from long codes understand that working with short codes is much different. The carriers maintain strict oversight. Regardless of your previous processes, the CRM Text opt-in process is required.

You can also read more about what the CRM Text SMS API automates here. But the summary is that the CRM Text SMS API automates the compliance guidelines for opting-in that you see below. If a user opts-in via a handset generated keyword, the CRM Text SMS API will fire a compliante opt-in confirmation text message to the mobile subscriber. If a user is opted-in via a non-handset method, the CRM Text SMS API fires a compliant opt-in request text message to the mobile subscriber. The mobile subscriber must reply YES or Y before they can receive further text messages. If they do not, the CRM Text SMS API blocks any messages to that mobile subscriber. Once the subscriber is opted-in, you are no longer required to add the compliant language to your messaging for as long as the subscriber remains opted-in.

Short Code Opt-in Requirements

Users can opt-in to a short code campaign several ways: by sending a text message or opting in from a mobile app (Handset Opt-In), or by signing up on a web site, filling out a paper form, making a verbal agreement, or otherwise opting in without using a handset (Non-Handset Opt-in). In each case, the campaign’s opt-in message flow must meet certain compliance standards set by the wireless carriers.

The following guidelines are based on carrier conditions of short code service and other industry standards. Your company is required to comply with these guidelines in the use of any of CRM Text Solutions products.

Subscriber Initiated Handset Opt-in (Single Opt-in)

When a user signs up from a mobile handset, a double opt-in process is advised, but not required. A compliant message flow should look like this:

End User: {Keyword}
Short Code: You Opted-in to {Store Name} {Program Name}!
Msg&data rates may apply.
{Message frequency}
Reply HELP for help, STOP to cancel.

The “program name” should be a single word to define the kind of alerts, e.g. “Account Alerts,” “News Alerts,” “Coupons” etc.

The message frequency must be specific, but can be any interval, for example: “1 msg/day,” “4 msgs/month,” “2 msgs/transaction,” etc. If the message frequency will vary based on user interaction, “1 msg/user request” is standard.

Non-Handset Opt-in (Double Opt-in)

When a user initially signs up by any means other than from a mobile handset, or when express written consent isn't available, a double opt-in process is required. A compliant message flow should look like this:

Short Code:{Store Name} {Program Name}.
Reply YES to opt-in.
Msg&data rates may apply.
{Message frequency}
Reply HELP for help, STOP to cancel.
End User: Yes
Short Code: You Opted-in to {Store Name} {Program Name}!
Msg&data rates may apply.
{Message frequency}
Reply HELP for help, STOP to cancel.

Help Message

An opted-in subscriber can get help by texting HELP to the short code they are opted-in too.

End User: Help
Short Code:{Store Name} {Program Name}!
Msg&data rates may apply.
{Message frequency}
STOP to cancel.

You can manage and edit your compliant opt-in templates in the CRM Text SMS API interface here.. We advise not doing so. Keep in mind that every opt-in keyword you create within each store will use the assigned store opt-in/out, STOP and HELP templates in the store interface. Methods to edit the templates via API exist but are unpublished. If you would like access to these methods email support.