Putting on our ISV Shoes

Twilio is an API-first company that supports builders. We get to work with builders who range from hobbyist developers to software developers at large multinational enterprises. Some of the customers are referred to as Independent Software Vendors (ISVs). We offer a definition for “ISV” in this blog post.

Twilio partners with ISVs to provide communication infrastructure APIs, access to the Super Network, and communications expertise, so that ISVs’ teams can focus on building innovative customer engagement solutions that delight their own customers.

When ISVs come to Twilio, one of the first things they say is, “Wow, there are so many APIs and products! Where do I begin?” That question is a fun one for us Twilions to answer, because the answer itself is a question: “What challenge(s) are you trying to address?”

In the spirit of two of the values outlined in the Twilio Magic— Wear the customer’s shoes' and Write it down— this post walks through an ISV’s journey getting started with Twilio.

Meet Owl Inc.

Owl Inc. (our fictional ISV) currently provides customer relationship management (CRM) software and solutions to retail customers operating in the exercise and wellness space (businesses like bicycle shops, surf shops and running shoe companies, for example).

Current state

Owl Inc. has been growing its customer base with the recent increase in demand for outdoor activities (due to the pandemic), and they’re hearing from their customers that their customers want to be able to communicate more effectively with people buying their products, who are on the road and more mobile than ever before. Owl Inc.’s customers are saying that flexibility in the mode of communication and enabling their consumers to select their preferred method of notifications is key.

Owl Inc. has a couple of key metrics they want to improve:

• Decrease churn rate
• Increase conversions from freemium to paid packages
• Reduce front office and back office labor; such as customer support folks.

Owl Inc. reaches out to their Twilio Account Representative to chat about their use case and the challenges they’re trying to address. After talking with the Twilio team, Owl Inc. decides to enable retail stores to send transactional alerts and notifications to their customers. This solution will improve their key performance indicators (KPI)s in the following way:

Checklist

Owl Inc. produced the following checklist of critical pieces that they need to validate to ensure the success of the project:

• Technology
• Finance
• Enablement
• Security and Compliance

Let’s walk through each of these aspects in more detail.

Technology

Proof of Concept

The first thing Owl Inc. wants to do is create proof of concept (POC). The POC is something that Owl Inc. wants to create in one sprint (2 weeks), and it needs to satisfy the following user stories:

1. As a customer of Owl Inc., I can select a template in the Owl Inc. solution that will be sent to my customers.
2. As a customer of Owl Inc., I can add contacts to the Owl Inc. user interface.
3. As a customer of Owl Inc., I will see the status of an SMS after it is sent to my customer.
4. As a developer at Owl Inc., I can send an SMS message to our customers’ end-user.

The ladder diagram below represent the workflow. The proposed solution will use the following Twilio APIs:

• Account API
• TrustHub API
• Address API
• Messaging API

First lets create a Subaccount.

Now we can create a Secondary Customer Profile for a customer.

Great! We can now create an A2P Trust Product.

We know how our Secondary Customer Profile and A2P Trust Product registered. Lets create an A2P Brand and send an SMS to our end-user (Alice).

By following the ladder diagram, Owl Inc. can now implement these APIs into their platform for testing. Owl Inc. will add logic on their end to handle when to send an SMS.

If the POC is successful, we then need to ensure that we have the correct architecture.

Since Owl Inc. is an ISV, we’ll need to use subaccounts. This ensures that Owl Inc. has complete tenant (or customer) isolation, which makes it easier to monitor customers’ key metrics and risk factors.

A diagram of a Twilio account structure being used by a few of our ISV customers is shown below. You’ll see that we need to create two top-level Twilio accounts:

• Owl Inc. Dev
• Owl Inc. Prod

In each account, we will create a subaccount for each of Owl Inc’s customer. This architecture allows Owl Inc to have separate environments for their customers, so that when rolling out new features they can deploy to development, staging and production environments.

If replicating the entire production environment within the development environment isn’t necessary, the development environment can be aggregated as shown below:

Finance

• Technical (done)
• Finance
• Security & Compliance
• Enablement

Once we’ve achieved our technical validation, we can begin to think about how we will add the Cost of Goods Sold (COGS) into our existing pricing and packaging.

Packaging

Owl Inc. Sales teams can now upsell a SMS messaging add-on for their solution, which enables customers to engage their consumers through SMS messages. Analyzing how their customers use the messaging product will enable Owl Inc. to better understand their customers, provide new packages based on customer feedback, and build an end-user experience that drives retention.

COGS and Gross Margin

Introducing Owl Inc.’s SMS solution to their customers will increase their cost of doing business, so we need to ensure that this solution will be financially viable. The increase will come from the cost of using Twilio’s APIs. As such, Owl Inc. has broken down the gross profit for each tier.

The cost of goods sold is the total cost of using Twilio’s APIs. We used 31 as the multiplier, for 31 calendar days, to be conservative. So for example:

