Ifbyphone Blog

Venture Beat reports that American Express customers can now take Reardon Commerce’s personal concierge with them when they leave home. It illustrates the converging of several trends: context-centric application mash-ups, multiple ways of interacting — voice, SMS, email, Web. This could be taken to the next level with a smart interactive voice application at the end of the click-to-call to increase the efficiency at the other end — think about changing travel plans — and to eliminate typing on tiny keyboards.

Our vision, stated here time and again, is that the phone is the best technology that small and medium businesses have at their disposal. Normally it is in the context of using our technology to drive more conversations (using Click-to-call, IVR applications, Virtual Receptionist, Voice Broadcast, etc).

But today we’re taking another angle. Today we’re showing off a demo of a time entry application. There are a number of businesses that have workforces that are primarily in the field. The fact that the main office is in a physically different location than the workforce presents any number of challenges.

The main office wants information from the field (status of jobs, time spent), and they may want to send updates to the field (a change in priorities, a new job, etc). But how do they enable that kind of communication?

You could just have everyone calling each other day, but then no actual work would get done. You could use tablet PCs or SmartPhones with custom built applications. But think of the associated costs. The development cost for this type of application is going to be significant. The developers are going to have to learn a particular mobile phone OS and the associated SDK. Plus, you are going to have to purchase and support the hardware. Then you are going to have to train the users on the device AND the application.

Once you get done with all those costs, it’s clear that the return on investment is going to be negative.

Wouldn’t it be easier if you could do all those things just using the phones all your workers already have? Using IfByPhone’s API, you can do just that. We have developed a bare-bones Time Entry application. This application allows you to input an Employee ID, a JobID and start and end time. Here is how the demo works.

An employee would call a phone number, and it will ask them for their employee ID. After validating the Employee ID, it will ask them for the Job number, the starting time, and the ending time. Once the call is complete, IfByPhone posts the results to a webpage run by the company recording the time. Then the data can be thrown into any internal database they want.

This is a pretty bare bones application. But with some customization, you can imagine some pretty powerful possibilities. For construction companies, you could allow a foreman to authenticate himself, and then enter in not only hours worked for his crew, but potentially request new equipment, enter in amount of product used for a given job, etc. If you have technicians in the field, you can use your existing database to direct them to the next job (potentially including step-by-step directions).

So please, try this out. Click the phone to enter some data (look below for valid Employees and Jobs).

Then go see the results pop up in real time here.

