Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/how-to-register-for-a-united-states-us-sms-short-code-with-aws-end-user-messaging/

Obtaining and using SMS short codes in the United States requires a thorough understanding of the detailed application process and strict requirements set forth by mobile carriers. This comprehensive guide walks through the step-by-step procedure for registering a US SMS short code from AWS End User Messaging, which provides SMS capabilities to all AWS services.

This guide covers the process from initial creation of a support case, the short code application form with all necessary details and documentation, and the multi-stage provisioning process involving carrier review and approvals. Particular emphasis is placed on establishing compliant opt-in workflows, crafting SMS-specific terms and privacy policies, and preparing the required message templates – all of which are closely scrutinized by the carriers.

While the application process may be time-consuming, the benefits of using a short code, include:

• High throughput – They start out at 100 messages per second
• Ability to scale to thousands of messages per second
• Higher deliverability rates – Because of the increased upfront scrutiny in the registration process they have less issues with filtering and blocking. Critical use cases such as One-Time Password(OTP)/Two-Factor Authentication(2FA) are use cases that, even if you don’t need the high throughput, you may want to consider using a US short code to deliver them in the US
  • Short codes investigate issues before blocking through proactive audits, while other registered originator types such as toll-free or 10DLC block/filter first and investigate later when issues arise
• Easy for customers to remember and identify – Short codes are 5-6 digit numbers, which is easier for recipients to remember than 10+ and lends credibility and trust to your message

The US Short Code Application Process

Step 1: Create a Case in AWS Support Center

Currently short codes are only available by opening a case. The first step to register a short code is to open a short code request case in the AWS Support Center, providing detailed information about your use case and opt-in policies. A request must be opened for each country in which you want a short code. Each country has their own registration process and requirements so if you are registering for other countries besides the US having a case for each allows for much easier tracking and updating as there are communications going back and forth between you, the customer, support, and any downstream clarifications that may come back.

NOTE: If you require a HIPAA eligible Short Code for your use case please respond to the case with explicit confirmation that you require a HIPAA eligible Short Code. We will provide you a unique form for this use case

Along with attaching the correct form Support will request that you confirm that you understand the pricing, billing, and time frame of this request so make sure that you respond to the case, don’t just start on the application.

Step 2: Complete the Short Code Application

We will walk through the US Short Code application in detail below. Make sure that everything you submit is 100% correct to your knowledge, as any missing information or information that needs to be corrected extends the time it takes to receive your short code.

NOTE: Application forms are occasionally revised to clarify or add to existing information. By the time you read this post, the form that you receive might differ slightly from the form that we review in this post.

The first section of the US Short Code form contains basic information about your company.

Company Information

Most of the fields in the first section are straightforward but the key thing to make sure you have a good understanding of is, who owns the relationship with the recipients? The company that owns the opt-in data and controls the message(not just the delivery) is the company that needs to have their information submitted.

IMPORTANT: If you are a SaaS/mutli-tenant/service provider, providing SMS capabilities to YOUR customers or a business within a larger portfolio make sure that you are clear on that. It does not matter WHERE the opt-in is happening, it matters who owns the data and the clear relationship between that entity and the recipient. The company that owns that relationship is the company who’s information needs to be used.

There are a few fields in this section that people ask how they will be used:

Primary Contact name, email address, phone number

These contact details will be used during the Company vetting/validation step we will discuss later in this post. It would also be used to contact you if there is ever an audit of your short code.

Customer Care Information

The customer care contact points are required to be actively monitored.

Customer Care URL

The URL of a page where your customers can go to find information about contacting your Customer Support team.

Customer Care Email

The Carriers require you to provide an email address that customers can contact if they have questions about your short code messaging program. This address should be a shared mailbox or distribution list (such as [email protected]) rather than an individual person’s email address and must match the domain of the Company URL in the Company Information section above.

Customer Care Phone Number

Like the support email address, customers should be able to call this phone number to get support for your short code messaging program. The phone number doesn’t have to be a toll-free number, but it does have to be a US-based phone number.

Short Code Service Information

AWS Region

The AWS Region that you use AWS End User Messaging in. If you’re not sure, check with the person or team within your organization that is responsible for managing your AWS accounts.

IMPORTANT: Short codes can only be used in the region that they are requested in and cannot be moved. Short codes can be shared to other accounts via Resource Access Management but they must be in the same region. All resource billing, such as the shortcode monthly leasing fee, will still run through the managing account but the cost for SMS volume will be charged to the sending account.

Short Code Option

In the US you have the option of either a 5-6 digit random code or a “vanity” code that you can specify. These vanity codes are numeric only, take longer to procure, and come with a higher cost. You can check if your preferred vanity code is available at: https://www.usshortcodes.com/find-short-code

Short Code Use Case

Mobile Carriers need to know how you plan to use your short code, and how you will interact with users. It is very important to be clear and concise in this section. Humans are reviewing these so make sure that everything you write can be understood without any prior knowledge of your company or your use case.

Company Overview

Provide a short description of the products/services that your Company provides to its customers. This should concisely answer the question, “Who are you and what do you do?”

Service Name

A name or phrase that identifies your messages as being from you. Service names typically are a recognizable form of your company or brand name. It can be a shortened version as long as it is something that your recipients would recognize as coming from you.

