Analog lines are so 1960

March 29, 2011

Way back in 1961, Bell Labs introduced the T-1. We’re talking 47 years ago. For those of you unfamiliar with the T-carrier system, prior to 1961, all telco traffic was analog signaling over copper wires. Fast forward to now and you’ll still find people ordering a half-dozen phone lines from the phone company to plug into their IVR instead of buying a T-1.

As a rule of thumb, once you need to order 8 POTS (plain-old telephone service) lines from the phone company, it’s usually just as cost-effective to buy a T-1 that can handle 24 calls. A single metered phone line from Verizon will cost you around 55 dollars per month. A single T-1 with all 24 ports activated will cost you around 450 dollars per month. And no, I didn’t make up those numbers to work out so evenly.

The immediate advantage to a T-1 is the fact that it’s a single cable from the demarc to your IVR. Instead, with POTS lines, you have to contend with 8 demarc ports with 8 wires going to 8 IVR ports in a nasty snarl of silver satin wiring. Plus all of those POTS lines are subject to noise, static, and other problems that only occur on analog lines. This makes replacing 8 POTS lines with a T1 a gimme. Same cost, less hassle.

I would, however, argue for replacing as few as 4 POTS lines with a T-1 if you’re planning on taking full advantage of your Plum Voice IVR.

First, 4 POTS lines is still four times more wiring to tangle up than a single T-1 line. You’ll still save yourself headaches.

Second, POTS lines don’t know what number was dialed (the DNIS) so you can only ever run one IVR application on any given line. So if you have 4 POTS lines you can only run 4 IVR applications. With a T-1, the IVR knows what number was dialed when a call comes in on a channel and can then fire up the right application for that particular call. You can have hundreds — even thousands — of phone numbers assigned to your T-1 and any call made to any of these numbers will be sent over a free channel on your T-1 and then directed to the appropriate application.

Third, even if you were to only have 4 applications running on your 4 POTS lines, each application only has one channel available to it. If two people try and call the same number, one gets through and the other gets a busy — just like your plain old telephone service at home. On a T-1, you have 24 channels that can be used for any of your applications. Capacity is shared because, with DNIS-based application routing, every call identifies its own destination.

Fourth, POTS lines don’t tell you when they’re dead. They just quietly stop working. Both ends of a T-1 — your carrier’s switch and your IVR — are constantly trading status information. If the carrier switch ever fails, the IVR will know immediately and you’ll be able to immediately respond to the situation before your callers discover the failure for you.

Fifth, and last, ANI (commonly referred to as caller ID) requires two rings of an POTS line before it’s available to an analog IVR. Sure, call setup time is a minor matter as most callers are willing to wait 10 extra seconds for the IVR to pick up, but wouldn’t you rather have immediate transmission of ANI data and immediate call acceptance?

So unless you’re running only one application and have a high-tolerance for messy wiring, you should go out and replace anything larger than a 4-port analog IVR with an IVR with a digital T-1 interface.

-

2

-

When (not) to use speech rec...

March 29, 2011

Speech recognition is cool. I’m still saying that after working here at Plum for 8 years. It’s cool that the IVR can listen for any US city-state combination being spoken and accurately and reliably recognize it. It’s cool that the IVR can listen for 90% of the given names used in the US. And it’s cool that I can drive an IVR app with just my voice while…um…driving.

But just because something’s cool doesn’t mean it should be used everywhere. Speech rec has been around long enough that IVR designers should know better by now but, alas, that’s not the case in practice. The worst possible example of this is using speech recognition for any IVR application that will be called from a noisy, talky environment: several airlines use ASR in their flight status lines. It’s a strikingly ill-advised decision to rely on speech recognition in an environment like an airport concourse. Even when I’m connected to a live agent while at an airport, I have trouble hearing them and vice versa. Replace that human agent with an ASR engine and you’ll discover there’s nothing more irritating than hearing the airline IVR say, “please say your destination city?” and then having the airport PA system say “San Francisco” loud enough for the airline IVR to hear and accept.

How do most of the airlines solve this problem? They rely on the callers getting frustrated and hitting “0″ to get a human being on the line. But if you’re going to do that, why even bother with an IVR in the first place? Now, instead of having customers calling their agents directly and costing them money, they’re irking their customers first and then transferring them to an agent and still costing them money. It’s a lose-lose situation.

So what’s my solution?

  1. Don’t use speech recognition, instead use DTMF when your callers are likely to be in noisy environments where accuracy is required. People are pretty used to text-messaging now, so if they have to spell “Boston” on their telephone keypad, they won’t be befuddled.
  2. If you absolutely want speech rec in an IVR app that’s to be often called from a noisy environment, design your IVR app to be modal: switching from voice-and-dtmf mode to dtmf-only mode if it seems the caller’s speech input is consistently erroneous.

-

2

-

Introducing Us

March 29, 2011

First post!

We, your Plum Voice blog hosts, will be talking here about IVR and all of the technologies that surround IVR like: VoiceXML, speech recognition, speech synthesis, telephony protocols, and even a little Linux and PHP. We’ll try and keep the marketing-speak and buzzwords to a minimum. After all, we’re engineers who, though employed by Plum Voice, would also be just as happy writing, say, parametric surfboard design software (don’t think I haven’t considered it). Sure, we’ll occasionally cheerlead for something IVR-related but just as often we’ll be the first to start booing some inappropriate use of automated telephony like, oh, an airline building a speech recognition-based flight status line (ever try using one of those in a busy airport terminal?)

Stay tuned.

-

2

-