The app will ask you for an Employee ID (11111, 22222, 53581, and 49525) and a JobID (11 and 22). I feel the need to emphasize: I am not a graphic designer, and this is simply a demo. So the data page ain’t pretty. And we’re not doing things you want to make sure to do in any real application (user validation, validating the job #, etc). This is simply a demo meant to show how our voice applications can extend to external systems and databases. I’ll be posting the files to the download section of PhoneMashup in a couple days.

Click here to talk to Khyle.

Recently in this space we’ve talked about the lack of interesting VOIP Applications. It seems that people all over are asking where the apps are. No less than Jeff Pulver has decried the lack of innovation in this space. At first, I objected to Jeff’s post, saying that there were several companies doing interesting things (us being one of them!). Then I had the chance to chat with him, and immediately came to the conclusion that he was indeed correct.

The functionality that IfByPhone provides, the tools we offer, are not in fact innovative. Shocking, isn’t it? And in actuality, I’ve said that here in the past. Big companies started adding voice to their existing applications years ago. Airlines use it to notify fliers that there is a flight cancellation. Prescription companies are making it easier to refill medications. There are a million uses.

So the tools have been around. The trick is that in order to use voice in applications there has been, historically speaking, a huge amount of overhead. You have to get a delivery mechanism - a physical way to make the calls. Then you have to monitor the ports, support them when they go bad. You have to get telco providers. Probably you will have to hire support people in IT to monitor and maintain the whole system. You have to hire and support very specific types of developers (ones that understand VXML). Developers that likely will only work on voice applicaitons. You have to maintain very comlpex code, and any changes to your applicaitons are also going to be expensive. Rolling out new applications? Start from scratch.

If you are a huge company, you have options. You can play off a couple vendors who do big-league IVR systems against each other, and get them to eat the cost of development. They probably deliver phone calls for a living, so they’ll eat that cost because you are going to send them more than enough traffic to make up for it.

But let’s say you’re not a major airline. What happens if you don’t drive millions of minutes of traffic? Well, you are out of luck. No matter what the ROI would be, adding voice to your business operations was a non-starter. You simply can’t get over the hump to make the effort worthwhile.

Here is the true power of IfByPhone. We make it easier for any developer to use voice. I talk to a lot of developers who want to use our tools to add voice to their applicaitons - and the number one thing I hear in almost every conversation is ’straightforward.’ If you have a developer that can run a query on your database and write a little PHP or ASP code, that’s all you need.

We’re a better tool box. With us, you use a GUI (graphical user interface) to design the application. Then you access it securely over the internet. We’re the right tool for the job, if the job involves voice. I would strongly recommend you spend 15 minutes today thinking of all the various aspects of your business that you don’t like doing. What are the things you have to do, but take you and your employees away from creating more revenue? What are the things you’d like to be able to do but don’t have the time?

Do you like following up on late invoices? Do you want to call and remind people of their upcoming appointments? Are you using a call center but are spending a lot of money while they ask or answer the same questions over and over? Are you gathering leads and losing money because you can’t verify their phone numbers or they go cold? Would you like to use your knowledge of your customers to combine an order received phone call with an upsell?

We have the tools to solve all those problems. All you need to do is sprinkle a little PHP on it (or ASP if you like), tie it with your database, and you have your voice enabled application :). Don’t read me wrong, it will take work. But if you have access to a developer you trust, you should strongly consider adding voice to your line of business applications. The ROI will amaze you.

If you are a consultant or a developer, spend a few minutes trying to understand your clients’ pain points as they relate to communicating with their customers. Pitch them on ways you can make their life easier and make them more money, and watch their reaction. To paraphrase “Field of Dreams” - “Build the apps and they will come.”

If you’d like to talk to me about it, click here.

Creating an IVR (Interactive Voice Response) can be as simple as recording a few prompts, telling a customer to press one or two, and routing the caller to an operator at the end of the call. But to create an effective, seamless, and confusion-free IVR that allows you to use a computer where a live person once was needed requires more thought and planning. It doesn’t need to be a painful process, but careful outlining of what you want to do and, more importantly, what you want a customer to do will ensure an IVR that is not just another component to your business but an essential feature of your business’s communication structure.

So, you want to create an IVR to expedite telephone product sales, manage a customer service department, or develop a phone directory for a 100-employee company (or a 5-employee company). Now what?