• For example, if Example Corp. wants a short code for sending account-related notifications, they could use a service name like “Example Corp.” The Carriers require you to put this service name at the beginning of each message. Keep in mind that SMS has a limit of 160 characters so you do want to keep this short.
• A message might look like this:
  “Example Corp. – This is an account notification for your account #[XXXXXX].”

Message Type(s)

You can choose more than one message type but keep in mind that for each message type that you select you will need to provide examples of those types of messages later in the form and you also need to collect consent for each one. We recommend to not mix promotional and transactional type messages on a single code but at the time of publication this is acceptable by the carriers.

Message Examples

You need to provide at least ONE message example for each of the message types you chose above. Carriers will review these examples during the approval process. These are only examples and will not be the only messages you will be able to send but they should represent all of the types of messages that you plan on sending. If you need more room it is fine to add more examples. Remember you do NOT need to include every message you plan on sending, as long as you have a representative sample of all message types.

• Requirements:
  • Include your service name in every message sample
  • Ideally each message is 160 characters or less to reduce your costs. Any message over 160 characters is broken into message parts in 160 character chunks and each message part is charged. 161 characters would be two message parts
    • If your message uses only characters in the GSM 03.38 character set, also known as the GSM 7-bit alphabet, it can contain up to 160 characters. If your message contains any characters that are outside the GSM 03.38 character set, it can have up to 70 characters. When you send an SMS message, AWS End User Messaging SMS automatically determines the most efficient encoding to use. We provide a tool in the AWS console to check your messages.
    • If your messages will include variables, it’s fine to use either placeholder values or variables.
      • For example, both of the following are acceptable: “Hello John. Your one-time password is 654321” and “Hello [first_name]. Your one-time password is [otp code] .”
    • Do not use unbranded link shorteners i.e., “bit.ly/yourlink”
      • If you have to use a shortener make sure that it is branded and that there are not multiple redirects. Also make sure to provide examples of the branded shortened domain so that it is on file with the carriers
  • Include an example of all of the message types you are registering for
  • If you plan on sending in languages other than English, include those versions
  • Read them all and make sure that they are clearly a part of the message type/use case that you are registering for
• If you plan on sending Multimedia Messages(MMS) make sure you include at least one example

Multimedia message sample (MMS)

MMS capabilities must be requested at the time the short code is requested. If you intend to send MMS messages make sure you check the box and include a message example in the section above

Will you use your short code for any of the following?

Selecting “Sweepstakes or contest” or “Debt Collection” will require more documentation. For example, official sweepstakes rules and terms would be requested if that was your use case. If neither of these apply then select “N/A”

NOTE: Debt collection in particular is highly regulated. If you are a 3rd party debt collector you will not be able to get a short code.

Per-user message frequency

This is an estimate but will be used later in some of the message templates so be sure to have this correct. Will you be sending out 1 message per day? Week? Month? Programs like Two Factor Authentication(2FA) or One-Time Password (OTP) are examples of “message frequency varies” or “1 message per login”.

Carrier requirements for user sign-ups

The core requirement for communicating with SMS is explicit consent – end users must have the option to consent to receive your messages, know exactly what the program will include, and are able to opt-out or ask for help at any time. There are no exceptions to this regardless of the use case or your business type. As a reminder, Carriers make their own rules which will override things like FCC exemptions.
The Carriers pay extra attention to the information provided in the following section, so be thorough and follow the guidelines provided. An in-depth review of how to build a compliant SMS opt-in process can be found here.

How the User will opt-in

There are lots of compliant ways to capture an opt-in. Choose the option that applies to your use case. It’s fine to choose more than one option. However, you must provide mockups of the opt-in workflows for all of the options that you select. Be prepared to provide a verbal script for any opt-in processes where the user does not have the written call-to-action and SMS disclosures in front of them to read. Examples include:

• Sending a keyword to your short code
• Website or mobile app
• Over the phone/In-Person
• Paper forms
• Other – Which you will need to explain in detail. As long as you can be compliant, it should be accepted

User Experience Flow

This is one of the most comprehensive parts of the form and where many customers tend to receive a lot of feedback because there are several things that MUST be included in this section and there are no exceptions. Below you will find a list of the required components and descriptions of each. Keep in mind that these can be written or verbal opt-ins but this does not change the below requirements. Keep this concise, only detailing the opt-in process and nothing else.

• The Opt-in location must include the following:
  • Program (brand) name
  • A call-to-action phrase like “To receive SMS account notifications from [SERVICE NAME], enter your mobile number below”
  • You must expressly collect consent for each use case(s) that you detailed above. A single checkbox for all use cases will not be approved.
    • For example, If you are sending account notifications and OTP you must have two separate statements such as:
      • “To receive SMS One Time Password notifications from [SERVICE NAME], check this box and enter your mobile number below.”
      • “To receive SMS account notifications from [SERVICE NAME], check this box and enter your mobile number below.”
  • The opt-in must be “explicit” this means that any checkboxes, radio buttons, etc. must be left unchecked or at least not defaulted to SMS if you have options. If it is a verbal script then there must be a verbal consent given and you should track the date of that consent. If it is written then the recipient must sign and date the consent.
  • You must supply a secondary channel such as email. SMS must be optional and another option must be provided. This is mandated by Verizon in the US.
  • Link to a publicly accessible Terms & Conditions page
    • We will detail what needs to be included later in this guide
  • Link to a publicly accessible Privacy Policy page
    • We will detail what needs to be included later in this guide
  • Message frequency disclosure
    • Same as stated earlier in this application
  • Customer care contact information
    • Email address, phone number, Text “Help”, are all valid
  • Opt-out information
    • You must support the “Stop” keyword along with this list of keywords that can be found here
  • “Message and data rates may apply” disclosure.
    • This must be verbatim