Bronze comes with 50 messages per day. Assuming 31 days at full utilization a customer will send 1550 messages.

Reconciliation

Owl Inc. will need to track the number of SMS messages customers are sending so that it can keep track of profitability.

Owl Inc. will implement Usage Triggers to track their customers’ messaging volume. The easiest way to implement this is to set a usage trigger based on the pricing tier a customer has. For example, if Freestyle Falcons signed up for a Silver package, they would have 250 messages per day. Owl Inc. can set a Usage Trigger that will send an alert to an internal endpoint on Owl Inc.’s server when Falcon Flights sends the 250th message of the day.

Enablement

• Technical (done)
• Finance (done)
• Enablement
• Security & Compliance

Owl Inc. has a pre-sales team and a post-sales team that will need to be provided with the right information to sell their new SMS solution.

Pre-sales

Pre-sales is responsible for acquiring new customers to onboard onto Owl Inc.’s software. When pre-sales team members think about how to target the right customers, there are a few areas they will need to ask about:

• What's their business objective for wanting to send SMS Messages?
• What use cases are they looking to support?
• Where are the users located geographically?
• How many messages does the customer plan on sending to each consumer?

Owl Inc.’s goal in pre-sales conversations is to ensure that the customer’s use case aligns with the solution that has been built. If Owl Inc. finds that customers are asking for things like discount offers (promotional traffic) at a high volume, or the ability to send SMS to countries outside the U.S., they will need to iterate on their solution to meet these requirements.

The Twilio blog post titled Messaging Architecture for ISVs contains more in-depth information about this topic.

Post-sales

Owl Inc.’s post-sales team is responsible for managing the current customer base to reduce churn. Supporting SMS customers requires enabling post-sales teams in a few key areas:

• Know your customers’ (KYC) policies
• Message deliverability
• Usage alerts
• Procuring non-standard international numbers
• Troubleshooting / support

To help Owl Inc’s. Post sales team, they can use a few different tools.

Status Callbacks

Status callbacks are specified on each message sent or on the Messaging Service. As the message goes through Twilio and the messaging ecosystem, Twilio will send status updates to the specified status callback url.

If you see statuses such as undelivered and failed, start investigating what might be leading to these statuses.

Debugger Event Webhook

As Owl Inc. begins to develop its product(s), warnings and errors will occur, as this is part of the development process. When Owl Inc. pushes their services that depend on Twilio to production they need a way to monitor errors at scale. We recommend using the Debugger Events Webhook for situations like this.

Below is a webhook for all errors and warnings to be sent. This endpoint might be an JSON storage service or a monitoring service:

Messaging Insights

Messaging Insights is a dashboard that aggregates account-level Messaging metrics. Owl Inc. can view insights at the parent account and subaccount data, making it easier to understand high-level trends and to monitor key metrics such as deliverability, opt-outs and errors.

Security and Compliance

• Technical (done)
• Finance (done)
• Enablement (done)
• Security & Compliance

Owl Inc. will be sending communications on behalf of their customers, which means they need to ensure all traffic is compliant with Twilio’s Acceptable Use Policy (AUP). Additionally, all messaging traffic has to comply with Twilio’s Messaging Policy.

These policies are in place to ensure consumers are only receiving compliant communications through the Owl Inc. solution. You can read this post to learn more about how Twilio is “Partnering with ISVs to build a culture of sending wanted communications.”

Owl Inc. will ensure that only authorized senders are sending SMS messages from their platform by placing checks on the new tooling. Owl Inc.’s security team will also need to review all documentation provided, including Twilio’s Security Overview And Twilio’s Security API Docs

Push to Production

Owl Inc. has successfully completed all of the items in its checklist and now it’s time to go to production. There are a few things that Owl Inc. will need to do before they fully launch their product:

• Identify a few customers that are willing to be beta customers. Releasing the new solution to beta testers first will help to validate the solution. Then, Owl Inc. can make any necessary improvements before announcing the general availability (GA) of its new SMS solution.
• After a successful beta phase, Owl Inc. will begin rolling out the new SMS feature to their entire customer base, and allocate a marketing budget to promote it.

Conclusion

Integrating communications can drive revenue for your products, expand your products’ capabilities, and build lasting engagement directly with end consumers. Twilio’s Engagement Platform has the solutions to support your vision, and the use cases are endless.

To learn about becoming an ISV Partner, please complete this form.

If you’re interested in reading more ISV specific blog posts, here are a few to consider:

• ISVs: Set up for Success for foundational, ISV-specific information
• Using subaccounts to understand how to leverage subaccounts.
• Messaging Architecture for ISVs
• Voice Architecture for ISVs
• Partnering with ISVs to build a culture of sending wanted communications

Josh is a Principal Solutions Engineer at Twilio, focused on helping our Independent Software Vendor (ISV) Partners build scalable architectures and business on Twilio.