1. A good IVR is short and to the point – no unnecessary questions or prompts. The first thing you need to do is think about what the most important pieces of information are that you want to deliver to your customers or that you need from them. A good way to manage this process is to think about the five most important prompts or questions you want to play for or ask of your customers, and begin there. Then, as time goes and as you continue to watch how the IVR is working for you, you can add or remove those prompts and questions that do not add to the overall quality of the IVR. Less is more. Start with a few prompts and build as your employees or customers get more comfortable with it.
2. Create an effective opening prompt. Be brief, concise, and polite – watch out for 30-second introductions or too many multi-syllabic words, and make sure you appear grateful that the employee or customer is calling in to your IVR.
3. Have the system refer to itself as “I.” Customers prefer to hear a first-person IVR rather than a generic “system.”
4. If you have an IVR that is longer than four prompts, let a caller know what they can expect from the system immediately. Customers don’t like it when they can’t see the end of the tunnel. Either have the IVR share how many questions and which they are answering or provide some glimpse of the number of questions or time it will take to complete the IVR in your introduction.
5. Take advantage of Ifbyphone’s speech-recognition software and give customers the option to traverse the IVR by either using touch-tone buttons or speaking their answers. Make sure they know that speech is an option.
6. If you decide to allow speech-recognition answers, make it clear what the answer needs to be and use two or three syllable responses so as not to confuse the customer, or the system. Answers of a couple words can work well because they give the system a more precise speech target to search for.
7. Be concise, and make sure that you use the same language to describe the same nouns or processes throughout the IVR. An article on the Ifbyphone blog titled “How To Make Prompts Consistent” does an excellent job of explaining just how to do this. Break down the different “names” (what you would call something) and “actions” (something you ask a customer to do), and ensure that there is a consistency throughout. If you tell a customer to “enter two” at one place and to “press three” in another, you’re not being consistent. Likewise, if you call something a “menu” in one prompt, you don’t want to refer to it as a “message” later on.
8. Think about the Barge-In Factor. On the Ifbyphone system, you have the option to Allow Barge-In or not. If your customers will be interacting with an IVR in a loud place, the background noise may affect the voice recognition system, and you may not want to allow barge-in. However, if you expect most customers to be at home or in an office, then barge-in is a useful feature to speed up an IVR.
9. Think about the Touch Tone Only Factor. If you select this, the system won’t accept any voice responses, only numbers entered in on a touch tone phone. It’s another useful tool for customers who have a lot of background noise, but also a convenient way to simplify an IVR. Giving customers the option to say or enter in their responses isn’t always necessary; sometimes the simple press of a button will do. If you turn on “Touch Tone (DTMF) only” and Allow Barge-In at the same time, you can create an IVR that is very quick and easy to navigate.
10. Create an option to always allow customers to access human help and let them know about it. Depending on the type of IVR you are setting up, you may want to keep in mind that people become frustrated, annoyed, and may eventually hang up if they cannot access human help when the IVR doesn’t appear to suit their needs.

In a recent NY Times article we learn that Microsoft, whose philosophy for the last 25 years has been to build “shrink-wrapped software,” is slowly moving towards the Web 2.0 side of the Net and introducing MashUps into its development plan. While it’s hardly a trend at the company, it does show a transition from Microsoft, who has often been reluctant to stray from its lucrative mold, towards the Web-based applications popular at Google and in the rest of Silicon Valley.  Add this to Microsoft’s bid (rejected this morning) of Yahoo! and we see a stark difference in the way this company is beginning to do business.

The technology is there. Combining different modes of communication across the Net has never been easier. And now we see the Emerald City Superstar slowly moving towards the future. Have you looked into how MashUps can improve your company’s infrastructure and bottom line?

Every minute of every day, somewhere, someone is pounding on their keyboard, or screaming at their computer, “How do I contact the people behind this web site, or this blog?” Too many web sites make it difficult for viewers to connect.

Later that same day you might become frustrated because the emails you sent to a business associate or friend landed in the black hole of a SPAM folder. Or maybe you were away from your computer and the screen on your phone is just too small to read, but you need to check on the delivery of the sofa you just ordered. If you call the sofa company they will put you on hold, forever. You just want to know the date of the delivery - why should this be so hard?

All of these examples are easily solved by better utilizing the everyday, plain old telephone. Telephones are everywhere today, at home, at work, in our pockets. Phone mashups combine the intimacy of the telephone with the efficiency of the web. In the examples above, you could provide a web site visitor with a Click-to-Call that connects the viewer’s telephone to your telephone. You could use an automated Voice Broadcast to send messages to your customers. With an Interactive Voice Response system, the sofa company could provide you with instant customer service while saving on staff and reducing costs.So why doesn’t every small business, web site creator, or blog author integrate their web world with their viewers’ telephones?