This must be explained for each process that you checked in the “How the user will opt-in” section. If you are using a keyword and also have the ability to opt-in from your website or mobile app for example, then both of those processes need to be documented here.

If you are using a paper form or a verbal opt-in all of the required components must still be present. If verbal, components such as the Privacy Policy location must be read back to the person opting in. If written, then the full URL needs to be present. Regardless of your process you must include all of the components for you to be approved.

Opt-In Mockup

This is where you can supply screenshots if the opt-in location is online. You can also provide the verbal script or written opt-in form here as well. Make sure that the Opt-in mockup exactly matches the above requirements and that you explain the process.

Example of an online form

Terms and Conditions URL

This is the URL where your SMS-specific Terms and Conditions document resides, or where it will reside. You can also include a link to your standard Terms and Conditions page, as long as it includes a section dedicated to SMS messaging. If those terms and conditions aren’t live yet, or are not available online, you must include a copy of the Terms and Conditions along with your completed application. There are boilerplate items that MUST be included here with no exceptions, see here for more detail and below for those items:

1. {Program name}
2. {Insert program description here; this is simply a brief description of the kinds of messages users can expect to receive when they opt-in.}
3. You can cancel the SMS service at any time. Just text “STOP” to the short code. After you send the SMS message “STOP” to us, we will send you an SMS message to confirm that you have been unsubscribed. After this, you will no longer receive SMS messages from us. If you want to join again, just sign up as you did the first time and we will start sending SMS messages to you again.
4. If you are experiencing issues with the messaging program you can reply with the keyword HELP for more assistance, or you can get help directly at {support email address or toll-free number}.
5. Carriers are not liable for delayed or undelivered messages
6. As always, message and data rates may apply for any messages sent to you from us and to us from you. You will receive {message frequency}. If you have any questions about your text plan or data plan, it is best to contact your wireless provider.
7. If you have any questions regarding privacy, please read our privacy policy: {link to privacy policy}

Privacy Policy URL

Message Senders are responsible for protecting the privacy of Consumers’ information and must comply with applicable privacy law. Message Senders should maintain a privacy policy for all programs and make it accessible from the initial call-to-action. The privacy policy should be labeled clearly and privacy policy disclosures must provide up-to-date, accurate information about program details and functionality. For verbal scripts, a URL must be read off to the end-user enrolling in the SMS program, or the comprehensive terms or link to those terms must be directly included in the script.

• One of the key items Carriers look for in a Privacy Policy is the sharing of end-user information with third-parties. If your privacy policy mentions data sharing or selling to non-affiliated third parties, there is a concern that customer data will be shared with third parties for marketing purposes and your registration could be rejected at worst or delayed while you explain or update your Privacy Policy.
• Express consent is required for SMS; therefore, sharing data is prohibited. Privacy policies must specify that this data sharing excludes SMS opt-in data and consent. Privacy policies can be updated (or draft versions provided) where the practice of sharing personal data to third parties is expressly omitted from the number registration. You can include an SMS specific section within your privacy policy if your company or business model requires data sharing. This part is non-negotiable and Carriers are incredibly strict about this requirement
  • Example: “The above excludes text messaging originator opt-in data and consent; this information will not be shared with any third parties.”

Confirmation SMS / Double Opt-In

A confirmation message is the message sent when someone opts into your program. It is required you send your customers an opt-in confirmation message. It is optional, but a best practice, to include a “Double Opt-In,” such as the example below, asking the recipient to text back a confirmation to prove “humanness” and also validates your end user provided you with their correct phone number

There is one exception to the above if your use case is an OTP/2FA. In this one instance, the OTP code that you send to your recipients is considered a confirmation. You MUST however, still opt them in initially, adhering to all of the prior requirements we have detailed in the above sections.

This message must include the following in 160 characters or less:

• The service name that you specified earlier in the application
• The phrase “message and data rates may apply”
• Information about how often recipients will receive messages from you (such as “up to 30 messages per month” or “message frequency varies”)
• Information about getting help (typically, something similar to “Text HELP for more info”)
• Information about opting out (typically, something similar to “Text STOP to opt out”).

Example Message:

• “Welcome to AnyCo! Reply “YES” to confirm your subscription and get special offers once a month. Msg & data rates may apply. Text ‘STOP’ to opt out.”
  • It is best practice, but not required, to do a “double opt-in” as seen in the example where the recipient will text back “YES” to confirm that they did want to register.

HELP Response

The “Help message” is the response that is required to be sent to end-users when they text the keyword “HELP” (or similar keywords). The purpose is to provide information to the end-user related to how they can get support or opt-out of the messaging program.

