Many people keep asking me why I use Tropo instead of Twilio. It seems that Twilio does a great job of getting the word out about their service, so many people end up using them first. But there are a few reasons I'm using Tropo instead. Basically it comes down to features, scalability and support.
In addition to sending SMSs and calling phone numbers, Tropo can send messages over other text channels such as AIM, Google Chat, MSN, Yahoo IM, Jabber and Twitter, and can also call Skype and SIP numbers.
Tropo recently released Phono, a browser-based SIP client, so you can now do things like have a click-to-call button on your website which will use the computer's mic and speakers to make the call!
Phono also turns a browser into a Jabber client. Your browser gets an address you can use to send messages to via the Jabber protocol. This means you can quickly make a chat interface without having to build the server-side code dealing with sockets.
Tropo lets you set the caller ID of outgoing calls to any arbitrary phone number, which can be used to more tightly integrate with existing phone systems. For example, I'm using caller ID tricks for a client to route calls directly to extensions in their office phone system.
Tropo can do great voice recognition to let callers speak instead of enter digits. For example, you can prompt a caller to say "sales" or "support" instead of just entering 1 or 2 on the keypad. This is especially great for when you need to ask the caller to choose from a large number of options such as states, or cities within a state.
Tropo doesn't charge anything for development applications until you put them onto the production network. This is really great for experimenting with a new idea without running down your development "credits."
Twilio runs on Amazon EC2. Tropo runs in the private Voxeo network. "Co-tenancy is hard." says John from Netflix in a blog post titled 5 Lessons We?ve Learned Using AWS. Personally, voice data and SMSs are not something I want running in a shared environment where resources may be allocated away from a call while I'm on the phone.
Additionally, if you are building an application that needs to be secure, such as for a bank or a government agency, they probably won't allow the application to run on the Amazon cloud for security reasons. With Tropo, you can license Prophecy and run your own Tropo platform in a secure location.
I've had nothing but great experiences with Tropo support. They are very responsive to tickets submitted, I usually get a response back in less than an hour.
There are also several Tropo staff available on their IRC channel (#tropo on freenode.net) at pretty much any time of the day. There are also several community members that hang out on the channel and can help with questions and issues.
Here are some links about projects built using Tropo.
On the weekend of December 4th and 5th, people gathered in coworking spaces around the world for the Random Hacks of Kindness hackathon. In Seattle, two teams worked on Population Centers in Disaster, and Mobile Assessment of Damage for the Public.
After a weekend of much hacking, good food, and good company, we came away with solid problem definitions, UI mockups, and prototypes of an iPhone app, Android app, a website backend, and a voice-powered phone menu.
Mobile Assessment of Damage for the Public
The goal of MadPub.org is to build an application that streamlines the process of reporting and assessing the amount of damage after the occurrence of a natural disaster in the United States. Beta testing will be for the State of Washington.
In the event of a disaster, each county has a 72 hour window to report a dollar estimate of damage to the state and federal government in order meet the threshold for a federal declaration. The current system for assessing and reporting damage has many inefficiencies, requiring government personnel from each county to manually fill out a form after talking on the phone with the person reporting the damage.
To solve this, we are building a system that allows businesses and individuals to report damage on a variety of platforms including: a phone tree with voice recognition managed with Tropo, a web form, and Android and iPhone apps.
Laurel (@laurelfan) and Chi-Bong Ho built working prototypes of iPhone and Android apps! The apps allows you to enter the required information to gather information about the damage, and you can take photos and send them in the report as well. Mark (@malept) prototyped an HTML5 form using jQuery Mobile.
Mark (@malept) and Pat Tressel built a Sahana-backed web form for submitting data, which the mobile applications can also send data to. While that was getting ready, Kav (@kavla) threw together a quick Rails app so uploading from the apps could be tested.
Aaron (@aaronpk) worked on a phone interface for entering the data. This involved a Tropo app to handle the speech recognition.
Speech recognition is a difficult problem in general, but Tropo provides a great platform to make it a lot easier.
When someone calls the hotline, the Tropo application answers the call and offers to provide an overview of the information the caller will need to answer the questions. It then asks a series of questions needed to fill out the form.
Most questions can be answered with a simple "yes" or "no." More complicated questions require more computing power to understand. Even the top of the line speech recognition technologies have a long way to go to understand what people are saying on the phone. How many times have you, a person, asked someone on the phone whether they said "b" or "d"? Now imagine a computer trying to hear that without any context!
Luckily, Tropo provides a way to recognize speech patterns from a smaller set of vocabulary. Tropo has built-in speech recognition to understand numbers, currencies and dates, and you can even specify your own set of options. What this means is that it's far easier to get a computer to tell the difference between "sales" and "suppport" than it is to tell you what word a person said in no context. If you give the computer two options, it can more accurately match what the caller has said.
With this in mind, I set up a system for building survey applications with sets of options. For any questions that have completely free-form answers, such as "please describe the damages to the property," the system records the audio from the caller so that the operator can play back that part of the message later. In fact, every response to every question has the audio recorded automatically so that the individual responses can be played back at a later date.
Here is some sample code showing what it takes to create a survey in this framework.
You can see the different types of responses the Tropo can understand. I added the "[BOOLEAN]" and "[RECORD]" types to the framework which causes Tropo to listen for a "yes" or "no" response, and that will just accept a recording of whatever the caller speaks.
My goal in designing this Tropo application was to make it as easy as possible to set up survey questions and change them in the future. The application takes care of recording responses and tracking answers, and provides the callers' responses in the admin's web interface.
The data gathered from the call is presented to admins in a web view. Here is an example of a transcript of one of the calls. There are "listen" links which will play the audio for that response. Some questions don't have recordings because the answers were determined based on other answers. For example, entering a zip code determines the county and state.