Twilio Studio for Dummies (Like Me)
We love Twilio here at Weave. We build tools that enable small businesses to communicate with their customers, and Twilio plays a fairly critical role in helping us do that. We especially love their well-documented APIs, comprehensive logs, and innovative product catalog.
Earlier this year I happened to bump into a new product with which I was not familiar: Twilio Studio. One of Twilio Studio’s main examples was “Appointment Reminders”, which really caught my eye because this is one of my team’s main responsibilities at Weave. To be quite honest, my knee-jerk reaction was that Twilio was trying to put me out of a job, and I did not appreciate that.
Rather than fear change, however, I decided to embrace it and find out if Twilio Studio was all that it was cracked up to be. I had a simple project in mind and built it one weekend using Twilio Studio.
The Project
Today, I is a journal service that texts subscribers on a daily basis prompting them to respond with a few thoughts about their day. Subscribers should also be able to submit a journal entry at-will without requiring a prompt first.
While I am sure countless such services already exist, I’ve contracted the terribly contagious not-invented-here syndrome while working at Weave and therefore decided to reinvent the wheel. (Plus, signing up for an existing service turns out to be an ineffective way to learn a new technology).
The good news is that this project, as we’ll find out, is the perfect use-case for Twilio Studio.
The Implementation
Intro to Twilio Studio
Microsoft Word has Documents, Excel has Workbooks, Twilio Studio has Flows. The browser-based Twilio Studio editor allows you to view, edit, test, and save these flows. It is visual and intuitive, which makes it very accessible for a non-technical audience and a delight-to-use for everyone. Each flow is composed of drag-and-drop widgets that are connected to each other to program the behavior of your application.
All flows start with the same widget called “Trigger”, which acts as the entry point for your application. There are actually three possible ways to get into the “Trigger” widget: an incoming text message, an incoming phone call, and an incoming HTTP request. Each of these triggers can have their own branch in the flow, or they can share a branch, or they can just lead to a dead-end.
The Journal Flow
Since I want to receive a daily reminder to write in my journal then our flow needs to support triggering when we make an HTTP request to flow’s REST API. I wrote some code to iterate through all subscribers and execute a request for each one; this runs nightly using Heroku Scheduler.
We also want subscribers to be able to initiate an ad hoc journal entry whenever they get the urge, so we’ll support this behavior by triggering off of an incoming SMS message that is sent by a subscriber to the flow’s phone number.
So Incoming Messages and the REST API both flow into a widget that allows us to send a text message and wait for a response. We ask the subscriber to tell us what they did today and give them 1 hour to respond. If they don’t respond then we flow into another “Send & Wait for Reply” widget to message them again and try to shame them into responding.
Assuming our subscribers do care about remembering their lives and they respond then we need a way to get their journal entry back out of the Twilio Studio Flow and into our journal database. For that, we use a widget that allows us to make an HTTP request to an external service.
We build the request body using data we’ve collected from other widgets upstream in the flow (such as the subscriber’s phone number and their SMS response). The request is sent to a service running on Heroku that stores the journal entry in a database. Based on whether or not the request was successful we’ll send another message to the subscriber to let them know we’ve added their journal entry, and that they should feel good about themselves.
And that’s pretty much it for the journal service. I did have to write some code for the nightly invitations as well as an API for creating journal entries, but neither of those tasks were too onerous.
The Conclusions
Twilio Studio is powerful, flexible, and easy-to-use, but is it going to put me out of a job at Weave?
Did it even make my life easier?
First of all, did Twilio Studio help me move faster on this project than if I had just used Twilio’s Programmable SMS instead? I still had to write code, so presumably it allowed me to at the very least write less code, but what specifically was easier?
If you think about the pain I would have suffered trying to implement just the logic to send a follow-up message to each user that doesn’t respond to their first journal prompt then I think it becomes very evident how much heavy lifting Twilio Studio did. I would have had to track each outbound and inbound SMS message, and suddenly my one-weekend project just turned into a three-weekend project (meaning it will never be completed).
Instead, the only information I have to track is Users and their Journal Entries — SMS messages are not even in the lexicon of my application code. Think about that for a minute; texting is a critical component of my journal service yet shows up nowhere in the code I had to write.
Additionally, using Twilio Studio makes it extremely easy to tweak the way my application interacts with users. For example, the first version of my journal flow would make a phone call to users and use text-to-speech to collect a journal entry if they didn’t respond to the first text. This turned out to be ineffective, obnoxious, and expensive, so I switched it quickly and easily to a second SMS prompt instead.
So I should always use it?
I mentioned that the daily journal ended up being the perfect project for Twilio Studio, whereas other projects might gain very little benefit from it. In my opinion, there are two main factors to consider when evaluating whether or not to use Twilio Studio for a project: (1) you only care about the result of a customer interaction and (2) the set of possible interactions is small and well-defined.
My journal app has a very small set of interactions (you responded or you didn’t) and doesn’t care at all what happened between the first message in a conversation and the final message that contains the user’s journal entry. Ultimately, I was not building a communications tool; I was trying to use communication technology as a front-end that allows users to add data to my service.
If you are building something, however, that requires a lot of open ended responses or requires you to track a comprehensive chat history then this product is probably not going to be as useful to you.
While Twilio might tout Chatbot or Appointment Reminders as viable use-cases for Twilio Studio, I think these are useful as only tutorials more than anything else.
But am I fired?
Not today. Twilio Studio’s Appointment Reminder example can be described as “cute” but it’s still no match for Weave’s Schedule Team. (The hard part about appointment reminders is actually not sending the reminder, and it’s not even handling the response; the hard part is knowing when to send the reminder. Twilio Studio is no help in answering that question).
Just because I am not fired, however, does not mean that Twilio Studio is useless. It is a powerful product that can help developers build innovative software that sparks joy for users.
I appreciated how easy flows are to test and iterate on; there were some moments that I felt documentation or examples could have been a little more fleshed out, but overall I found the product to be extremely easy to use. 4.5/5 stars.
You can sign up to have your own daily journal reminder at https://todayi.page.