• The message must include:
  • Program (brand) name OR product description
  • A method of contacting your support organization. Email addresses, websites, and phone numbers are all acceptable methods of communication. We recommend that you include two contact methods in your response (such as a phone number and a website).
• The following is an example of a HELP response that complies with the requirements of the US mobile carriers:
  • ExampleCorp Account Alerts: For help call 1-888-555-0142 or go to example.com. Msg&data rates may apply. Text STOP to cancel.

STOP Response

The “Stop message” is the response that is required to be sent to end-users when they text the keyword “STOP” (or similar keywords). End-users are required to be opted out of further messages when they text the STOP (or equivalent) keyword to your number and confirms with them that they will no longer receive messages for the program.

• The message must include:
  • Program (brand) name OR product description
  • Confirmation that no further messages will be delivered
• The following is an example of a compliant STOP response:
  • You are unsubscribed from ExampleCorp Account Alerts. No more messages will be sent. Reply HELP for help or call 1-888-555-0142.

Step 3: Submit the Application and Supporting Documents

Attach your completed application to your AWS Support case. Make sure to monitor this case daily as there can be clarifications that are needed or additional information and any delay can cause substantial delays in receiving your short code.

NOTE: Billing for short codes starts at the time the application is submitted to be reviewed, which is before the short code is registered for use. We will let you know when that review period begins.

Step 4: Documentation Pre-Review

Your documentation will be reviewed prior to submitting it to the Carriers. This does not guarantee that there will be no questions/revisions but it does make step 6 more efficient as there should be less potential questions from the Carriers. Once your documentation is considered compliant your company will be submitted for vetting.

Step 5: Vetting

This is similar to a credit check process where your data will be validated by a third-party and you will need to prove you are a member of your company through a domain validation email.

Example email for vetting

Step 6: Resolve Follow-up Issues

Respond promptly to any questions or concerns raised during the review process. Make sure to monitor this case daily as there can be clarifications that are needed or additional information and any delay can cause substantial delays in receiving your short code.

The Provisioning Process – Post Approval

After approval, Carriers begin setting up your short code on their networks. This process typically takes 6+ weeks to complete across all US carrier networks. This is a part of the overall timeline given.
Expected sequence of events for Carrier Review

1. The Carriers will review your application. We’ll answer any questions/corrections requested by the aggregator or the Carriers for your application. You may need to provide additional information.
2. The Carriers will connect the short code to their network for testing. Each carrier will approve your application and provision on their network.
3. We will send you a confirmation that your short code is ready and activated in the End User Messaging service once all Carriers finish their approval and provisioning process. This process is only as fast as the slowest carrier approval.

What happens if I don’t complete these steps or if I need to change something?

Customers sometimes ask what would happen if they didn’t implement all of the requirements that are discussed in the preceding sections. If your application for a new short code doesn’t meet these requirements, the answer is simple: the Carriers will reject your request for a short code. These carrier-imposed requirements are not optional.

If you submit an application that meets all of the carrier requirements and you are approved but your real-world production use case doesn’t meet those requirements, there could also be consequences. The Carriers periodically perform audits of short codes to ensure that they are being used in a compliant manner. You can review the process here in the CTIA Short Code Monitoring Handbook If they find that your opt-in process differs greatly from what you showed in your short code application, or your use case is different than what you registered for they could pause your short code’s ability to send messages on their networks. Remember, one advantage of using a short code compared to other originator types is that, because of the increased scrutiny for being approved, when this happens, the Carriers typically provide some time to remedy the issue, rather than just block your messages without warning.

We will alert you if there is an audit of your short code and advise you on what changes/additions need to be made in order to remain within compliance and continue sending via your short code.

What do I do if I need to make edits to my registration after it is approved?

It’s OK to make minor edits such as correcting typos, clarifying text, or using a variation of a message template that was already approved after you receive your short code. Remember it is critical that you do not deviate from the use case that you registered for, short codes are periodically audited, and deviating from the use case in your application could lead to your short code being suspended if you do not respond and comply with the requests. When in doubt, open a case and request that support reviews your change, prior to making it, to determine whether you can launch the new template/process without risking an audit.

If you need to make substantial changes to these templates after you receive the short code, you may need to submit your updated message templates to the carriers. Substantial changes could include the following:

• Changes to the brand name that appears on your messages (for example, if your company rebrands under a new name, or is acquired by another company).
• Changes to the use case (for example, if your application specified a one-time password use case, but you start sending account notifications through the same short code). This type of change might require you to re-collect consent from your customers before you start sending the new type of messages.

In these situations, you should open a case with AWS Support. We will work with the Carriers to have your short code registration information updated or depending on the change, you may need to register for another short code.

Conclusion

Obtaining and utilizing SMS short codes in the United States is a complex and highly regulated process that requires meticulous attention to detail. However, the benefits that short codes offer – such as high throughput, enhanced deliverability, and strong brand recognition – make them a valuable communication tool for businesses that need to engage customers at scale through SMS.

The key to successfully navigating the short code application and provisioning journey lies in proactively planning and preparing. By thoroughly understanding the carrier requirements upfront, companies can avoid common pitfalls and delays that often plague short code implementations. This includes thoughtfully designing compliant opt-in workflows, crafting robust terms of service and privacy policies, and developing a comprehensive set of message templates that align with approved use cases.

