Best Practices for Sending Global SMS with AWS End User Messaging

Cloud Messaging Services for Sending SMS Globally

Introduction

Cloud messaging has become essential for businesses looking to send SMS globally, enabling them to communicate with customers across different regions. AWS End User Messaging provides a robust cloud messaging solution, covering 240 countries and regions. However, unlike personal SMS, Application-to-Person (A2P) messaging involves strict regulations that vary by country.

This blog explores best practices for sending SMS globally, from country selection and origination identity (OID) choices to message testing and compliance. By understanding these steps, businesses can optimize their cloud messaging strategy and improve deliverability rates.

SMS Delivery Process

Pre-Planning and Country Selection

The first step to planning a global rollout of SMS is to know what countries you want to send to and what each of your use cases are. Put together a spreadsheet for each unique use case you have and the countries you plan on sending to with the below key details:

Key Details to Include in Your Spreadsheet:

– The volumes you expect to send to each country.
– The throughput (Also referred to as Messages per Second, MPS, Transactions per Second, or TPS) at which you expect to deliver these messages.
– Whether your use case is one-way or two-way. Not all countries support two-way communications, which is the ability to have the recipient send a message back to the OID. Sender ID also does not support two-way communication, so if you are planning on using Sender ID, you will need to account for how to opt recipients out of future communications.
– Leave a column for the Origination Identity you will use for each country.
– Leave a column for whether this country requires advanced registration.
– Leave a column for any country-specific limitations or requirements such as language limitations.
– Leave a column for the estimated time it takes to register.

Selecting an Origination Identity (OID)

Now that you have these details all in one place, consult the table to determine what OIDs each country supports, and, if your use case requires it, which countries support two-way.

In countries where there are multiple options for OIDs, there are several guidelines to consider when you’re deciding what type of origination identity to use:

– Sender IDs are a great option for one-way use cases. However, they’re not available in all countries, and if you are needing to opt-out your customers, you will need to provide a way for them to do so since they are only one-way. In some countries (such as India and Saudi Arabia), long codes can be used to receive incoming messages but can’t be used to send outgoing messages. You can use these inbound-only long codes to provide your recipients with a way to opt out of messages that you send using a Sender ID.
– Short codes are a great option for two-way use cases and have the highest throughput of all OIDs. While short codes have a higher throughput, they also come at a much higher cost than other OIDs, so weigh your cost against your use case requirements.
– In some countries, we maintain a pool of shared origination identities. If you send messages to recipients in a particular country but don’t have a dedicated origination identity in that country, we make an effort to deliver your message using one of these shared identities. Shared identities are unavailable in some countries, including the United States and China. Shared identities cannot be two-way, so make sure you have a way of opting customers out of communication.

To streamline the rollout, prioritize countries with minimal registration requirements before expanding to those requiring complex approvals.

Procuring and Registering Origination Identities

In countries where registration is onerous, it is important to have a few things about your process all in one place. Some registrations are very similar in the information that they ask for while others have special processes that you need to follow.

Strong>Examples of Different Country Registrations:

– US
– Short Code
– The information you gather from this post is useful for many of the other registrations.
– 10DLC
– Toll-Free
– India
– Singapore
– China

Once you have decided on your OIDs for each of your countries, you can begin the process of procuring them. Depending on where you plan on sending, you may need to open a case to procure them.

Testing SMS Sending

Once you have procured OIDs and are ready to begin testing, it is essential that you set up a way of monitoring the events that End User Messaging generates. Pay attention to the Delivery Receipts (DLRs) that are returned back into the event stream. End User Messaging can deliver events via Amazon Kinesis, Amazon Simple Notification Service (SNS), Amazon CloudWatch, and/or Amazon EventBridge. This gives you flexibility in how you deliver the events to their required locations. Monitoring SMS events is an important part of sending globally.

MPS limits can vary depending on the countries you’re sending to and the OIDs you’re using. If there’s a risk of exceeding these limits and triggering rate-limiting errors, it’s crucial to devise a strategy for queuing your messages. Keep in mind that End User Messaging doesn’t offer queuing capabilities. Therefore, message queuing must be incorporated at your application level or by leveraging AWS services.

Once you have your monitoring solution in place, you are ready to begin testing sends to real destination phone numbers. Keep in mind that at this point, you are likely still in the Sandbox for SMS. This means you have much lower quotas for sending and can only send to verified phone numbers or the SMS Simulator numbers. End User Messaging includes an SMS simulator, which you can use to send text messages and receive realistic event records to 51 commonly sent to countries. Messages sent to these destination phone numbers are not sent over the carrier network but do incur the standard outbound SMS messaging rate for the country that the simulated phone number is based in.

Best Practices for Global SMS Sending

Use the SMS and Voice v2 API and the SendTextMessage Action. The V2 API is the preferred way of sending as it allows for more fine-grained control over your messages and is the API upon which new functionality will be built. When sending SMS, End User Messaging includes logic for selecting the best OID to send from based on the country code. If there are multiple OIDs available to send to a particular country, End User Messaging will default to the highest throughput OID available in your account/region. If there are not OIDs specific to the country being sent to, End User Messaging will default to SenderID or to a shared OID owned by End User Messaging in that order, if the country allows these OIDs to be used. Given this functionality, the best practice for sending SMS is to use pools and to allow End User Messaging to select.

If you have multiple use cases and need to specify the correct OID for each, this is where the V2 API is useful. OIDs can be attached to pools, which can be configured to serve a particular use case, and the pool can be specified in your SendTextMessage call. Sending using a PoolID and allowing End User Messaging to select the right OID from that pool for the destination phone number simplifies your sending process.

Managing Opt-Outs

Regulatory compliance requires businesses to handle opt-outs effectively. AWS Cloud Messaging offers automatic opt-out processing using keywords such as “STOP” or “UNSUBSCRIBE.” However, businesses with multiple use cases (e.g., OTP and marketing) should segment opt-out settings to avoid blocking critical messages.

Monitoring Sending

The last step in ensuring success for SMS sending is having a solid platform for monitoring your sending. SMS is not a guaranteed delivery channel. You will always receive an event for a successful send in the event stream, but there is no guarantee of a return status event if a DLR from a carrier is not sent. The first event you should see returned when watching the Event Stream for an SMS send activity is the “PENDING” event. This means we’ve sent the message to the carrier, where it’s buffered, and we’re waiting for the carrier to return a status message.

Make sure to review all of the possible values for the record_status attribute so that you are aware of varying issues with your sending that can arise. For example, statuses such as “Blocked,” “Spam,” and “Carrier_Blocked” can indicate systemic issues that should be investigated.

Conclusion

Global SMS delivery presents regulatory and technical challenges, requiring careful planning and execution. AWS Cloud Messaging streamlines this process, ensuring businesses can optimize message delivery, maintain compliance, and enhance customer engagement. Staying informed about new regulations and service enhancements is key to improving SMS success rates.

Enhancing Customer Connections: The Future Of Communication Management lies in leveraging cloud-based solutions to ensure seamless, compliant, and efficient messaging across global networks. Cloudastra helps businesses navigate these complexities by providing expert services in SMS delivery optimization.

Do you like to read more educational content? Read our blogs at Cloudastra Technologies or contact us for business enquiry at Cloudastra Contact Us.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top