When you understand the requirements for the voice response service, the business goals and callers’ needs, you can begin designing your application. You may not yet know which Blueworx Voice Response facilities and other software and hardware you will use to implement it. Part of the design process will be to decide on the implementation of the high-level activities.
This process will be iterative, as you create prototypes and learn more about both requirements and ways of implementation. Always involve users, both callers and the departments commissioning the voice response service, in the design process. However, there will be work you need to do without them.
- Before the first meeting with users, identify the main activities to be performed by the application. An example is shown in Figure 1.
- Together with users, design the dialog for each activity, concentrating
on everything proceeding smoothly (as you hope it will in majority
of calls). You must take into consideration all the possible responses
by the caller, remembering that they may have either keys or speech
or both to respond with.
Table 1. Example dialog segments ID
Words
1
Thank you for calling the Blueworx Voice Response Automated Account Inquiry Service.
2
To hear your account balance, press 1.
3
To hear the current interest rate, press 2.
21
You have...
22
...in your current account.
23
...in your savings account.
31
Today’s interest rate is...
7
To leave the Blueworx Voice Response Automated Account Inquiry Service, press 7.
15
Thank you for calling. Goodbye.
16
The key you pressed is invalid. Please try again.
Table 1 shows examples of punctuation conventions that you can use in the text versions of voice segments:
An initial capital letter at the beginning of a voice segment indicates the beginning of a prompt.
Ellipsis (...) at the beginning of a voice segment indicates the continuation of a prompt.
Ellipsis (...) at the end of a voice segment indicates that further voice segments are to be appended in the prompt.
Period (.) at the end of a voice segment indicates the end of the prompt.
- You need to decide whether you are going to allow both keys and speech throughout the call, keys for some parts and speech for others, or whether you are going to restrict the caller to either keys or speech. You may decide on two versions of the service: one for callers who have pushbutton phones, and one for callers with rotary phones, who have to use speech.
- As your dialog design progresses, make sure you document each of the branches of the application. You can use the Blueworx Voice Response State Tables window to create a graphical representation of the state table, filling in the details later.
- Before the next meeting, identify all the things that could go wrong: for example, the caller could hang up in the middle of the call, the connection with a host computer could fail. Again, you can use the Blueworx Voice Response State Tables window, this time looking at the possible results for the actions and filling in the details.
- Again, with users, refine the dialog, taking into consideration all the things you have identified that could go wrong. The business departments will want to be assured that the caller is going to hear the right thing whatever happens. They do not want to lose business through a badly designed voice application. If the voice application itself cannot continue, ideally, the caller should be transferred to a human agent.