While the investment of time and resources may seem daunting, the long-term advantages of leveraging a short code make it a worthwhile endeavor. Short codes instill a sense of trust and familiarity with customers, allowing businesses to stand out in a crowded messaging landscape. Moreover, the rigorous vetting process ensures that only legitimate players gain access to this high-value communication channel, protecting consumers from spam and fostering a healthy ecosystem.

Ultimately, the decision to pursue a short code should be made with a clear understanding of the commitment required. However, by leveraging the guidance and best practices outlined in this comprehensive guide, companies can navigate the complexities with confidence and position themselves for success in delivering impactful, high-performing SMS campaigns that drive meaningful engagement and business outcomes.

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/a-guide-to-optimizing-sms-delivery-and-best-practices/

If you’re sending critical SMS messages to your users including one-time passwords (OTP), appointment reminders, urgent alerts, and marketing messages, you know how important reliable delivery is. SMS has become the backbone of modern business communications, and for good reason. Its ubiquitous nature and high engagement rates make it the go-to channel for reaching users globally.

But here’s the thing. As your messaging volumes grow and you rely more heavily on SMS for critical communications, you might notice that not every message gets delivered exactly as planned. And that’s normal across the entire telecommunications industry. In fact, expecting 100% delivery rates for SMS messages is like expecting every flight to arrive exactly on time. It’s simply not realistic given the inherent complexity of global telecommunications networks and systems. This isn’t unique to any particular messaging provider. It’s the nature of SMS delivery itself. Don’t worry, you’re not alone. Let’s dive into why this happens and show you how to build a rock-solid messaging strategy that works for your business.

In this post, we’ll explore what really happens when you send an SMS, share practical monitoring techniques that go beyond basic delivery receipts, and show you how to build redundancy into your messaging architecture. By the end, you’ll have the knowledge and tools to optimize your messaging operations using AWS End User Messaging.

Understanding SMS Delivery Complexities

Have you ever wondered what happens when you hit send on that crucial OTP message or important customer alert? The journey your message takes is more complex than you might think. Let’s break it down.

Your message begins its journey through a network ecosystem that involves multiple carriers, systems, and devices before reaching your end user. While this might sound daunting, AWS End User Messaging works continuously to optimize and simplify these delivery paths and maintain strong relationships within the messaging ecosystem.
So what makes SMS delivery so complex? Think of it like air travel – even with the best airlines and optimal conditions, various factors can affect whether a flight arrives exactly on time. The same is true for SMS messages.

Network infrastructure plays a crucial role. Just as flights navigate through different airspaces, your messages traverse carrier networks to reach their destination. AWS End User Messaging actively participates with SMS providers, carriers, and regulators to ensure up-to-date compliance and optimal delivery performance. However, just like air traffic control might need to redirect flights, message routing isn’t always straightforward. Network congestion, carrier maintenance (both scheduled and unplanned), country regulatory changes, and handset network availability, can occasionally affect message routing.

Carriers add another layer of complexity. Each carrier has its own set of rules and policies – think of them as different airports with their own specific regulations. They implement various filtering and anti-spam policies, handle message queuing differently, and may occasionally block messages without proactive notice if they detect suspicious patterns or unusual volumes. This is actually a good thing – it helps protect users from fraud, even though it can sometimes affect legitimate messages.

Then there’s the final destination – the end user’s device. Even if your message successfully navigates the network and carrier challenges, the recipient’s phone might be turned off, in an area with poor coverage, or simply out of storage space. It’s similar to a passenger missing their flight because their vehicle broke down on the way to the airport. Like the passenger, SMS connections may be lost due to local transportation issues at their destination.

This is why focusing solely on delivery reports doesn’t tell the whole story. For instance, you might receive a successful delivery receipt from a carrier, but the end user’s phone could be in airplane mode. Or conversely, a message might show as undelivered in carrier reports, but the user actually received it after a slight delay.

Understanding these complexities helps explain why achieving 100% delivery rates isn’t realistic. Instead of pursuing perfect delivery rates, successful messaging strategies focus on multiple factors:

• Building comprehensive monitoring systems,
• Following messaging content best practices (such as using Global System for Mobile Communications (GSM) characters,
• Maintaining appropriate message lengths,
• Following URL best practices
• Ensuring compliance with carrier requirements
• Providing alternative delivery channels.

Next we will dive deeper into some of these and explore how to set up effective monitoring practices that give you real insight into your message delivery success.

The Reality of Delivery Rates

Let’s address something important: if you’re expecting 100% delivery rates for your SMS messages, you’ll need to adjust those expectations, as this is not the reality of the industry. This is true regardless of which messaging provider you use – it’s simply the nature of how SMS works within global telecommunications networks. Even in optimal conditions, various factors can affect delivery:

• Network conditions in different countries
• Carrier policies and filtering systems
• End-user device states
• Local regulations and requirements
• Natural or infrastructure disruptions (for example: cable cuts, wildfires, tsunamis, or other environmental events)

Think of it like this: even the world’s most reliable airline can’t guarantee every flight will arrive exactly on time. Weather patterns change. Airports face congestion. Maintenance needs arise unexpectedly. SMS delivery navigates similar real-world challenges.

What matters is understanding what “good” looks like for your specific use case. Just as an 85% on-time arrival rate might be excellent for flights in winter conditions but below average in clear weather, a 95% SMS delivery rate might be excellent in one country but below average in another. This is why establishing baseline metrics for different regions and message types is so crucial.

Strategies for Reliable Delivery

Now that we understand why 100% delivery isn’t realistic, let’s talk about strategies to maximize your success rates.

The Art of the Retry

When a message doesn’t get through, having a retry strategy is crucial. But it’s not as simple as “try, try again.” You need to be thoughtful about:

• How long to wait between attempts
• How many times to retry
• When to switch to a different channel
• The cost implications of your retry strategy

Think of it like following up on an important email – you wouldn’t send the same email every 5 minutes, but you might try different approaches over time.

Important Anti-Abuse Note: Always implement reasonable limits on your retry features. This prevents both intentional and unintentional abuse of the system, ensuring fair usage and maintaining the integrity of the service for all users.

This retry strategy forms just one part of a comprehensive approach to reliable message delivery. Later in this post, we’ll explore how to build additional resilience through multi-channel messaging strategies that give you multiple paths to reach your users.

Establishing Effective Monitoring Practices

Let’s talk about what really matters: knowing if your messages are actually reaching your users. Sure, carrier delivery receipts are useful, but they’re just one piece of the puzzle. Just as airlines don’t rely solely on flight trackers to measure success, you need a more comprehensive view of your messaging performance.

So how do you get the full picture? It starts with understanding what “normal” looks like for your messaging patterns.

Getting to Know Your Baseline

Just like you know your typical website traffic patterns or customer service volume, you need to understand your typical message delivery patterns. What’s a normal delivery rate for messages to India versus messages to the United States? How do your success rates vary between weekdays and weekends? What about during peak shopping seasons?

This baseline knowledge becomes your compass – helping you quickly spot when something’s not quite right. But how do you build this understanding? This is where AWS End User Messaging Message Feedback API comes in handy.

Putting the Message Feedback API to Work

Here’s the thing about carrier delivery receipts: they can take up to 72 hours to arrive and will vary by country. That’s like waiting three days to know if your customer got their one-time password! Instead of playing this waiting game, you can use the Message Feedback API to gain real-time insights into message delivery.

Let’s say you’re sending OTP codes. When a user successfully enters their code, that’s a clear signal they received your message. With the Message Feedback API, you can record this action, marking the message as successfully delivered. Not only does this give you immediate feedback, but it also helps build a more accurate picture of your actual delivery success rates.

But what about messages that don’t get a response? After an hour without user interaction, the Message Feedback API will mark these messages as failed. This helps you maintain accurate metrics and quickly identify potential delivery issues.

Building a Complete Monitoring Strategy

Your monitoring strategy should be like a flight operations center, combining multiple data sources and ready to respond to changing conditions.

Message Feedback Data: This is your real-time insight into user interactions. Are recipients completing the actions your messages are meant to trigger? Are OTP codes being used? Are links being clicked?

CloudWatch Metrics: Set up alerts that make sense for your business. If your typical OTP conversion rate is 85%, you might want to know if it suddenly drops below 80%. Remember, these aren’t perfect numbers, and they’re not meant to be. Different messages might need different thresholds. What’s acceptable for a marketing message might not be acceptable for a security verification code. The key is understanding your normal delivery rates and monitoring for significant deviations from that baseline. See here for more information on setting up CloudWatch for End User Messaging.

User Behavior Patterns: Pay attention to how users interact with your messages. Are certain types of messages more successful than others? Do some regions consistently show different patterns? This information is gold for optimizing your messaging strategy.

The key is to look for patterns. Maybe your delivery rates dip at certain times of day, or perhaps specific types of messages have lower success rates. These patterns help you adapt and improve your messaging strategy over time.

Remember, monitoring isn’t just about catching problems. It’s about understanding your messaging ecosystem and continuously improving it. When you do spot an issue, you’ll need to know how to investigate and resolve it quickly.

Investigation and Troubleshooting Strategy

Even with the best monitoring in place, you’ll occasionally run into delivery challenges. Just as airlines have procedures for investigating flight delays, you need a systematic approach to investigate and resolve messaging issues quickly.

Spotting the Signs

Just as air traffic controllers monitor multiple indicators for potential issues, your messaging system has key indicators that signal when something needs attention; your most reliable indicators come directly from your customers’ experiences:

• A sudden drop in OTP conversion rates
• An uptick in customer complaints about missing messages
• Unusual patterns in your message feedback data
• Spikes in failed delivery attempts

Customer-driven signals are your most accurate indicators of messaging health. When these metrics change significantly, particularly in one-time password (OTP) conversion rates and customer complaints, it’s crucial to investigate the underlying causes and understand their impact on user experience.

Playing Detective

When you notice something’s off, start by narrowing down the scope. AWS End User Messaging provides detailed event data that helps you investigate delivery issues. Let’s look at what information you have at your fingertips:

Message Events contain crucial investigation data like:

• Country (isoCountryCode): Which countries are affected?
• Carrier information (carrierName): Is this specific to certain carriers?
• Timing (eventTimestamp): Are issues occurring at particular times?
• Message status and description: What’s happening with the message?
• Message type and encoding: Could content formatting be a factor?

Some of the most important things to configure in End User Messaging are Event Destinations. For an in-depth post on how to configure these read here. Here’s an example snippet of a delivery event that you might receive that helps paint the picture:

Understanding these events helps identify patterns. Maybe you recently changed your message templates, or perhaps you’re sending higher volumes than usual. These could be important clues to investigate.

When to Call in AWS Support

Time is crucial when investigating SMS issues. For ongoing problems, carriers need recent examples – ideally messages sent within the last 48 hours. This allows them to investigate current network conditions and message flows.

Even for historical issues that are no longer occurring, fresh data is still required for investigations. If you’re reporting a past problem, try to provide the most recent examples possible. Be aware that if an issue is too old, providers may be unable to conduct a root cause analysis due to log retention policies and other limitations.

The SMS ecosystem involves multiple third parties, each playing a role in message delivery. Investigating issues often requires coordinating with these various entities, which can extend the time needed to determine the root cause. In some cases, if the issue is old enough, a complete analysis may not be possible.

Prompt reporting is key. The sooner you alert us to an issue, the better chance we have of gathering relevant data and working with carriers to resolve the problem or provide meaningful insights.

If you spot significant issues and you have AWS Premium Support (a paid service that provides additional assistance), don’t hesitate to contact them. But here’s the key to getting quick results: provide comprehensive information. Remember that “my message didn’t deliver” isn’t nearly as helpful as “we’ve seen a 20% drop in OTP conversion rates for messages to Country X over the past 4 hours, affecting approximately 1,000 messages. Here are message IDs to investigate.”

What is Required by Support to Help You:

• Country having SMS issues
• Clear data showing the scope of the issue
• Multiple example message IDs and phone numbers that reflect the scale of the problem:
  • For widespread issues affecting thousands of messages, provide dozens of examples
  • For regional issues, include examples from different affected areas
  • For carrier-specific problems, include examples across affected carriers
• Dates and times for when the issue started and any patterns you’ve noticed
• Relevant message feedback data

The affected downstream carrier and our support team requires detailed information to help resolve delivery problems. A few example numbers aren’t enough if you’re seeing a widespread issue. The scale of your evidence should match the scale of the problem.

Investigating Issues Without Premium Support

Even without Premium Support, you have powerful tools at your disposal to investigate and resolve many issues:

• Leverage CloudWatch Metrics: Set up detailed alarms to catch issues early. Monitor trends in delivery rates, user engagement, and error types.
• Analyze Message Feedback Data: Use the Message Feedback API to gather real-time data on message delivery and user interactions. This can help you pinpoint where in the delivery process issues are occurring.
• Review AWS End User Messaging Documentation: Check out our Best Practices guide for proactive measures you can take.
• Use AWS Forums and Communities: Connect with other AWS users who might have encountered similar issues. Our community forums are a great place to share experiences and solutions.
• Implement Logging: Detailed application logs can be invaluable for tracking down the root cause of issues. Ensure you’re logging key events in your messaging workflow.
• Test with Simulator Numbers: Use our simulator numbers to test your messaging flows in a controlled environment, helping you isolate issues.

For particularly complex or persistent problems, Premium Support does offer additional resources and expert assistance. You can learn more about these services here: https://aws.amazon.com/premiumsupport/.

Learning from Each Investigation

Each investigation is an opportunity to improve your messaging strategy. Keep track of what you learn:

• Which monitoring alerts helped you catch the issue?
• What investigation steps were most effective?
• How could you spot similar issues faster next time?

But what if you could prevent some of these issues in the first place? That’s where building a resilient messaging strategy comes in, and that’s exactly what we’ll explore next.

Building a Resilient Messaging Strategy

Earlier, we discussed how retry logic helps handle immediate delivery challenges. Now, let’s expand our reliability toolkit with multi-channel approaches…

Just as passengers don’t have to rely on a single airline to reach a destination, you shouldn’t depend solely on SMS for critical communications. While SMS is fantastic, using just one channel is like depending on a single flight path. When that path becomes unavailable, you need alternatives.

Understanding Single Points of Failure

Here’s something crucial to consider: dedicated SMS phone numbers are provisioned through a single carrier partner in each region and country. Think of it like relying on a single airline for all your routes. If that airline experiences issues, you need alternative routes. This creates a potential single point of failure if that carrier partner experiences problems.

This makes implementing redundancy into your messaging strategy not only favorable/beneficial, but essential for business-critical communications. You can create this redundancy through:

• Using multiple channels like WhatsApp, Push notifications, or voice calls
• Implementing email notifications as a backup, failover, or just as an additional channel that handles specific types of messages
• In countries that support both dedicated numbers and sender IDs, planning to use either option if your use case allows for it
• Using phone pools to quickly adjust your sending strategy if specific originators experience problems

Remember, just as major airports maintain multiple airlines and routes to ensure reliable travel options, your messaging strategy needs multiple paths to reach your users reliably.

The Multi-Channel Advantage

Consider your messaging strategy like an international airport hub serving multiple carriers. AWS End User Messaging gives you several channels to work with:

• SMS for its universal reach
• WhatsApp for rich, interactive messages
• Push notifications for app users
• Voice calls when immediate attention is crucial
• Email as another reliable option

But it’s not just about having multiple channels – it’s about using them strategically. Pick the right channel for the message you are delivering. Not every message belongs on every channel.

Smart Failover: Your Messaging Safety Net

Imagine you’re sending a critical security alert. Here’s how a smart failover strategy might work:

1. Start with an SMS – it’s quick and widely accessible
2. If you don’t get confirmation within a few minutes, try WhatsApp
3. Still no response? Send a push notification if they have your app
4. For truly critical messages, you might even escalate to a voice call, or send via email and SMS at the same time

Putting Users in the Driver’s Seat

Just as frequent flyers have preferred airlines and routes, your users likely have preferred ways to receive messages. Some might want WhatsApp messages during the day but SMS for urgent notifications. Others might prefer push notifications while using your app but SMS for critical alerts.

Let your users choose their preferred channels, but be smart about it:

• Make preference updates simple and straightforward
• Consider message urgency when applying preferences
• Remember that preferences might vary by message type

Testing: Your Safety Check

Just as pilots run through a pre-flight checklist, regularly test your messaging setup. AWS End User Messaging makes this easier with SMS simulator numbers – a powerful tool that lets you test your messaging flows without sending messages over carrier networks.

With simulator numbers, you can:

• Test your messaging flows in a controlled environment
• Receive realistic event records
• Validate your application’s handling of SMS events
• All without incurring carrier costs(you will still pay for volume based on the country you are sending to) or affecting production traffic

Your testing strategy should include:

• Using simulator numbers to verify basic message flows
• Checking that messages render correctly across different channels (especially if you support multiple languages in your messaging)
• Confirming that your retry logic performs as designed
• Validating failover mechanisms work as expected
• Monitoring the performance of each channel

Think of simulator numbers as your messaging test lab – a controlled environment where you can experiment, validate, and fine-tune your implementation before sending to real phone numbers. You can find more details about using simulator numbers in the AWS End User Messaging documentation.

The Goal: Reliable Communication

Remember, the goal isn’t perfect delivery, but reliable communication with your users. By building redundancy into your system and offering choices, you create a robust messaging strategy that handles real-world challenges.

Just as airlines maintain multiple hubs and routes to ensure reliable service, your messaging strategy should provide dependable communication, even when individual channels face challenges.

Bringing It All Together: Your Path to Messaging Success

We’ve covered a lot of ground, so let’s wrap up with the big picture. Successful message delivery isn’t about achieving perfect numbers. It’s about building a robust system that reliably connects you with your users, even when conditions aren’t ideal.

Key Lessons to Take Away

Think of what we’ve learned as your messaging strategy toolkit:

First, we discovered why SMS delivery isn’t as straightforward as pushing a button. Just like a flight plan, your message navigates through various networks and systems before reaching its destination. Understanding these complexities helps set realistic expectations and guides better decision making.

Next, we learned that comprehensive monitoring is like having a reliable air traffic control system. It’s not just about watching flight trackers. It’s about actively monitoring passenger experiences through tools like the Message Feedback API. Remember, knowing if your passenger reached their final destination tells you more than a simple landing confirmation ever could.

We also explored how to identify and thoroughly investigate issues when they arise. Time is crucial. Those first 48 hours are golden when investigating delivery problems, and when you need help from AWS Support, detailed evidence is your best asset.

Finally, we looked at building resilience through multiple channels. Just as airlines maintain various routes to key destinations, your messaging strategy should have backup plans ready when needed.

Taking Action

Ready to improve your messaging strategy? Here are your next steps:

1. Start with Monitoring
   Review your current monitoring setup. Are you just looking at delivery receipts, or are you tracking actual user interactions? Implement the Message Feedback API to get better visibility into your real delivery success rates.
2. Set Up Smart Alerts
   Configure CloudWatch alerts that make sense for your business. Remember, different messages might need different thresholds – what’s acceptable for a marketing message likely is not acceptable for a security alert.
3. Build Your Safety Nets
   Begin implementing multi-channel capabilities. You don’t need to do everything at once. Start with one alternative channel and expand from there. Click here for a workshop on a basic failover between SMS and Email
4. Test and Learn
   Regularly test your messaging flows and monitor their performance. Use what you learn to continuously refine your strategy.

Need More Help?

We’re here to support your messaging journey. Check out these resources to dive deeper:

• AWS End User Messaging Documentation [link]
• Message Feedback API Guide [link]
• AWS End User Messaging Best Practices [link]
• AWS Premium Support [link]

The Future of Your Messaging Strategy

The messaging landscape will continue to evolve, but the fundamentals we’ve discussed will serve you well: monitor effectively, investigate thoroughly, and build in redundancy. With AWS End User Messaging, you have a partner who’s continuously working to optimize message delivery and provide the tools you need for success.

Remember, the goal isn’t perfection. It’s building a reliable communication system that your users can count on. Start implementing these practices today, and you’ll be well on your way to more effective user communications.

What’s your next step? Whether it’s implementing the Message Feedback API or designing a multi-channel strategy, the time to start is now. Your users are waiting to hear from you.