Application Design

Last month we began our four part series that examines the process of developing voice application projects. At Angel we have helped hundreds of clients successfully deploy voice solutions that generate revenue, reduce costs, and improve the customer experience. I hope you will benefit from us sharing some of our findings.
The process of developing a voice application involves four phases:

Plan - decide what you want the application to accomplish, and gather the resources needed.
Conceptualize & Design - construct a model of the application, and specify how it will accomplish the goals stated in the requirements.
Implement - perform the engineering work required for the application to conform to the design.
Refine & Test - ensure that the application is meeting the requirements, and tune the caller experience.

This month I will take a closer look at the planning phase, with the goal of showing you how easy it can be and what an impact it can have in the final product.

Discovering the Caller's Goals
If you've done your homework during the Plan phase, it should be easy to work through discovering the caller's goals. During planning you looked at what you would like the Voice Site to accomplish, or your goals. Now it's important to consider what the caller's expectations are when they dial into the application.

Are they calling to find out information? Are they looking to accomplish a specific task? Are they going to be first-time callers or will the same people call over and over again? If a task is to be completed, how complex is it?

Remember that your goals and the caller's expectations may not match. For example, your goal may be to create a store locator to provide information about the nearest outlet. However, the caller might already know the location they want and would like to find out if their local outlet is going to be open on Sunday evening.

There's no good substitute to gathering data from real callers. If your voice application is replacing an older system, or is replacing an interaction with a live agent, you may be able to classify the purpose of calls and come to conclusions about caller goals.

Another way to discover goals is to look at proxies for the voice application. For example, statistics on the usage of your corporate website may shed some light as to what visitors are looking for. If you can extrapolate to the phone, an approximation can be made.

Finally, you can always interview a sample of your potential callers. A simple questionnaire may provide you with the raw material for discovering their expectations.

The Virtual Conversation
Once the caller's goals have been clarified, a useful tactic is to find or create samples of conversations that the system would have with the caller. What kind of language will be needed to carry out this task? Steps will have names, and there will be expressions that callers will be comfortable with.

A sample virtual conversation may go like this:

System: New purchase or existing purchase?
Caller: Er, it's an existing purchase.
System: OK, I have an order here for $42 that you placed last week on Monday. The order is being filled and will be shipped tomorrow. Would you like to change your order?
Caller: No thanks.
System: No problem.

From this dialogue we can infer:

That the system will have to deal with ordering and order status.
That callers may have multiple orders.
That callers may feel more comfortable identifying their orders by the order amount.
That callers with existing orders would like to know, primarily, when is the order being shipped.

A few of these conversations may go a long way towards defining the tone and the scope of the application. Later in the process, the design will have to be formalized, but for now it's important to capture the "spirit" of the task, and identify the steps necessary to accomplish it.

With a clear concept, the task of designing the application will be less daunting. Remember, the sample dialogs dictate the structure (and not the other way round!).

The flow of the call
A call flow document describes the discrete points of a Voice Site where the system presents a choice to the caller and determines the action that the system takes due to the choice. These points are sometimes called dialog states. The call flow defines the structure of the Voice Site, by showing not so much the content of each state, but how a caller can get into a state and where they can go based on their selection (by what they say or press).

There are several ways to describe a call flow, but a typical one is via a diagram:

Call Flow

The bubbles represent the states, and the arrows the transitions between states. Labels in quotes (like "12345") represent sample utterances (what a caller can say) out of a large set, while labels without quotes represent a complete set. For example, from the "confirm" state, a caller may either say "yes" or "no", but those are the only significant choices.

Call flow diagrams are helpful to determine the order of steps and to flesh out the concept. Although not all details about the design are reflected in the diagram, the entire structure is.

The prompt list
A prompt is a voice recording, which the system will play when it reaches a specific state. For any given state, there may be one or more prompts. There will always be a main prompt. In addition, you may want to define escalating prompts for when the caller fails to make a choice, or makes a choice that the system cannot match to one of the choices you specified as a valid transition. These are called No Input and No Match prompts. Angel comes with predefined No Input and No Match prompts, but you can improve your design by tailoring these prompts to the specifics of the dialog state.

A prompt list outlines all the "lines" for the system in its dialog with the caller. A sound file or a text-to-speech sound bite will later represent each of these prompts. Thus, it is a good idea to define sound file names in your prompt list. Prompt lists are useful to communicate the details of the design with people who may need to review it, and the voice talent producing the sound files will be in a better position to help if they get a well organized prompt list.

The Voice Site Prototype
Armed with your call flow diagram and your prompt list, Angel makes it easy to turn your design into a working voice application. But before you commit to a final design, it is a good idea to test it. With Site Builder you can replicate the call flow by simply pasting the text from your prompt list into a few Voice Pages. Each bubble of the call flow will normally translate into a Voice Page.

Prototyping your application provides an important piece of feedback: a feel for whether the dialog works. Hearing your prototype and listening to how other people interact with it will give you valuable information about the design's effectiveness.

One more benefit of prototyping with Site Builder is that in most cases you will be able to use the prototype as the final target with little modification.

Dynamic Access Points
A final design step is to determine which parts of dialog are static (they don't change from call to call) and which ones are dynamic (what is played is dependent on who the caller is or what they enter). Static dialogs can be implemented with regular Voice Pages. Dynamic dialogs will require a Transaction Page, calling on a script that will implement the logic to decide what to play next.

By identifying these Dynamic Access Points, it will be easier to communicate with the person developing the scripts. For each dynamic access point I normally include a short description with the following:

Inputs: what pieces of information were collected in previous dialog states are needed to make the logic work.
Possible outcomes:
- Normal outcomes (e.g. data was found, data doesn't match, data is of type 'x', etc)
- Extraordinary outcomes (e.g. there was a problem processing the request)
Transitions depending on the outcome.

Conclusion
A thoughtful design will prove invaluable in later steps of the process of building a voice application. Three main documents will summarize the design: 1) a collection of sample conversations between callers and the system, 2) a call flow diagram outlining the structure of the application, and 3) a prompt list detailing the wording of each prompt.

Next month, we'll look at the process of implementing a design.

If you're working on an IVR project we'd love to talk to you! Give us a call at 888-692-6435 and say "Developer Hotline".

Sam Aparicio