Successful Messaging Tactics for ISVs
Time to read: 6 minutes
ISVs, or independent software vendors, are Twilio customers who utilize Twilio APIs to support their own software solutions. ISVs then sell this software to their own clients.
If you are an ISV, you are in a unique position. You are building directly on Twilio and responsible to Twilio for content violations or high error rates, but it is your customers who determine the content sent through the software over the Twilio APIs.
Unfortunately, a few bad actors can have a negative impact on your Twilio account, as Twilio is responsible for stopping bad traffic from getting to carriers and end-users. If your ISV starts to see high rates of bad sending, investing in these three areas may help:
- Twilio account architecture, specifically Subaccounts
- Internal process such as filtering and reporting strategies to combat and be alerted of bad actors
- Better vetting of your customers’ future sending practices
In this post, I will outline the key tactics in each of these areas that our successful messaging ISVs do to ensure that their messaging solution sees minimal filtering and compliance issues and ultimately thrives.
- ISVs: Set up for Success for foundational, ISV-specific information
- Messaging Architecture for Independent Software Vendors (ISVs) for a deeper understanding of the ISV-specific architecture decisions we recommend
Twilio has functionality that can help make sure one bad actor doesn’t impact the broader customer base of an ISV: Subaccounts. While I won’t go into as much detail around architecture as our Messaging Architecture for Independent Software Vendors (ISVs) blog, I’ve included the high level reasons why our ISVs often opt for independent Subaccounts per customer.
Our most successful messaging ISVs utilize Subaccounts to differentiate customers from each other. Benefits to the Subaccount structure include:
- It differentiates usage for each client using our usage by subaccount page, leading to efficient billing.
- Subaccounts allow for individual configurability. For example, each Subaccount could have their own set of geo-permissions to make sure customers are only sending to the countries the ISV has approved.
- When troubleshooting a customer’s sending, you can easily search for the Subaccount SID or Friendly Name in Messaging Insights, observe their sending, and compare against other customers.
- Subaccounts decentralize security risks. If a malicious actor obtains customer credentials, they will only have access to the data in that specific Subaccount. By contrast, if the ISV does not use Subaccounts and houses everything within the parent account, ALL customer data could be accessed when credentials are compromised.
- Subaccounts allow Twilio to easily discern between the various customers when it comes to resolving compliance issues. Without the ability to isolate the offending senders, the Twilio compliance team may have to take action on the whole account.
As an ISV, you can operationalize this structure by developing a system that programmatically creates a Subaccount with a standardized Friendly Name naming convention when a new customer signs up for their platform.
In addition to leveraging the power of Subaccounts to silo and contain sending, you can also follow these recommendations to be even more successful:
- Utilize in-house filtering algorithms to catch bad sending before it can get to Twilio
- Utilize our Lookup API to gut check recipient lists
- Create an in-house compliance team
- Consistently monitor traffic
While Twilio does have its own filtering algorithms, we do not serve as compliance as a service (CaaS). Our filtering exists to best safeguard our relationships with carriers. As an ISV, you are responsible for the sending on your platform.
ISV platforms sometimes build out content scanning functionality that assesses for language compliance either during the message authoring process or "at-send." In both cases, these solutions ensure that problematic sending does not reach the Twilio platform. This type of scanning typically watches for:
- Possible problematic language (e.g., cannabis, money lending, alcohol)
- Lack of
Opt-Out or HELP language
- Lack of Sender Identification
The Lookup API identifies landlines or problematic numbers before the message even gets out. This can either be promoted in the application as an option for customers to check their list proactively OR be implemented ‘at-send.’
The Lookup API works best for 1:1 verification upon phone number collection. Catching a bad phone number before you log it for that contact will save resources, customer confusion, and messaging costs.
Considering the ever-changing landscape, one of the biggest things messaging ISVs prioritize is building out a team internally to manage platform compliance. These folks are the ones reviewing customers that are getting flagged either by internal tooling or Twilio’s compliance.
This team is the biggest player in the success or failure of an ISV as they are responsible for the traffic their customers generate and the consequences of this traffic. Twilio’s main offering as a platform is to provide APIs to easily send messages on a global scale. It is not our scope to act as a regulatory compliance service for our customer base. Our filtering and scanning functionality is built to prevent problematic sending that could jeopardize our relationships with carriers and impact our ability to operate efficiently on these networks. With that in mind, if we find that an ISV consistently allows prohibited traffic over their platform, we will need to safeguard our network.
Twilio provides you with a lot of data that can be used to flag possible trends or issues. Here are some of the tools available:
- Message Status Callbacks pass error codes and statuses from Twilio back into your system. With that data on hand, you can set up internal flags or alerts when rates get too high.
- Alarms notify you when spikes in errors occur.
- The Inbound SMS Webhook can capture responses or opt-outs. It also enables you to build a flow of data from when the message was sent to when the response was triggered. This type of cycle allows you to create automations that intervene when bad sending occurs. I’ve seen ISVs leverage a combination of these solutions to track trends and tackle large amounts of bad senders.
ISVs utilize this data to proactively catch bad actors by tracking error rates and opt-out rates for customers and setting up alerts if they are getting near rates that Twilio considers risky.
ISVs that perform the best, take it upon themselves to have stringent KYC practices (Know Your Customer) and provide resourcing to their customers to train on best practices. You know your customers much better than Twilio ever will, so getting in early to vet a customer before sending is a great starting point. If you do see a customer starting to trend downward, having reminders and customized documentation may help bring the customer back to good sending.
As the messaging landscape continues to change, the ability to provision a number without customer information is becoming harder and harder. One way to show customers how to use your functionality without technically providing a number is to utilize Magic Numbers. Magic Numbers are a useful way to let customers test out how they would use your platform without actually sending messaging traffic over carrier routes. Once they feel comfortable with your platform’s sending behavior in this sandbox, they can choose to provide additional information regarding their use case and sending patterns for your team to vet. If they pass your checks, you can give them the ability to provision a number and start sending – this process is often called Know Your Customer or KYC.
Twilio’s Verify API is a purpose-built solution you can use to vet your customers before providing too much access. It helps reduce fraud in the user experience with phone number verification that uses one API endpoint to validate users and detect fraud with minimal friction.
As an ISV, you have a responsibility to ensure that your customers are legitimate businesses or people. Having a vetting process in place will give you the opportunity to validate that you have the right customers on your platform.
It is helpful to have call outs within your platform for certain compliance pieces. If the customer is sending in ways that you’ve identified to be risky, having a pop-up that asks about their compliance plan or sending practices can get them on the right track.
One example of this is Twilio’s in-Console alert that says “You are at risk of incurring penalty fees.” This notifies customers that have sent unregistered messages in the last 7 days that there may be repercussions of their unregistered sending coming soon.
In-platform compliance reminders can also go hand in hand with the content scanning outlined in the Filtering section. If the content scanning identifies problematic language, there could be a pop-up to notify the customer why they will not be able to use that phrase.
ISVs find it helpful to put out their own compliance documentation that they link out to in the platform or have listed on their website. This way you can provide documentation directly to your customers regarding the pieces most relevant to their platform. Then, when difficult conversations come up around compliance, they have branded documentation to provide their customers. It also serves as a training opportunity for the go-getter customers who are interested in the messaging landscape.
There you have it! You’ve now reviewed how you can use Twilio’s Subaccount feature, internal processes, and customer vetting to optimize the messages sent from your ISV platform and safeguard its reputation.
If your team would like assistance with any aspect of your messaging solution, Twilio Professional Services is here to help. Reach out to learn more about our offerings.
I can’t wait to see what you build!
Michelle Desien is a Senior Technical Onboarding Manager with Twilio’s NAMER Professional Services team, coaching customers on best practices, US compliance, and sending at scale internationally. She can be reached at mdesien [at] twilio.com.
From APIs to SDKs to sample apps
API reference documentation, SDKs, helper libraries, quickstarts, and tutorials for your language and platform.
The latest ebooks, industry reports, and webinars
Learn from customer engagement experts to improve your own communication.
Twilio's developer community hub
Best practices, code samples, and inspiration to build communications and digital engagement experiences.