Telephony Case Study: After Hours Doctor's Office

In this interview we talk with Thomas Howe, winner of the O'Reilly Media and StrikeIron ETel 2007 Mashup Contest with his application After Hours Doctor's Office. He developed this inventive and useful application on top of a variety of Web Service APIs including the StrikeIron SMS Pro API, the Amazon Mechanical Turk API and the Tellme service.

Q: What is After Hours Doctor's Office and why did you build it?

A: After Hours Doctor's Office is a mashup I wrote for the O'Reilly Emerging Telephony Contest. I wanted to demonstrate the impact of integrating real time communications into business applications. As I think the mashup demonstrates, real time communications makes business processes faster, makes them more efficient and makes the customers happier.

The actual application is fairly simple: A patient calls the doctor's office, but it's after hours, and the office is closed. Instead of taking the message and saving it for when the doctor arrives in the morning, I passed the voice mail message off to a bank of nurses. The nurse listens to the message, and then if it's urgent, forwards the message to the doctor. Otherwise, the nurse saves the message for the morning. At each step in the process, the nurse sends a text message back to the patient to let him know what's happening : "A nurse is reviewing your message now", or "We want to have the doctor speak to you on the phone; stand by and he'll be calling you soon."

This scenario can lead to better customer service for patients while simultaneously reducing cost and effort. But what might not be apparent is that I wrote the application in a matter of days, and I didn't need anything but my credit card to charge the $50.00 for the SMS messages. I didn't need any contracts or hardware, and I'd bet that the application is more scalable and robust than anything that would have required contracts or hardware.

Q: What APIs did you use and what was the best and the worst part of using them?

A: I used TellMe to accept the inbound calls and StrikeIron's SMS Pro API. I also used Amazon Web Service's Turk API for handling the nurses that review inbound messages to determine if the message is urgent or not.

Q: What programming languages and tools is this built with?

A: For this mashup, I used VoiceXML for the scripting and PHP for the web logic... everything else was straight HTML and hosting. I've changed my toolset a bit, though, as these days I'm pretty much Ruby all the time. It takes a little while to get into the Ruby swing, but it's worth the effort. It's been a long time since I've fallen in love with a language.

Q: What lessons or issues did you run into when using any of the APIs.

A: It wasn't all easy - although I loved the Amazon Turks part of the mashup, it did seem to take some magic incantations on my end to figure out how to issue the task correctly, especially when the task itself doesn't have a standard format. In in the end, I used a network sniffer to grab the XML as it ran across the wire, and then I had to hand code that in the PHP to make it look right. I know - ugly. Maybe it was my PHP issues. I also had a little bit of trouble accounting for all the error cases in the VoiceXML part of the application. As a standard, XML is excellent at representing data, but I don't appreciate it as much as an approach to programming languages. I'm a much bigger fan of adhearsion.

Q: Using third-party APIs is seen by many as introducing business and technology risk. How do view this issue and how do you account for it in your strategy and implementation?

Well, I think it depends on the third part API you are talking about. We are a little lucky in telephony, as there are several vendors that provide essentially the same functionality through an API. For instance, I used TellMe for the VoiceXML part of this mashup, but I typically use Voxeo. (OK, I admit I was pandering to the sponsors of the contest.) Because I use VoiceXML, it's easy to port from one to the other, and if I wanted to, I could purchase a VoiceXML hardware solution from a number of vendors. Same deal with SMS, although I typically use GlobalSMS pro, just because once you have the account setup with StrikeIron, you can use any of their APIs. Other APIs for telephony typically have many vendors, and it's not too hard to port from one to the other. Sometimes I'll use more than one just for redundancy or arbitrage reasons.

Q: When you say redundancy or arbitrage reasons, can you elaborate?

A: In telephony mashups, many of the web services based APIs are generic. For instance, I can think of three or four click to dial providers. If your mashup will use APIs from more than one provider, you can direct most of the traffic to the lower cost service provider, or you can send all the traffic to one if the other fails.

Be sure to read the next Telephony article: Skype's New Mashup Contest