Call Flow Design

Call flow is the set of logical steps that form the user's interactions with the system, defining how the user will pass through a series of dialogues. It is the road map to task completion. Each dialogue asks the user a question, gives the user information or confirms previously gathered data. Each dialogue is a node in the interaction between application and user. Think of each dialogue as a state in the call flow.

The following section looks at an application for scheduling appointments. In this example, the user's task is to schedule a meeting with a number of attendees. The call flow steps through all the dialogs that are necessary to gather the primary information needed to schedule the meeting. At the end of that subtask, the application confirms the individual details before checking the schedule for conflicts. If there is a conflict, the application asks which of the variables the user wants to revise—the date, start time, duration or subject.

System Initiative

The following figure shows a flow diagram for the initial portion of the dialogue using a simple turn-taking structure. The user must answer a series of four questions in order to complete the first subtask for scheduling the appointment. After completing this subtask, the system has four key pieces of data—the date, start time and duration of the appointment as well as a subject or label.

In a system initiative dialogue the user may only provide the information requested by the system. Confirmation occurs at the end of the subtask as the system reads all four items back to the user in summary form. The user confirms the summary as a whole by answering the simple yes or no question "Does that sound right?"

The system handles any revisions that may be necessary by asking the user which piece of data he or she wishes to revise. The system then routes the call flow back to the appropriate dialogue for revision.

Each block or dialogue element in this example represents a step in the interaction. The system prompts the user at each dialogue, but it is the successful response from the user that moves the conversation along to the next turn in the call flow. A full set of error handling and help prompts provide support for each dialogue.

Creating a conversation with the Speech Application SDK (SASDK) involves a number of components such as the QA control, a grammar to handle what the user says and a semantic map with at least one semantic item to hold the semantic information gathered from the user in an accessible form.

In the example shown in the previous figure, the dialogue state labeled "GetDate" is composed of a QA control, a grammar and a semantic item, which acts as the container that holds the date information after a successful recognition occurs.

Mixed Initiative

In a mixed initiative dialogue the user may provide information the system has not yet asked for. For example, if the system asks for destination the user might respond with destination, plus time and date. The system requires that the answer include at least what it asked for, but it also accepts additional information. In other words, if the system asks for A the user must at least provide A, but may also provide B and C.

The creation of a call flow design that can accommodate mixed initiative responses from the user can shorten the call flow significantly. Task completion is more efficient when users embed several pieces of information in a single utterance. Of course, users are free to take the conversation step by step, but often, as they become more adept at navigating the system they will use these "express lanes" to state their commands in a more condensed form.

The level of command compression is optional and at the discretion of the user. Also known as menu flattening, this type of user command compression can be difficult to design, but the power and efficiency it provides for users is well worth the extra effort in design and development. Designers of such systems face the challenge of revealing this functionality to users without burdening them with extensive tutorial content. For this reason, systems that accommodate mixed initiative responses are often those that track users over time and can offer advanced tips based on user experience with the system.

Handling Mixed Initiative

Support for mixed initiative in the SASDK is provided by the ExtraAnswers element of the QA control, and a simple algorithm embedded in a script named RunSpeech. In essence, the algorithm ensures that the semantic item for a QA control is filled and confirmed before activating the next control on the page. Because of the simple rules that govern the order in which RunSpeech activates controls on a page, designs that allow users to specify information in the form of mixed initiative responses are not only possible but also quite easy to create.

How May I Help You

A final dialogue model is where the system simply invites the user to make a request, and tries to recognize and confirm the user's response.

See Also

Dialogue Organization | Designing Dialogue Flow