While the VoiceXML and CCXML standards have driven down the cost of custom IVR, these solutions are still too complex and expensive for many independent developers and small businesses. Many Click-to-Call solutions now available in the marketplace tend to be limited in flexibility. Phone mashups require flexibility.Phone mashup APIs need to be usable by any web developer with basic web form coding skills. In essence, the phone mashup API should replace web forms with voice forms.Ifbyphone provides a very flexible family of APIs (we call them Ifbyphone Glue) that includes the ability to:

• Initiate a traditional Click-to-Call between two parties
• Initiate a Click-to-Virtual Receptionist
• Initiate a Click-to-VoiceMail
• Initiate a Click-to a full featured interactive voice response system
• Initiate a Click-to a Find Me with full recording capabilities

Ifbyphone APIs also support the scheduling of voice broadcast messages, reminder calls, and wake up calls.In addition to initiating telephone connections from a web site, the communications facilitated by the Ifbyphone hosted platform may be activated from a telephone call. When someone calls into an Ifbyphone provisioned telephone number their call can be:

• Routed based on the caller ANI (caller ID)
• Routed based on the time of day and day of week
• Routed to a voice mail account
• Routed to a find me
• Routed to a virtual receptionist
• Routed to an interactive voice response application (IVR)

Ifbyphone IVR applications can be thought of as voice forms. If you know how to build a web site that uses a form to collect information, processes the information, and then displays another form, you know how to build a phone mashup.

SurVo Voice Forms** are created at the Ifbyphone web site and then invoked by an API or telephone call. A voice form consists of prerecorded or text-to-speech prompts and questions that are played for a caller, and then allows their responses to be recorded or converted into text.

When the caller reaches the end of a voice form, the Ifbyphone platform passes control to a web page you create. This web page can be hosted on any server, coded in any language and secured or unsecured. Your web page will receive the data collected via the telephone dialog (voice form) as a post or get in the same way you would collect information from an HTML form.

Once you have the data you can write it to a database, use it to query another web source, or process it in just the same way you would process information collected from any other form.  After processing, your web page outputs an XML file which tells the Ifbyphone platform what to do next. The next step can be another voice form, a find me, a virtual receptionist or even to just hang up the telephone. Data provided by your web page can be read to the caller or can be used to determine the next set of questions asked.

There is no limit to the number of voice forms or the number of transitions between your web pages and the Ifbyphone infrastructure.

To summarize, the Ifbyphone Glue (API) supports the combination of information accessible from the web for presentation via voice on any telephone.  All Ifbyphone services use real telephones and do not rely on desktop computer based VOIP services.

To learn more just take a look at the Ifbyphone Glue (API) documentation.

Ifbyphone Glue (API) Documentation

All Ifbyphone Documentation

**The name SurVo comes from the fact that initially this technology was built for creating customer surveys.

While there are many telephone technology conferences each year, two stand out. VON and eComm. VON is where the business professionals in the voice and telephony industries go to make deals. eComm is where the technologists go to innovate.

Prior to this year Etel (the predecessors to eComm) was an O’Reilly sponsored conference designed to provide a forum for people working in the emerging telephony technologies to get together, learn and network. When O’Reilly decided to drop the Etel conference a ground swell of discussion in the telco world lead Lee S Dryburgh to put his day job on hold and facilitate eComm as a replacement. As stated on the eComm site:

“eComm is the venue for those interested in the radical transformation of the trillion dollar telecommunications industry. It has already started down the path that the homebrew computer took three decades ago. Just as democratized computation gave birth to the computer industry, eComm is tracking, highlighting and promoting the people and technologies driving this new wave of democratization.

eComm brings out the visionaries, emergent technologies, real-world startups, cutting-edge academic projects, views from the incumbent telecom players; garage based hacks and stirs required policy debates to create the ultimate three-day conversation.

The story of the decentralization of communications innovation has past the second chapter which was VoIP. It is now regarded as a building block only. As a standalone service it is both uninspiring and unlikely to be highly profitable.”

The Ifbyphone phone mashup API is an ideal vehicle for developers looking to build creative web to phone applications. At my eComm 2008 talk I will describe the Ifbyphone architecture used to drive down the costs of sophisticated IVR applications while making them accessible to any web developer or small business.

Information about eComm 2008

Here’s a short letter from the editor of Speech Technology Magazine, the one company you’d think would positively, absolutely get their phone IVR to sound absolutely wonderful. That turns out not to be the case… in fact, they don’t even use speech recognition!I know they investigated and solved the problem (I visited their offices recently); when they provide a follow-up letter about this incident I’ll post that link as well.The moral of the story: think for yourself and think for your customers. First, think for yourself. Don’t blindly copy idiotic statements from other systems (”Please pay attention as our menu options have changed”) that are (a) not true and (b) not useful.And second, think for your customers. Again, it’s easy enough to put yourself into your customer’s shoes. Will your customers be mollified if you say “your call is important to us” or will they feel patronized? (Hint: when you call someone else’s system, how do you feel about that announcement?)

One of the most important things I do when I write an application is check for consistent prompts. What do we say to the customer? Do we say the same thing everywhere, or do we suddenly change our minds half-way through the application?Here’s an example from what I’m working on today. The client supplied the following prompt:

Press # or say “main menu” at any time during this message to go to the options menu.

How do I check this prompt to make certain that it’s (a) consistent and therefore (b) not confusing?I start out by underlining each individual “name” and each individual “action” in the prompt. A “name” is the name of something: for example, what you and I would call an account number some applications call a “customer number.” An “action” is something that we ask the customer to do, or that the customer wants to do; for example, we might ask the customer to “say” the account number, “press” a button, or the customer may wish to “transfer” funds.Here’s a table of all the names and actions I found in the prompt, in order:

Then I start checking for consistency. I looked through this application and made a decision: during the application, we will always use “press” consistently; we won’t use “press” in some places and “enter” in others. We will also use “say” consistently.But the rest of this prompt poses further problems. First of all, the action “#” (pressing that particular key) isn’t consistent with other places; it’s the only # in the entire application. The “options menu” wasn’t defined anywhere — in fact, although I am developing the software, even I can’t figure out which menu is the “options” menu. And furthermore why require someone to say “main menu” if they want to go to the “options” menu — that’s not consistent even in the same prompt! Actions should always be consistent with names whenever possible.”Go to” is an action that the user might want to do, but the wording has to be consistent with other places in the application. Finally, the name “this message” might not be consistent with the idea that we’re in a “menu.” Is this a “message” or a “menu?”In the end, I was able to straighten this out. The call flow is really just returning the user to the previous menu, and now I use the words “previous menu” everywhere in the application and also always use the * key to or the words “previous menu” to get there. I also use “return to” when I’m returning rather than “go to.” The prompt now reads something like this:

To return to the previous menu, say “previous menu” or press *.

I use the exact same wording for this prompt everywhere in the document.With consistent prompts, callers will be more comfortable with the application because they won’t have to re-learn how the application behaves each time they encounter a prompt, and they can focus on the content of the questions rather than trying to figure out what the questions mean in the first place.

Voice Broadcast used properly is an effective and reliable alternative to email. Ifbyphone’s services are ideally suited for delivery of customer service information, customer notifications and employee communications. All information valuable to the recipient.For example, let’s say you own a heating and air conditioning company. You used to send emails to your customers in the spring and fall to recommend they schedule a tune up of their air conditioner or furnace. The last couple of years your customers have complained “John, why don’t you email me a reminder anymore?”. But you do. What’s happening. Your emails are going into your customer’s spam folders. Spam technology has rendered email an ineffective customer communications tool.
Instead of using an email message use a Voice Broadcast. Record a short 30 second message to each of your customers. Schedule 20 of these messages to go out a day and offer the customer an option to transfer to your office and make an appointment during the call. Just as email used properly enhances your customer relationships and improves sales, Voice Broadcast used properly is a more reliable delivery vehicle then email, which all to often today ends up in someone’s spam folder.