IVR Deconstructed

Last week I talked about audio encoding formats but did not address how the decoder knows how the encoder encoded the audio (try saying that ten times quickly!)

There are really only two ways to address this issue. Method one is encapsulating the data with the encoding descriptors. Method two is…to guess.

The only encapsulation file format supported by the Plum IVR is Microsoft .wav which is derived from a format called RIFF. People often think that Microsoft .wav is both a file format and an audio encoding format. It isn’t. .wav/RIFF is independent of the audio encoding. Without getting into too much detail, you can think of the .wav/RIFF format as merely an envelope; the data enclosed within the envelope can be encoded any number of ways from PCM or u-law (as mentioned last week) to MP3 to various proprietary audio encoding formats. Thus, it’s important if you are going to create a .wav file that you also make sure that the audio is encoded using one of the formats mentioned last week.

That all said, you could also just send the IVR raw audio data and have the IVR guess at the format. You do, however, have to give the IVR a bit of hint in the form of an appropriate file name extension. If you encoded your audio data as 8kHz 16-bit PCM mono, just slap a “.pcm” on the end of the filename and the IVR will assume that’s the format. On the other hand, if you recorded your audio data as 8kHz 8-bit u-law mono, add “.ul” to the end of your filename. These types of files are often referred to as “raw, headerless” files because there’s no metadata whatsoever in the file — it’s all pure audio data. The downside to this is that there’s nothing to stop you from recording 11kHz 8-bit PCM stereo but still naming the file “whatever.pcm”. The IVR will load it, assume the data is another encoding format, and produce some noisy garbage over your phone lines.

One final thing to mention are MP3s. The Plum IVR can handle MP3s just fine, however, we often hear complaints about the decline in audio quality between what someone hears when their MP3 is played over their headphones and what is ultimately heard over the phone. Bear in mind: the phone system was never intended to transmit high-fidelity audio. That’s why we usually recommend the lossless formats instead because ultimate sound quality can be better controlled by the application developer when what he or she hears through headphones closely matches what they would hear over the phone.

So what would I recommend as the audio encoding format and file encapsulation format? We usually recommend .wav encapsulation of a 16-bit linear PCM, 8kHz, mono audio file. A) the file is self-describing, and B) “16-bit linear PCM” is common to all audio production software. Ideally we’d prefer to recommend u-law instead of 16-bit linear, but u-law often confuses people because it’s sometimes referred to as “mu-law” or sometimes “μ-law”. As usual, our support forum at http://support.plumgroup.com/ is always there to help you work out any audio production issues you might have.

Our fine engineers here at Plum have added a new question type to our survey application: the transfer question type. The transfer question type allows the survey designer to insert a phone call anywhere in a survey. This feature, when paired with skip logic, is quite powerful indeed as I’ll discuss further down in this post.

But first there were some design challenges associated with adding this feature:

• It’s only available for the IVR version of a survey. We felt there wasn’t a good web equivalent of making a phone call and decided, rather than coming up with a weak web counterpart to call transfer that no one will use, it’d be better to simply make this a phone-only feature.
• What is the “result” of a transfer question? For this iteration of the Plum survey application, a transfer question will return the length of the call. If there’s sufficient interest, we’ve considered returning a recording of the call transfer as the result similar to how a recording is returned for the comment question type.
• If the caller hangs up during a transfer, they might miss out on questions that occur afterwards. However it’s natural to hang up during a call transfer if it’s the last question in a survey. We decided that in the former case, data will not be saved for this respondent just like if they gave up in the middle of a web survey without finishing it. In the latter case, we’ll return the length of the call up to the point where they hung up and if, indeed, the call transfer was the last question in the survey, the survey is considered completed and the data is saved in the database.

Of course, these design choices are fairly minor matters. The ability to transfer a phone-based survey taker to any phone number based on choices they previously made opens up numerous possibilities for using the Plum survey application as both an enhanced survey tool and a general IVR tool.

First I’ll offer an example of how one coule use the transfer question type to enhance an existing survey. Let’s say you’re a call center that wants to ask your customers how satisfied they were with the rep that they reached. Frequently this determination of whether to take a survey occurs at the end of the phone call. This leaves open the possibility that the rep could game the system by only mentioning the satisfaction survey to callers with whom they’ve had a good call.

With the Plum survey application, you could ask the caller if they want to take a survey before they speak with a rep. It would look something like this:

1. Ask caller if they want to take a survey after the call. If yes, go to step 2. If no, go to step 3.
2. Transfer the call to a rep. After the rep hangs up, go to step 4.
3. Transfer the call to a rep. After the rep hangs up, end the survey.
4. Proceed with asking the caller some questions about the conversation they just had with a rep. Once the caller has answered all of the questions, end the survey.

Thus, the survey is no longer just a call destination after you’re done talking to a rep. The survey application becomes the entire call, from the first question, through the conversation with the rep, to the satisfaction questions themselves.

Second I’ll offer an example of using the Plum survey application for as an IVR autoattendant/call director. You can think of an autoattendant as a series of questions that the IVR asks a caller to figure out where to transfer their call. So even though the Plum survey application isn’t explicitly intended to be used as an autoattendant, it can now certainly be used in that manner now that a call transfer is just another question type.

Imagine the following autoattendant structure:

• Choose a language: English or Spanish
  • If English, choose sales, billing, or technical support in English
    • If sales, transfer them to the English sales line
    • If billing, transfer them to the English billing line
    • If support, transfer them to the English support line
  • If Spanish, choose sales, billing, or technical support in Spanish
    • If sales, transfer them to the Spanish sales line
    • If billing, transfer them to the Spanish billing line
    • If support, transfer them to the Spanish support line

There are six different possible phone numbers to which to direct the caller. The “survey” would end up looking something like this:

1. Ask the caller if they want English or Spanish. If they choose English, skip to step 2. If they choose Spanish, skip to step 6.
2. In English, ask if they want sales, billing, or technical support. Skip to step 3 if sales, step 4 if billing, or step 5 if support.
3. Transfer call to English sales. Once the conversation is over, end the survey.
4. Transfer call to English billing. Once the conversation is over, end the survey.
5. Transfer call to English support. Once the conversation is over, end the survey.
6. In Spanish, ask if they want sales, billing, or technical support. Skip to step 3 if sales, step 4 if billing, or step 5 if support.
7. Transfer call to Spanish, sales. Once the conversation is over, end the survey.
8. Transfer call to Spanish, billing. Once the conversation is over, end the survey.
9. Transfer call to Spanish, support. Once the conversation is over, end the survey.

Thus, by adding the transfer question type, the Plum survey application is now a fairly general tool. Yes, there are a capabilities missing that would make it potentially a completely generalized tool: stateful control-flow logic, large user-defined grammars, and direct data integration to name a few. And, no, not all of them will be built into the Plum survey application. But even as-is, most users should be able to design and build many simple non-integrated applications quickly and cost-effectively using a tool that relies on a simple survey paradigm.

We’ve got more features on the way, so stay tuned.