AWS Messaging & Targeting Blog
SMS Onboarding for SaaS, ISV, and Multi-Tenant Applications with AWS End User Messaging
Introduction
SMS messaging continues to be one of the most reliable and effective communication channels. However, for Software as a Service (SaaS) companies, Independent Software Vendors (ISVs), and multi-tenant solution providers looking to incorporate SMS capabilities into their offerings, the journey can be complex and filled with challenges.
This guide is specifically designed for technology providers—whether you’re a SaaS company, an ISV, or any platform that enables your customers to send SMS messages to their end users. Throughout this article, the following terminology will be used:
- Provider: An organization offering SMS capabilities as part of your product or service
- Customer: The entities using Provider technology to send SMS messages
- End User: The recipients who opt in to receive SMS messages from Customers
The landscape of SMS implementation can be complicated, with varying country-specific regulations, lengthy registration processes that can take weeks or even months, different originator types (Long Code, Short Code, Sender ID, etc.) with unique capabilities, and the diverse needs of Customers and End Users. These challenges are amplified when you’re a Provider offering SMS services to your own Customers, who in turn serve their End Users.
By the end of this guide, you’ll understand:
- How opt-in influences architecture
- Options for how to structure your SMS offering to Customers
- Strategies for reducing friction in the SMS implementation process
Let’s dive in.
The Registration Dilemma: Who Owns the Relationship?
One of the most critical decisions for your SMS Originator registration is determining whose information is used to apply. The biggest mistake AWS sees Providers make is not knowing how their relationship with their Customers and their Customers’ End Users affects their architecture and how they complete any registrations that are necessary.
Mobile carriers want to know who will be sending SMS to their customers, how that entity will opt them in, and what content they will be sending. When registering for originators, especially in the United States, you will need to succinctly explain how End Users will opt in and how that data will not be shared with any third parties. Your architecture must ensure:
- Clear opt-in processes that name the correct entity
- Privacy policies that accurately reflect data sharing practices
- Compliance with third-party data sharing regulations
AWS consistently sees Providers register themselves when obtaining an Originator when they do not have a relationship with their Customers’ End Users. The decision of whose information belongs in the registration hinges primarily on a fundamental question: Who does the End User believe they’re entering into a relationship with when they provide their phone number?
The most common scenarios are below:
Scenario 1: End Users interact with the Customer’s brand only
In most cases, End Users are completely unaware of your existence as the Provider. They believe they’re opting in to receive messages from your Customer directly. In this scenario:
- Registration should be completed using the Customer’s information. There are many ways you can facilitate this process and some ways to reduce this common friction point will be discussed later in this post.
- Messages should appear to come from the Customer, not the Provider, your service name should not appear in messaging
Scenario 2: End Users explicitly opt in through the Provider application
In some cases, End Users clearly understand they’re opting in to receive messages via your technology platform, on behalf of your Customer. The opt-in data will not be shared with your Customers and your brand, as the Provider, will be the named entity in all SMS sent.
There are a number of ways that this can happen:
- End Users could opt in using a widget you build that your Customers install on their site or in their app
- A paper form or verbal script that you supply that clearly identifies you, the Provider
AWS commonly sees this occurring with Providers that supply:
- Third-party payment processing
- Shipping and logistics support
- Customer service platforms
- One-Time Password (OTP) capabilities
In this scenario your company name would typically appear in the messaging and registration would use your company information.
NOTE: There are edge cases to these two scenarios but the implementation can be complicated, so if you are a Provider and you don’t think that you fit into these two scenarios above make sure to reach out to your Account Manager, open a case, or speak to a specialist before starting to implement anything.
Architectural Models for SMS Implementation
Let’s explore various architectural models for structuring your SMS offering based on your business needs and Customer relationships. Each model has distinct characteristics in the following areas:
1. “Bring Your Own AWS Account” Model
Who does the registration and configuration?
- The Customer connects their own AWS account, so the registration and any configuration happens in the Customer account.
- Usually in this scenario the information that is input into the registration is the Customer’s since it’s their account
Customer responsibilities:
- Customer handles all registration and configuration requirements themselves
- Customer integrates their account with the Provider service
- Customer manages sending, opt-out lists, etc.
- Pays the AWS bill
Provider responsibilities:
- The Provider offers a user-friendly interface that calls the AWS End User Messaging Service APIs using the Customer’s credentials.
- The depth of services offered by the Provider can vary
Best for: Technical Customers who want full control and already use AWS; Providers who want to avoid registration and configuration complexities.
2. Provider Account – Manual Registration and Configuration
Who does the registration and configuration?
- The Provider owns the account and is not providing the Customer with a way to submit their own information so the Provider must enter the information
- The Customer’s information is captured manually
- The Provider handles the complexity of registration and configuration through the console
Customer responsibilities:
- Provide necessary information to the Provider for registration purposes
Provider responsibilities:
- Captures the registration information manually from Customers.
- Manages the complexity on behalf of your Customers.
This can be implemented either with separate AWS accounts for each Customer or a multi-tenant architecture in a single account.
Best for: Providers with a small number of high-value Customers who need hand-holding through the SMS implementation process.
3. Semi-Automated Solution – Customer Sending
Who does the registration and configuration?
- The Provider builds a way for the Customer to submit their registration information, which the Provider then programmatically submits to carriers/regulators.
Customer responsibilities:
- Your platform manages the technical configuration and provides sending capabilities, but the Customer is responsible for maintaining compliance.
Provider responsibilities:
- You provide a streamlined way for Customers to submit registration information (webhooks, forms, APIs).
- You programmatically submit the registration data to carriers/regulators.
- You manage the technical configuration and provide sending capabilities.
Best for: Providers with moderate technical sophistication who want to reduce friction while maintaining separation of regulatory responsibilities.
4. Fully Automated Solution – Provider Sending
Who does the registration and configuration?
- The Customer’s information is used in the registration, which you handle programmatically.
Customer responsibilities:
- You handle all technical aspects of registration, but the Customer is still responsible for maintaining messaging compliance.
Provider responsibilities:
- You provide hosted, customizable Terms & Conditions and Privacy Policies for each Customer that are compliant out of the box.
- You offer compliant opt-in pathways (web forms, verbal scripts, etc.).
- You handle all technical aspects of registration.
Best for: Large-scale Providers serving many Customers with varying levels of technical sophistication.
5. Template-Restricted Fully Automated Messaging
Who does the registration and configuration?
- The Customer’s information is used in the registration, which you handle programmatically.
Customer responsibilities:
- You manage all regulatory compliance centrally, and the Customer can only personalize specific fields in pre-approved message templates.
Provider responsibilities:
- You provide a suite of pre-approved message templates.
- You manage all regulatory compliance centrally.
- You simplify the registration process since the content is tightly controlled.
Best for: Use cases with predictable messaging needs like appointment reminders, shipping notifications, or one-time passwords.
6. Fully Managed Programs
Who does the registration and configuration?
- The Customer authorizes you to send messages on their behalf, so you own the relationship with the end-user and the registration.
Customer responsibilities:
- Only required to give you any pertinent information necessary for you to send messages to the End-Users. This could be things like tracking numbers or other information that the particular use case requires and is part of the personalization that is allowed.
Provider responsibilities:
- You manage all aspects of the end-user relationship.
- You control the entire messaging experience, including opt-in collection and the end-user relationship.
Example: A shipping notification service might send messages like: “ShipTrack: Your order from ACME Corp will arrive tomorrow. Track at [link]”
Best for: Specialized use cases where your platform adds significant value as an identified intermediary.
Shaping Your SMS Offering: Strategic Considerations
Pricing Strategies
When incorporating SMS into your product, one of the first considerations is how to structure your pricing. Unlike many digital services with predictable costs, SMS pricing varies significantly based on destination country, originator type, and volume.
AWS End User Messaging Service bills based on volume sent per country, with each country having its own price point. This pricing is determined by the recipient’s handset country code, not their physical location. This means that even if you primarily serve U.S. based Customers, you may need to account for international rates when recipients have non-U.S. phone numbers.
There are also one-time and ongoing fees to be accounted for. Registrations often have one-time processing fees and Originators can have leasing costs that range from free to more than $1,000 a month for short codes in some countries. Make sure that you think through how those costs will or will not be passed to your Customers.
As you design your pricing model, consider these common volume based approaches:
- SMS Credits: Create a standardized credit system where Customers purchase credits regardless of destination country. You would internally manage the conversion between credits and actual costs.
- Dollar-Based Allocation: Provide Customers with a budget that gets depleted based on actual costs per message sent.
- Tiered Country Pricing: Group countries into tiers (e.g., Tier 1 for North America, Tier 2 for Western Europe) with different pricing for each tier.
- Bundled Messaging: Include a certain number of messages in your base subscription with overage fees for additional messages.
Each approach has trade-offs in terms of simplicity, transparency, and risk management. Your decision should align with your overall business model and Customer expectations.
Geographic Considerations
Different countries have distinct regulatory requirements for SMS messaging, including:
- Originator Support: Not all countries support all originator types, view the details here
- Originator Selection: In cases where multiple types of originators are supported, how do you support your Customer in selecting the right originator for the right use case?
- Read through this tutorial to help decide what originator(s) are right for your use case(s)
- Registration: An increasing numbers of countries require you to register before being allowed to send
- Quiet hours: Many countries restrict when promotional messages can be sent
- Content restrictions: Certain types of content (gambling, alcohol, adult content, etc.) may be prohibited or heavily restricted. A more comprehensive list can be found here
- Template requirements: Some jurisdictions require pre-approval of message templates
- Sender ID regulations: Rules regarding who can use alphanumeric sender IDs vary widely
As a Provider, you need to decide which countries you’ll support and how you’ll ensure compliance across markets. This decision affects not just your pricing but your entire product architecture, especially if you serve global Customers.
Strategies to Reduce Implementation Friction
Implementing SMS can be complex for your Customers. Here are some strategies that can simplify and/or streamline the process. Some of these can be mixed and matched and could also be used as a value-add or even as a paid offering to your Customers:
Provider-Hosted Privacy Policy and/or Terms & Conditions
Create customizable, compliant templates for Privacy Policies and Terms & Conditions that your Customers can use. This ensures proper disclosure of SMS practices without requiring Customers to update their own legal documents.
Registration Webforms and Workflows
Develop user-friendly webforms that collect all required registration information in a guided process. These can significantly simplify complex registrations like 10DLC brand and campaign registration.
Below, Figures 1-3, you will find several examples of compliant forms that could be customized for your use:
Fig. 1 |
Fig. 2 |
Fig. 3 |
Pre-Approved Opt-In Widgets
Create embeddable widgets, such as Figures 1-3 above, that your Customers can add to their websites or apps that implement compliant opt-in processes. These can include all required disclosures and confirmations while being easy to integrate.
Template Libraries
Provide a library of pre-approved message templates for common use cases. This reduces compliance risks and simplifies the sending process for your Customers.
Testing Environments
Create sandbox environments where Customers can test their SMS implementation before going live. This helps catch issues with formatting, opt-in processes, or content compliance.
Documentation and Training
Develop clear documentation and training resources specific to each originator type and use case. This empowers your Customers while reducing support burden.
Conclusion
Incorporating SMS capabilities into your platform can enhance Customer engagement, but the journey can be complex. This guide has explored key considerations to help you navigate it successfully.
This post examined various architectural models, each with tradeoffs in Customer responsibilities and Provider responsibilities. This post reviewed strategic factors like pricing, geographic regulations, and originator types that must be carefully considered.
Finally, practical strategies to reduce implementation friction for Customers such as hosted compliance documents, streamlined registration workflows, and pre-approved templates, you can use to simplify the integration process were discussed .
The critical first step though, is understanding the relationship between you as the Provider, your Customers, and their End Users. This shapes whose information is used for originator registration, which in turn defines the SMS experience.
Ultimately, a successful SMS solution requires balancing technical, regulatory, and Customer-centric factors. Leveraging this guidance will equip you to design and deploy an offering that delights your Customers and their End Users.
Additional resources: