Monday, June 27, 2011

Your phone in a browser

Last week, Google announced that they had begun working "to enable Chrome with Real-Time Communications (RTC) capabilities" - in other words, to allow your browser to send and receive streaming audio and video. Instead of having to download to download software to make calls, such as with Skype, or install a special plugin, such as with Gmail's voice and video chat, these applications could be built directly into the browser. Whoa!

The beautiful thing about WebRTC, as the project is called, is that it will give developers a standard way to write web applications that use real-time audio and video, using the same Javascript programming language that they already use to make web pages more interactive. This should open the door to more of these types of applications, as it will be much easier to develop them. And since WebRTC is sponsored by Mozilla, Google, and Opera, users of their  won't have to install any special software to use web applications that take advantage of WebRTC.

One obvious application of WebRTC is to build a phone in your browser. Perhaps Impact Dialing will use it so that you don't have to use a separate phone to connect to our hosted predictive dialer - instead, you'd connect directly through our web application, using WebRTC.

What else could WebRTC be used for?

Tuesday, June 14, 2011

The future is self-service

At the airport in New York the other week, I went to the counter of a Chinese restaurant to order some food for the long flight back to California. Nobody was at the counter, and nobody seemed to be paying any attention to me. And then I realized that the computers on the counter were facing the customers, not the staff. I was shocked. What a brilliant idea! How could nobody have thought of this before? Everywhere, businesses are finding ways to turn the computer to face the customer: all banks now have ATMs, most airlines have self-checkin kiosks, some grocery stores have self-checkout stands, and now restaurants are experimenting with lettering customers place their own orders.

The key change that's allowing self-service to expand, and the sticking point that causes it to fail and frustrate when done poorly, is user interface design. Remember old checkout interfaces at grocery stores? The green text on white screens, the cashiers furiously keying in codes? The amount of time needed to learn a system like that made self-service impossible. Self-service checkstands now have big colorful buttons with pictures, and, most importantly, fewer options. In the best-designed self-service grocery stores, you just scan the barcodes of all of your items. It doesn't get much simpler than that. Where self-checkout doesn't work as well is where this simplicity breaks down - most notably, when you have to tell the system which fruits or vegetables you are weighing. Some grocery stores fix this by packing produce and putting barcodes on them.

Impact Dialing is doing something similar with auto dialing. It used to take an expert to set up an auto dialer: there were a massive number of settings and options to configure, you'd have to install special hardware and software in your call center, and you'd need consulting and training from your auto dialer company to set things up and learn how to use the system. We've taken away all of that pain: made everything web-based, so there's nothing to install; simplified complicated settings and used plain English in our interface; and made the whole thing available to anybody who wants to try it out.

Are you creating beautifully-designed self-service tools? Have you used any that made your day? Or that made you angry because they didn't work as well as having a real person work with you? Leave a comment!

Wednesday, June 8, 2011

Auto dialer terminology (or, Wow, this is confusing)

Ever wonder what the difference is between an auto dialer and a predictive dialer? Can't keep your robo calls and your outbound IVRs straight? It's all very confusing.

In designing Impact Dialing's website, I spent a lot of time researching what search terms people actually use in the world of making lots of phone calls. I chose the the terms below based on this research and my own experience.

The term "auto dialer" is the most confusing phrase of them all, and a good starting point because of its generality. I did a Google search for auto dialer and came up with a few excerpts from its snippets:

  • "Software for broadcasting voice message by phone"
  • " automated phone dialer for voice message broadcasting..."
  • "An autodialer will call one or more programmed phone numbers..."
  • "... allows for hands-free calling..."
There are a lot of terms and ideas thrown around here. About the only thing they all have in common is that they involve automatically dialing a list of phone numbers. At Impact Dialing, we refer to all of our services as "auto dialer products", to reflect the different meanings that different people attach to the phrase "auto dialer". 

So if auto dialer is a vague, nebulous phrase relating to anything that automatically dials a phone number, then what are concrete examples of auto dialers? One term that showed up a few times in the above Google search is "voice broadcasting". Voice broadcasting is a kind of auto dialing in which a pre-recorded message is played when somebody answers the phone (or is left on an answering machine). Voice broadcasting messages are also sometimes called "robo calls". 

Pollsters often use robo calls to survey people, by asking them to press a keypad on their phone corresponding to different choices: for example, "Press 1 if you play to vote for the Democrat, press 2 if you plan to vote for the Republican." Sometimes people call these robo surveys, but they're more commonly referred to by a more technical name. Gathering information from pressing phone keypad digits is called Interactive Voice Response, or IVR. When it's used on outbound calls (as opposed to inbound systems - "Press 1 for Sales, 2 for Support"), it's sometimes called an "outbound IVR system". 

Our Google snippets showed us that people also use the term "auto dialer" for a system that connects answered dials to live people. The most common term used for live phone calls is "predictive dialer"; when a predictive dialer is offered as an online service, rather than as a piece of hardware, it's called a hosted predictive dialer. Some people also use the term "power dialer" to refer to an outbound dialing system. Although sometimes "power dialer" and "predictive dialer" are used interchangeably, the more technical distinction is that a predictive dialer uses real-time analysis to determine the optimal time to make dials (see this blog post for details), whereas a power dialer simply dials a pre-set number of lines when a caller finishes the previous call. 

So, in summary:
  • auto dialer: anything that automatically dials phone numbers
    • voice broadcasting: when somebody answers, play a message
      • robo calls: another name for voice broadcasting
      • robo surveys: press a keypad button to provide feedback
        • outbound IVR system: another name for robo surveys
    • predictive dialer: when somebody answers, connect them to a live person, and use realtime analytics to determine when to dial again
      • power dialer: use a simple ratio when somebody finishes the previous call
This is not an exhaustive list, but it touches on some of the most common terms and hopefully provides some clarification. 

Monday, June 6, 2011

Smaller is better: designing for usability

Yesterday somebody called to learn more about Impact Dialing and raved to me about how well-designed it is. He had looked at a half dozen other dialers and said that ours was far and away the best-designed and easiest to figure out. I don't claim to be a design expert, but I think we're on to something in terms of our usability, and I want to share our design philosophy.

My experience suffering through my now-competitors' poor design was one of the reasons I started Impact Dialing. For example, on logging in, one system presents the user with a blank screen and a series of drop-down menus. The only way to figure out how to use it is to explore the menus and sub-menus, opening up new windows and navigating deeper and deeper into each window's sub-application. Another dialer tried to be more user-friendly with a step-by-step wizard, but in order to change anything, you have to go through the entire wizard again. Both systems used specialized jargon that non-experts would never understand. From my frustration, I came up with a series of design principles:

  • Users shouldn't need to read a manual
  • Make everything accessible with minimal clicks
  • Use good defaults, so even if you have no idea what you're doing, you can still get set up
  • Use plain English and avoid jargon

I started out by breaking down the task of setting up a predictive dialer: you need logins for your callers, a script for them to read and record answers to, and a list of phone numbers for them to call. I used Mockingbird to wireframe a layout in which these three concepts - Callers, Scripts, and Campaigns (which contains lists and a few other pieces of information) - were tabs along the top. This would present users with everything they needed to access intuitively and with minimal navigation, so that they could work from left to right to set things up the first time.

Even with this simple design, I knew some people still might not think about needing to set up caller logins, so we made a default caller login for every new account. Similarly, new users might not know what their scripts should look like; since many of our clients make political calls, we made an example script and corresponding call results for political campaigns. Finally, I knew that some people still might need a helping hand along the way, so we created a "Welcome" tab that opens when users log in and displays a quick run-through of how to use the system, along with a video guide.

At this point, we released Impact Dialing. We just had the bare minimum features needed for a predictive dialer, which in my mind, was actually an advantage: we had a clear, simple, easy-to-use design, something that none of our competitors can say.

As our product has developed, we've been very careful with how we add new features. We eye anything that adds very much complexity with great suspicion, and try to think of simpler approaches whenever possible. All else equal, we always build simpler features before more complicated ones. And if somebody requests a feature that's tied in with other features we're considering, we'll try to wait to build it until we really understand the whole set of features.

For example, we originally only allowed one set of results per script, so if you had two questions in your script, you'd have to list out every combination of answers in your results list. A few people had asked for multiple results, but we knew that we'd eventually support free text entry and patch-through calls, and so we waited until we were sure we understood all of the use cases we wanted to support. Patch-through calls were going to take a little more work, so we just built out the multiple results and free text, and came up with a fairly elegant interface. We've got some more ideas about how to make the system even more flexible, but even now, it's still as straightforward and simple as our original design. That's how we like to improve things.

The final piece of our design approach is to remove and streamline when we can. For example, we originally required new users to enter their first name, last name, organization, email, password, password confirmation, and agree to the Terms of Service. When we re-designed our site, we stripped down to just email, password, and Terms agreement. If somebody entered their password incorrectly, they could always recover it later. Everything we decided was nice to know but not essential, and we'd rather err on the side of simplicity.

Do you have or know of a well-designed web site or web application? Please share in the comments below!