My Wife has an IVR-killing Superpower

A couple of months ago we dropped our traditional landline and began using the AT&T U-verse voice service. Shortly after that I discovered my wife’s unusual superpower.  It started innocently enough - we chat on the phone a few times during a day. That’s normal, right?

I should mention my wife is a multi-tasker and has a habit of resting the cordless phone on her shoulder as she types on a keyboard, rinses dishes, or performs an appendectomy. Often her cheek or chin would touch the keypad and voila, I would hear random touch tones.

After our switch to U-verse, I began thinking my wife was really leaning on the phone. I would hear two, three, or four tones in every call.

My complaints were met with firm denials and that’s when we figured it out: her voice triggers U-verse touch tones! She does not hear the tones. They are produced in the network in response to her voice. Is this an odd in-band signal problem?

It seems to be related to vowels; it’s not sensitive to volume, thankfully, so I am spared additional tones during our occasional debates about global warming or whether the right person was eliminated from “So You Think You Can Dance.”

Unfortunately, she has yet to master her superpower, so my requests to hear “Jingle Bells” or Iron Butterfly’s “Inagodadavida” go unfulfilled.

But as someone deeply involved in IVR services, I am struck by how her superpower can wipe out an IVR program. Imagine an application that allows a free-form recording of a consumer problem. In many cases, the recording can be stopped by pressing a touch-tone. Imagine the irritation generated when the consumer is recording a complaint and is interrupted by the IVR program as it prematurely moves to the next dialog after the recording.

Is this an isolated problem or is this something to be expected in our new world of hybrid traditional and SIP telephony? Is it time to change the default value of the dtmfterm attribute (of the <record> tag) from ”true” to “false”?

My wife’s talent is not yet listed on www.superpowerlist.com, but I am sure it will be soon. Next we need to work on a cool superhero name. Any ideas?

The Art of Estimating

One of our main objectives at MTI is to provide speech solutions to customers. In order to get buy-in from potential stakeholders, we have to provide accurate estimates of the cost of development of these solutions. Remarkably, there is little objective research on what a “typical” speech dialog should cost. Of course any dialog can be simple or complex and have one or more simple or complex grammars. But it seems like we should have enough experience and enough talent to be able to effectively ballpark the costs. And we in the industry do, sort of.

Many of us have been taking our estimation process seriously for quite some time. Others simply try to price development work on the basis of how an application can save money when compared to live agents (for purposes of this blog, I’ll call that “value pricing”). That might work one time, depending on whether the prospective customer has done any competitive shopping. This kind of pricing gives the competition an easy opportunity to undercut based on the “true” costs involved in developing and supporting an application; true costs, even with reasonable profit margins baked in, invariably are lower than the costs proposed by value pricing.

Try as one might, value pricing just won’t hold water these days. If the client was naïve enough to accept it the first time, they’ll most likely be better educated by the time a new project rolls around. The incumbent has a distinct advantage, for sure, but price drives sales. So we at MTI believe the way to encourage more speech applications is to develop what the customer wants at a cost that reflects the actual software development effort.

The key to turning the art of estimating into a science is to have solid history of what it took to build prior projects and to use that history to build ever more accurate estimates. And yet most developers and engineers consistently seem to ignore their history and continue to underestimate what it takes to fabricate and support quality applications. Why is that?

I think it’s because developers and engineers look for ways to be appreciated. Too often they aren’t. Deep down they know that they’ll get a big smile and a pat on the back if they promise to deliver anything at a low person-hour count. Pleasing your boss is a good thing, right? That works well until an “estimate” is missed, usually by someone announcing that a deadline is slipping by x days, weeks, or months. Too often that announcement comes very late in the development cycle. Then your boss isn’t so happy. And neither is the customer.

The trick is to motivate engineers to provide accurate estimates by rewarding accuracy. It is equally vexing to have estimates that are too low or too high. Neither does anyone any good.

So for a number of years now we have implemented a systematic approach to estimation where we look at the number of dialogs, database interfaces, web services needed, prompts, ongoing analytics, etc. to construct a reproducible, reasonable, and realistic estimate of what it takes to make and support something. Sometimes the numbers are surprising. But because of the granularity of the estimate, they are hard to argue against.

Honestly, it is a process that has no end. But it is a measurable process and we have made good progress. And, not surprisingly, our estimates continue to go down as we gain more and more experience and develop more and more reusable modules. Soon we will be able to actually tie a portion of our engineers’ annual reviews to how accurate they are in their estimates. That’s a good feedback loop. And a great motivator.

300 Knot Club

Well, yesterday it happened. I was cruising from Dallas to Atlanta at 17,000 feet, West of Atlanta near the Vulcan (VUZ) vortac. I picked up a hefty tailwind and managed to squeak out a 300 knot ground speed. That’s about 345mph. That’s a first for this plane! The picture shows the ground speed on the Garmin G1000 MFD; it’s a little out of focus due to a little chop. Fast is fun. ‘Nuff said.

300kt_200802264.JPG

My Intro

Welcome to my first post! I’m Mark Abramson, CEO/CTO and co-founder of Message Technologies, Inc. (MTI).

My goal will be to discuss what’s happening in my professional life, which spans about 37 years (unbelievable) and includes over 35 years of practical experience using speech recognition, text-to-speech, and touch-tone systems. Yes, the technology has been around quite a while and I’ve seen and done a lot with it. I want to include observations and perhaps a few “pearls” I’ve discovered over the years of working with this technology and the people who develop, deploy and tweak it.

I guess I am officially a serial entrepreneur, although I wouldn’t call what I do “rapid succession.” I’ve been involved in six or so startups, made money on a few and broke even on a few. Overall, my track record has been good and my instincts have proven more right than wrong.

My blog may occasionally include some aviation items, since I am an avid private pilot flying a 2007 Columbia (now Cessna) 400SX. I’ve logged about 1,100 hours so far. For those who like alphabet soup, I am officially a PP, ASEL, AMEL, IA. I have high performance, complex, and tailwheel endorsements and I’ve had a little experience flying aerobatics. All this means I normally can fly single and multi-engine land-based aircraft in the clouds. One day I hope to get my seaplane rating.

So I have two passions: work and flying. Happy blogging.

P.S. I guess I need to deliver the standard disclaimer stuff like the opinions in my blog are my own and not that of my company. I assume full responsibility for the content of my blog and if you take issue with anything I write, please take it up with me.