The last time we talked I show you how you can easily build RESTful APIs on top of iON. I just covered just a very narrow scenario, the sky is the limit when talking about the kind of integrations that you can build using iON. So this week I’m going to walk you through another interesting use case, IVRs. If you don’t know what they are, don’t worry I will cover the basics in this article. Stick around it’s going to be wild.
Interactive Voice Response
Now you know what IVR stands for. IVR is the name that we give to systems that allow a computer to interact with a human through the use of voice and DTMF keypad inputs. If you don’t know what DTMF is, then think about the keys on your phone. Every time your press a button on your phone it emits a sound, this sound is then interpreted by the computer on the other end of the line. The sound is different for each number, so the system at the other end of the line can know whenever you actually pressed a two or an eight for example.
You have used IVR systems in the past. All of us have. Almost every company in the world that offers customer service over the phone has an IVR system in place. They are used to service high call volumes, reduce cost and improve the customer experience. Banks use them to let you do simple queries (how much money you have on your savings account) or to perform small transactions. They are also used to identify and segment callers. When you call a call center it will ask for you to identify yourself and then based on the kind of client you are you might get preferred queuing (like a real separate waiting line for premium customers).
Most IVRs systems are very expensive to implement requiring heavy investments in CTI equipment, PSTN trunk connectivity and of course licenses for IVR software packages.
IVRs in the Cloud
Twilio Voice allows you to build voice applications that run on the telephony network. It offers Text-to-Speech (TTS) capabilities, audio playback, audio recording, DTMF keypad gathering, and more. It offers almost (if not all) the features that you would need from a commercial IVR package.
A Voice without a Brain
Twilio Voice only helps us solve half of the solution. Let’s go through the exercise of implementing a system that will read out loud your account balance from another cloud system. The workflow of such application would look like this:
- Welcome the customer to your system
- Ask the customer for his/her account number
- Verify that the account number is valid, if its not go 7
- Fetch account balance information
- Read balance out loud
- Hang up
- Tell the customer that the account number is wrong, and then go to 2 again
Twilio Voice will only helps us solve 1, 2, 5, 6 and 7. We still need to figure out a way to do 3 and 4 on our own. Let’s think about it for a minute. Which integration platform out there, can connect to Twilio Voice and hundreds of other SaaS vendors and runs on the cloud? Right. Mule iON. Twilio Voice will be the voice of our app, and Mule iON will be its brain. Mule iON will orchestrate the entire workflow I just lined out a few paragraphs back. It will also harness Mule Cloud Connect to do 3 and 4.
Getting Started
For this exercise we will be using Zuora as the SaaS vendor. They are an excellent e-commerce platform and we have a top-notch connector to them.
Let’s begin by building a Mule application:
After choosing the defaults when prompted you should have the skeleton of a Mule app. Before we can begin writing our integration we need to add the Twilio and Zuora modules to our project. First add the repository for MuleForge:
And then add the following dependencies under the dependencies section:
Next we need to add XML namespace declarations to our mule-config.xml. The mule-config.xml is located under src/main/app.
Add the following lines after the xmlns:mule-xml declaration:
And then add this schemaLocations under the mule/xml schema location:
So now we are ready to start using those modules. The first thing we need to do is to configure our Zuora connector and provide it some credentials. Just below the description element add the following:
Remember to replace zuora.username and zuora.password by your own. Next, is configuring TwiML:
This is a special configuration for running under iON that will deal with multiple iON workers, you don’t need to worry about this line just copy as it is.
Writing the integration
The way Twilio Voice works is that you configure a phone number at their site and then you give them a URL to hit. That URL will be your app running on iON and it will render the instructions back to Twilio Voice. For example the instructions can be “Say Welcome to the Caller”. To do that we need a HTTP inbound endpoint to receive Twilio’s Voice requests. Erase everything in the main flow and replace it with this:
The previous flow will listen on port 8081 and will render an instruction back to Twilio that will read the text to the caller and then hangup. So if you remember the workflow of the app we are trying to build we just cover step 1. We are welcoming the user. Next is gathering its account number. To do that we need to do something like the following:
After we “say” something to the caller, we will “gather” information from him/her. Prior to “gather”ing that information we will read the inner text in the “say” element. Once the information is “gather”ed the flow in action-flow-ref will be executed. Make sense?
Ok. We just did 1 and 2. Time to do 3 and 7.
When Twilio Voice interacts with us, whatever the user input during a gathering is sent via the inbound header “digits”. Using that we will query Zuora for an account. Then we make a choice between wherever the account exists or not. If it does we go an fetch the balance (step 4), if it doesn’t then we just ask for the account number again (step 7).
We are getting closer. The last piece is actually gathering the balance (step 4) and read it out loud (step 5).
The last flow is step 4 and 5 all in one piece. First we fetch the balance at the zuora:find element, then we format it to something that can be read back to the caller using a custom piece of Groovy and finally we render the instructions back to Twilio.
Wasn’t that easy?
We just created a simple application that allowed you to control an application (in this case Zuora) from any phone. Pretty cool stuff.
You can find the source for this example app in here: https://github.com/s/forum/mule-module-twiml/tree/master/examples
