avaya™ interactive response · 2002-11-12 · intervention hotline at +1 800 643 2353 for the...

Avaya™ Interactive Response Release 1.0 Designing voice response applications

Issue 1 Publication Date: December 2002

2 Avaya IR R1 designing voice response applications

© 2002, Avaya Inc. All Rights Reserved Notice Every effort was made to ensure that the information in this document was complete and accurate at the time of printing. However, information is subject to change.

Preventing Toll Fraud “Toll fraud” is the unauthorized use of your telecommunications system by an unauthorized party (for example, a person who is not a corporate employee, agent, subcontractor, or working on your company's behalf). Be aware that there may be a risk of toll fraud associated with your system and that, if toll fraud occurs, it can result in substantial additional charges for your telecommunications services.

Avaya Fraud Intervention If you suspect that you are being victimized by toll fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at +1 800 643 2353 for the United States and Canada. For additional support telephone numbers, see the Avaya Web site: http://www.avaya.com Select Support, then select Escalation Lists US and International. This Web site includes telephone numbers for escalation within the United States. For escalation telephone numbers outside the United States, select Global Escalation List. Providing Telecommunications Security Telecommunications security (of voice, data, and/or video communications) is the prevention of any type of intrusion to (that is, either unauthorized or malicious access to or use of) your company's telecommunications equipment by some party. Your company's “telecommunications equipment” includes both this Avaya product and any other voice/data/video equipment that could be accessed via this Avaya product (that is, “networked equipment”). An “outside party” is anyone who is not a corporate employee, agent, subcontractor, or working on your company's behalf. Whereas, a “malicious party” is anyone (including someone who may be otherwise authorized) who accesses your telecommunications equipment with either malicious or mischievous intent. Such intrusions may be either to/through synchronous (time-multiplexed and/or circuit-based) or asynchronous (character-, message-, or packet-based) equipment or interfaces for reasons of: • Utilization (of capabilities special to the accessed equipment) • Theft (such as, of intellectual property, financial assets, or toll-facility

access) • Eavesdropping (privacy invasions to humans) • Mischief (troubling, but apparently innocuous, tampering) • Harm (such as harmful tampering, data loss or alteration, regardless of

motive or intent) Be aware that there may be a risk of unauthorized intrusions associated with your system and/or its networked equipment. Also realize that, if such an intrusion should occur, it could result in a variety of losses to your company (including but not limited to, human/data privacy, intellectual property, material assets, financial resources, labor costs, and/or legal costs). Your Responsibility for Your Company's Telecommunications Security The final responsibility for securing both this system and its networked equipment rests with you - an Avaya customer's system administrator, your telecommunications peers, and your managers. Base the fulfillment of your responsibility on acquired knowledge and resources from a variety of sources including but not limited to: • Installation documents • System administration documents • Security documents • Hardware-/software-based security tools • Shared information between you and your peers • Telecommunications security experts To prevent intrusions to your telecommunications equipment, you and your peers should carefully program and configure: • your Avaya-provided telecommunications systems and their interfaces • your Avaya-provided software applications, as well as their underlying

hardware/software platforms and interfaces • any other equipment networked to your Avaya products.

Federal Communications Commission Statements Part 15: Class A Statement Note: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user will be required to correct the interference at his own expense. Part 68: Answer-Supervision Signaling. Allowing this equipment to be operated in a manner that does not provide proper answer-supervision signaling is in violation of Part 68 rules. This equipment returns answer-supervision signals to the public switched network when: • answered by the called station, • answered by the attendant, or • routed to a recorded announcement that can be administered by the CPE

user. This equipment returns answer-supervision signals on all direct inward dialed (DID) calls forwarded back to the public switched telephone network. Permissible exceptions are: • A call is unanswered. • A busy tone is received. • A reorder tone is received. Canadian Department of Communications (DOC) Interference Information This Class A digital apparatus complies with Canadian ICES-003. Cet appareil numérique de la classe A est conforme à la norme NMB-003 du Canada.

European Union Declarations of Conformity

Avaya Inc. declares that the switch equipment specified in this document bearing the “CE” (Conformité Europeénne) mark conforms to the European Union Radio and Telecommunications Terminal Equipment Directive (1999/5/EC), including the Electromagnetic Compatibility Directive (89/336/EEC) and Low Voltage Directive (73/23/EEC). This equipment has been certified to meet CTR3 Basic Rate Interface (BRI) and CTR4 Primary Rate Interface (PRI) and subsets thereof in CTR12 and CTR13, as applicable. Copies of these Declarations of Conformity (DoCs) signed by the Vice President of R&D, Avaya Inc., can be obtained by contacting your local sales representative and are available on the following Web site: http://support.avaya.com

Trademarks Avaya, CONVERSANT, and Intuity are registered trademarks of Avaya, Inc. Adobe and Adobe Acrobat are trademarks or registered trademarks of Adobe Systems, Inc. in the United States and in other countries. U.S. Robotics and Sportster are registered trademarks of 3Com Corporation or its subsidiaries. Alliance Generation is a registered trademark and NMS Communications, Natural MicroSystems, AG, Natural Access, NaturalFax are trademarks or service marks of NMS Communications Corporation or its subsidiaries. Informix, DB2 are registered trademarks of IBM Corporation. Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Nuance and Nuance Vocalizer are trademarks of of Nuance Communications, Inc. Oracle is a registered trademark, and Oracle8i, and Oracle9i are trademarks or registered trademarks of Oracle Corporation Sybase is a trademark of Sybase, Inc. Speechify, OpenSpeech Server, OpenSpeech Recognizer, and OpenVXI are registered trademarks of SpeechWorks International, Inc. Sun, Sun Microsystems, docs.sun.com, Java, Solaris, Sun Blade are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries.

Issue 1 December 2002 3

Technical Support Avaya provides a telephone number for you to use to report problems or to ask questions about your contact center. The support telephone number is 1-800-242-2121 in the United States. For additional support telephone numbers, see the Avaya Support Centre Web site. Select Escalation Lists. This Web site includes telephone numbers for escalation within the United States. For escalation telephone numbers outside the United States, select Global Escalation List. Warranty Avaya Inc. provides a limited warranty on this product. Refer to the Limited use Software License Agreement provided with your package.

Ordering Information: Avaya Publications Center Voice: +1 207 866 6701

+1 800 457 1764 (Toll-free, U.S. and Canada only) Fax: +1 207 626 7269

+1 800 457 1764 (Toll-free, U.S. and Canada only) Write: Globalware Solutions

200 Ward Hill Avenue Haverhill, MA 01835 USA Attention: Avaya Account Manager

Web: http://www.avayadocs.com E-mail: [email protected]

Acknowledgment This document was written by the CRM Information Development group.


About this document

This document is a compilation of help topics from Avaya IR System Help that has been formatted for printing. It contains the same information as the Help itself.

This document is only available as part of the Avaya IR System Help and Avaya IR Documentation CD. You cannot order this document separately from Avaya.

About cross-references in this document

The topics in Help contain hypertext links to other topics that enable you to jump to the linked topic. In this document, hypertext links appear as cross-references to the pages containing the linked topics. For example, a hypertext link in Help to a topic called "Features" would appears in this document as

"See Features on page 54 for more information"

However, not all the linked-to topics are included in the printable documents. This results is some topics that are normally linked in the Help content, appearing without page cross-references. Using the example above, if the "Features" topic is not included in this document, the text appears as

"See Features for more information"

Please be aware that this is a limitation of having subsections of Help compiled for print. If you see text that looks like a cross-reference without a page number, the information is available in Help.


Contents

About this document 5

Designing voice response applications 11

Overview of designing voice response applications 13

Application usability...................................................................................................14 Prompts .......................................................................................................................17 Announcements..........................................................................................................19 Menus...........................................................................................................................21 Digit input ....................................................................................................................23

Entering digit sequences .........................................................................................23 Validate a digit sequence entry ...............................................................................25 Confirming digit entries with callers.......................................................................26

Yes/no questions ........................................................................................................27 Touch-tone input for yes/no questions ..................................................................27 Spoken input for yes/no questions.........................................................................28 Yes/no questions with barge-in (WholeWord speech recognition) .....................28 Yes/no question without barge-in ...........................................................................28

Pace the application ...................................................................................................30 Application errors .......................................................................................................31 Touch-tone and speech recognition .........................................................................33

Recognizer differences between touch-tone input and spoken input.................33 Application examples...............................................................................................34 Touchtone input used with spoken input...............................................................35 Use touch-tone input when speech recognition fails ...........................................37 Modify a touch-tone-only application to include spoken input............................38

Dial through and barge-in ..........................................................................................39 Bilingual, multilingual, and non-US English applications.......................................41

Bilingual applications...............................................................................................41 Multilingual applications..........................................................................................42

Text-to-Speech in applications..................................................................................43 Use Text-to-Speech for prompts and announcements .........................................43 Use both Text-to-Speech and prerecorded speech prompts and announcements43 How to get the most out of Text-to-Speech ...........................................................44 How to test Text-to-Speech applications ...............................................................45

Contents


Designing applications that use speech 47

The speech filesystem................................................................................................48 Speech development tools and features ..................................................................51 Developing speech .....................................................................................................54

Determining the transaction ....................................................................................54 Planning the voice script .........................................................................................55 Writing the voice script ............................................................................................56 Selecting a speech development method ..............................................................58

Editing speech.............................................................................................................62 Recognizing WholeWord speech input.....................................................................63

How WholeWord speech recognition works ..........................................................63 Bilingual capabilities ................................................................................................64 Standard WholeWord speech recognition types ...................................................64 Keyword recognition types......................................................................................65 Connected-digit recognition types..........................................................................66 Recognition DIPs ......................................................................................................68 Word spotting............................................................................................................68 Phrase screening......................................................................................................68 Recognition confirmation ........................................................................................69 Barge-in .....................................................................................................................69 Dual Tone Multifrequency (DTMF) support ............................................................71 Custom grammars ....................................................................................................71 Custom vocabulary...................................................................................................72 Custom DIPs..............................................................................................................72 WholeWord speech recognition accuracy .............................................................72

Using NLSR in voice applications .............................................................................77 Barge-in and NLSR ...................................................................................................77 Using NLSR external functions in an IVR Designer application ..........................78

Putting it together .......................................................................................................81 Using NLSR with other features ..............................................................................81 Getting the most out of Text-to-Speech .................................................................81 Using Text-to-Speech and prerecorded speech together.....................................81 Using WholeWord and Natural Language Speech Recognition together ...........82 Comparison of recognition types............................................................................82

Enhanced Basic Speech formats ..............................................................................84 Languages available.................................................................................................84 Background information ..........................................................................................85 EBS formats ..............................................................................................................89

Designing applications that use ASAI 127

ASAI application types .............................................................................................128 ASAI versus the converse vector step....................................................................132

Contents


Avaya Interactive Response system application design ......................................133 Using ASAI in a call center.......................................................................................139 Call-flow design ........................................................................................................142 Host application planning and design ....................................................................150 Call flow examples....................................................................................................153

Designing applications that use Computer Telephony Integration (CTI) 169

ctiCallInfo...................................................................................................................170 ctiCallState ................................................................................................................172 ctiConfer ....................................................................................................................174 ctiDial .........................................................................................................................175 ctiDiscon....................................................................................................................176 ctiHold........................................................................................................................177 ctiNotify......................................................................................................................178 ctiPrivData .................................................................................................................180 ctiRetrieve..................................................................................................................182 ctiTransfer .................................................................................................................183

Designing applications that use Converse Vector Step (CVS) routing 185

Designing VoiceXML applications 187

Object element interface ..........................................................................................188 VoiceXML file locations............................................................................................192 VoiceXML audio file formats....................................................................................193 Current issues with the Avaya VoiceXML feature..................................................194

Designing applications that use Siebel eBusiness Integration 197

Introduction to Siebel eBusiness Integration.........................................................198 Identifying data to be transferred..........................................................................199 Setting up Siebel.....................................................................................................200

XML templates...........................................................................................................205 Interpreting DTDs ...................................................................................................205 Creating the template .............................................................................................207

Queries and updates ................................................................................................209 The Vonetix interface .............................................................................................209 Performing queries and updates...........................................................................210

Contents


Index 213


Designing voice response applications

Designing voice response applications provides general guidelines and detailed information about about designing voice response applications.


Overview of designing voice response applications

Overview of designing voice response applications provides general guidelines to use when you are designing voice response applications.



Application usability In order to design the most successful application possible, it is a good idea to research some basic design principles. Human factors experts call these usability principles, since they are critical to designing a usable application.

Because of experiences with poorly designed applications, some callers are wary of all voice response systems. Be careful that your application does not alienate your customers. Your goal is to make an automated transaction at least as attractive and efficient as interacting with an attendant.

Know your callers

Choices you make in the application design will affect those who the application will serve. Find out as much as you can about the people who will call the system, and use the information when designing your applications.

Relevant information to gather includes the following:

• Who are your callers?

Your callers have personal attributes that affect how they interact with the application you are designing.

― What language do they speak? If you expect that many callers will have an accent that is different from what the speech recognition package you are using expects, consider offering a bilingual service.

― How old are they? If you expect that a high percentage of callers may be children, you should use simple language and very short menus. Also, since speech recognition works best with deeper voices, for children you may want to use only touchtone input. If you expect that many of your callers are over the age of 65, you might want to allow them more time to respond. Make sure to reduce confusion by making the transaction as simple as possible.

― Are they employees of your company? You may want a script designed for in-house use to appear and perform differently than one designed for your customers. For example, if you provide training classes or user guides, you can probably use shorter and more concise prompts. Jargon and technical terms may be appropriate for employees if you can assume that they know the terms.

Note any other personal attributes that could affect how callers will interact with your application, such as regional slang, accents, or education level.

• How often do they call?

Application usability


Some applications are meant to be used only one time, while others can be used more often. Callers might access some applications several times a day.

If you expect callers to use the application rarely, your prompts and announcements may need to contain explicit information and instructions. Prompts for applications used very often can be made extremely short, since most callers will likely be experienced. If you expect your callers to be mixed in their experience levels, make it possible for the more experienced callers to dial through or barge in during prompts.

• How well do they know the subject matter?

If you expect that most of your callers will be unfamiliar with the subject matter (for example, if you are describing a new service or product), you should take special care in structuring and presenting the information so that your audience can understand it.

Use simple and natural dialog

Learning as much as you can about callers will allow you to determine what is "simple and natural" for them. Design uncomplicated, straightforward applications that use terms familiar to the callers.

Minimize demands on the caller's memory

Psychological research has shown that short-term memory can hold no more than five to nine separate pieces of information at one time. For each menu item you present to callers, two different pieces of information must be remembered: the option ("For loan rate information...") and the action required to choose the option ("press 2.") Menus should offer no more than four or five items at once, since callers cannot remember more items.

The fewer items callers have to remember, the more likely it is that they will remember them. Try to make the interaction easy for the callers. Keep menus short, and avoid wordy prompts and announcements.

Be consistent

Consistency in the structure of menu choices and in the presentation of information helps prevent callers from becoming confused. By using consistent language and requesting consistent action of callers, you simplify the interaction and reduce demands on memory.

Provide feedback

Whenever callers press touch tones or speak in response to a prompt, let them know how the response was interpreted. This clarifies the transaction for callers. For instance, if callers press zero for an attendant, the application could say "Please hold for an attendant." Although the application does not explicitly state that it heard the caller press zero, the interpretation of the key press is implicit in the announcement that follows.



Provide easy exits

To prevent callers from getting trapped in an application script, tell them how to reach an attendant, end a transaction, or return to the main menu. You can give this information at the beginning of the transaction. Provide these types of escapes within your application so that callers can always return to a place they know or can obtain help as necessary. This gives your callers more control over the interaction, and makes them feel as if they are not powerless in the face of automation.

Offer shortcuts

If you expect some callers to call often enough to become experts, provide ways to shorten their interaction with the application. For example, allow them to respond before the end of a prompt so that they can move through the interaction at a pace that is comfortable for them. You may want to consider providing separate scripts (or separate branches of a single script) for novice and expert callers.

Prevent errors

By following the above principles, you can prevent errors from happening. Well designed applications take into account the strengths and weaknesses of both the callers and the technologies.

Prompts


Prompts The prompts used in your application are one of the few forms of system interaction with callers. For this reason, It is very important that you design the application prompts to facilitate a successful interaction. Use the guidelines in Prompts to design the prompts for your voice response applications.

Prompt length

Make prompts as short as possible while remaining polite and informative. Keep the prompts brief, but not abrupt. The more quickly callers can do what they called to do, the more satisfied they will be. For example:

Instead of prompting... prompt... To listen to information on travel to California, say 1. For California travel information, say 1.

If you are calling to register for classes, press 3. To register for classes, press 3.

There are some trade-offs when considering prompt length. If you expect to have a high proportion of one-time or first-time callers, you might want to provide more information in prompts and make the prompts longer. Longer prompts are acceptable if you think your callers will need the extra information. Include only helpful information and express it in a short, direct manner.

Use longer, more informative prompts if you are asking callers to enter information in a way that may be unfamiliar. For instance, consider a caller entering a date. Most people think of months by name. For a touchtone application, callers are asked to press the one-digit or two-digit number for the month. For example, the month of December would be 12. With WholeWord speech recognition, the month of December is represented by the words "one, two" which callers may say as "twelve." Both of these examples require that callers think of the information in a way that is unusual, and so prompts should be clear enough for callers to understand. These longer prompts should include examples, such as:

"Next, enter the month listed on your bill. Say two numbers, such as `one, two' for December, or `zero, five' for May."

How to word prompts

Use the following guidelines when determining the wording of prompts:

• Present the option before the action.

In menu prompts, always list the option first, and the action second. For example:



Instead of prompting... prompt... Say 2 to receive the information by fax. To receive the information by fax, say

2.

When the option is listed first, callers need to listen only to the one action that pertains to their choice. When the action is listed first, they must remember it until they hear the option and decide if it is the one they want. Listing the option first will help both experienced and new callers.

• Use the same structure for each option-action pair in a menu prompt. This helps the caller to know what to expect. For example:

Instead of prompting... prompt... To hear sales information, press 1.

For services, press 2.

If you would like to speak to an attendant, press 0.

For sales, press 1.

For services, press 2.

For an attendant, press 0.

• Make each menu choice clearly different from other menu choices.

Be sure the menu choices are different from each other, so callers can decide which option they want. If callers are confused about which option they want, consider rewording the choices.

• Avoid jargon and acronyms.

Assume that callers do not use the same technical words you do. Avoid acronyms and abbreviations that may confuse your callers. Speak out the complete words. Use words that your typical callers will understand. Use technical terms only if your audience is a small group of people who are trained in your business.

Announcements


Announcements As with prompts, it is very important that you design the application announcements to facilitate a successful interaction with your callers. Announcements are used to inform the caller. Be selective when deciding whether or not to include announcements in your design, and if you decide to include announcements, how many.

Feedback announcements

Feedback announcements should be short and clear. If you want to include "please" and "thank you," include them only occasionally so that callers can complete the call as quickly as possible.

Avoid referring to the system as I or we. If callers think the system is a person, they may use more words to make their answers more friendly, thus making speech recognition more difficult. For example:

Instead of prompting... prompt... Please wait while I locate your records. Please wait while your records are located.

If a request will take more than two or three seconds to fill, assure callers that work is being done. For example:

"Looking for your records. Please wait." or "Please wait while your information is located."

Confirmation announcements

There are times where you should read the entry of the caller back, and allow the caller to confirm it. Other times, a feedback announcement (such as "Please wait while your information is located") is more appropriate than a confirmation announcement.

When you need confirmation

In cases where a recognition error or caller touchtone error would have a significant impact (like credit card numbers or call destinations), you should give callers an opportunity to confirm the entry. To do this, repeat the entry and prompt callers to say "yes" or "no" to confirm, as in the following examples:

• With speech recognition:

"What is your customer number?" < 432886 > "Customer Number 432886. Is this correct?"



{pause} "Please say yes or no, now."

• With touch tones:

"Please enter your customer number." < 432886 > "432886. If this is correct, press 1. If not, press 2"

• With IVR Designer, use a separate Prompt and Collect action to do the confirmation.

When you do not need confirmation

In cases where a recognition error or a caller touchtone error would not cause a big problem (that is, if it is easy for callers to return to the point in the application where they really wanted to go), you may choose not to allow callers to confirm an entry. Also skipping the confirmation of nonessential entries can speed the call.

Even if you do not confirm an entry, it is important to let callers know how the recognizer interpreted the input. To do so, include context-relevant information in the next announcement you play. For example:

"What month?" < August > "Artists performing at the Palace Theater for August include..."

Menus


Menus Use the guidelines in Menus when designing your applications that use menus.

Number of menu choices

Too many menu choices presented at once may confuse callers. In general, do not offer more than four or five choices in a single menu.

If you have more than four or five choices, separate them into small related groups and present more than one menu. For example, if you are giving information on seven parks, do not list them all in one menu. Your first menu could separate them into groups, and say:

"For parks with camping facilities, press 1 For other parks, press 2"

If the caller presses 1: "For Stony Ridge, press 1 For Cantwell Cliffs, press 2 For Old Man's Cave, press 3"

If the caller presses 2: "For Seneca Rocks, press 1 For Rialto Beach, press 2 For Lugano Falls, press 3 For Monroe Bluff, press 4"

In certain cases, it might be acceptable to present more than five menu choices. If all callers are trained in using your voice response system, or if they use the system frequently, having longer menus may save time, as long as you allow callers to dial through or barge-in to interrupt the menu prompt.

Menu choice sequence

To decrease the call length, present the most likely menu choice first, the second most likely second, and so on. If you do not know the preferred order, make a guess and adjust if necessary during application testing.

Numbered menu options

When presenting menu options that a caller can choose by number, present them in numerical order. Avoid skipping numbers.



If you change the sequence of your menu to present the more likely choices sooner, be sure to change the numbers of the menu prompts so that the caller can choose the first option by selecting 1, the second by selecting 2, and so on.

Keep in mind that experienced callers, and those with user guides, probably do not listen to all menu prompts. When you change one or more menus in your application, consider adding an announcement during the greeting, such as "The menu has changed; please listen carefully." After some time, you can remove this message.

Subdivided menu options

If your menu tree is complex, or you think that callers will want to get information from many different menus, give callers a choice to move to a different menu. You could add a choice to allow callers to go back to the previous menu, or a choice that would allow callers to go to the top of the menu tree. For example:

"For parks with camping facilities, press 1 For other parks, press 2" < 1 >

"For Stony Ridge, press 1 For Cantwell Cliffs, press 2 For Old Man's Cave, press 3 For the previous menu, press 4" < 2 >

"Cantwell Cliffs offers 15 tent camping sites, each with a water spigot. Cooking fires are permitted. Toilet and shower facilities are available. Reservations are accepted from April first through November first."

"To make a reservation, press 1 For directions, press 2 For the previous menu, press 3 To start at the beginning, press 4"

Although the menu should automatically repeat if the caller does not respond, you could include an option like "To repeat the menu, press 9."

Digit input


Digit input Use the guidelines in Digit input as you design your applications that use digit input.

Constant-length digit sequences

A constant-length digit sequence is a series that always contains the same number of digits, for example a United States social security number has nine digits.

The system recognizes constant-length sequences more accurately than variable-length sequences. Whenever possible, specify the maximum length of the variable-digit sequence to be recognized, to increase recognition accuracy.

Variable-length digit sequences

A variable-length digit sequence can contain different numbers of digits, for example a house number in a street address.

If your application must accept a variable-length digit sequence, you can increase recognition accuracy by using a two-step entry process. First ask for the number of digits, then ask for the digits. The recognizer will know how many digits to expect from the caller. For example:

"How many digits are in your house number?" < 3 > "Please say the three-digit number now."

If the digit sequence can have more than nine digits, remind the caller to say the number in digit format ("one, two") rather than as a natural number ("twelve").

Different types of credit cards may have different length numbers. If you allow callers to use one of several types of credit cards, use a menu to prompt them for the type of card, then for the numbers. This lets you know how many numbers to expect from the caller, so the recognizer will look for a constant-length number. For example:

"What type of credit card will you be using today? American Express, Discover, MasterCard, Visa, or Universal Card?" < Visa > "What are the first four digits on your Visa card?"

Entering digit sequences

For entry of sequences of 10 or fewer digits, the system provides constant-length grammars. A grammar is the set of rules that the recognizer uses to understand data, such as caller input. For entry of sequences greater than 10 digits, it is recommended that you use a



custom grammar. Otherwise, consider grouping the input. That is, prompt callers to read the series of digits in segments (groups), then confirm each group before going to the next. This technique is especially useful if the digit sequence cannot be validated with a checksum or custom grammar. If the number already has natural groups like in a telephone number, use those groups. For example:

"Please say the first four digits of your 12-digit number." < 4384 > "4384. Is that correct?" {pause} "Please say yes or no." < yes > "What are the next four digits?" < 9556 > "9556. Is that correct?" < yes > "And the next four digits?" < 8833 > "883. Is that correct?" < no > "Please repeat the four digits." < 8833 > "8833. Is that correct?" < yes >

This call is shorter if callers are allowed to barge-in during the prompt to answer the yes/no questions quickly.

Connected-digit versus tone-paced digit entry

WholeWord speech recognition supports the entry of connected-digit sequences, in all available languages. That is, callers can say a series of digits in one long breath, without intentional pauses in between. Many callers find this the most natural way to enter a series of digits.

You may have had experience with voice response systems that do not support connected-digit entry. In order to simulate connected digit input, other systems use pacer tones. When an application uses pacer tones, callers are prompted to speak the first digit, then wait for another tone before speaking the next digit. The tones then continue until all digits have been spoken.

If you prefer tone-paced method of digit entry, you can write your applications to use pacer tones. However, this type of data entry has not been proven to increase recognition accuracy rate for digit sequence. Pacer tones may even result in lower accuracy, since callers may become confused by the entry method. Avaya recommends using the connected-digit entry method.

Digit input


Use examples within a digit entry prompt

You may need to prompt callers to enter information that is not usually expressed in digit format. For example, dates are usually spoken "June eighteenth" or "six eighteen." However, WholeWord speech recognition recognizes only single digits. June eighteenth must be spoken "six, one, eight" or "zero, six, one, eight." This format is awkward for many callers. In order to make this easier, include an example in the prompt. For example:

"Next, enter the month and day of the month you were born. Use two digits for the month, and two digits for the day. For example, for June eighteenth, you would say `oh six, one eight.' Please enter the month and day now."

Use an example whenever you think that inexperienced callers will be less confused if you give them some help.

Validate a digit sequence entry

When you know that a certain group of digit sequences are valid, use whatever techniques you can to validate caller input. This is especially important with spoken input, but can also be done for touchtone input. These validation methods help you increase the recognition accuracy for connected-digit sequences. The following sections describe three ways to validate an entry.

Custom grammars

You can limit the results of the recognizer to valid sequences by using a custom grammar obtained from Avaya. A grammar is the set of rules the recognizer uses to understand data, such as caller input.

A number of grammars are already provided with IVR Designer (a list can be seen in the Input ASR Mode field on the Prompt & Collect Response tab). Custom grammars are special additions to this standard set, designed for your specific needs. For example, if you know that all valid callers will have telephone numbers from only a few telephone area codes, request a custom grammar that allows only the area codes you want. This helps the recognizer make accurate judgments about caller speech.

Checksums

Another way to validate an entry is to use a checksum. Some numbers (like credit card numbers) have a checksum built into the structure of the number, so that the number can be checked with a formula to determine if it is valid.

If the digit series you are accepting has a built-in checksum, use a data interface process (DIP), IVR Designer Set and Test node, or external function to evaluate the checksum. Once the system determines that the entry is valid, it can speak the entry back for confirmation, if necessary.



Database lookups

You can also validate an entry by looking for it in a database of valid numbers. For example, when accepting a telephone number, locate the number in the database of all customer telephone numbers. If the number is found, speak it back to the caller for confirmation, if necessary. If it is not found, the system can search the database for a telephone number that matches the second-best recognition result. If the second choice is found, the system assumes that this is what the caller entered, and can speak it back for confirmation.

Confirming digit entries with callers

It is important to confirm digit entries with callers.

Confirming single digit entries

In order for the system to speak back digits for confirmation, you must ensure that there is a recorded phrase associated with each digit. IVR Designer will supply the phrase tags for these digits, and allow you to record them. You can also use enhanced basic speech, in the language of your choice, to speak back digits.

Confirming digit sequences

With non-US English languages, the only reliable way to speak caller numeric entries back to them is as a series of digits, rather than a natural number. For example, a caller that speaks "one-hundred, twenty-three" will hear their input read back as "one two three." This should be adequate for most applications.

Yes/no questions


Yes/no questions Use the guidelines in Yes/no questions as you design your applications that include questions that require a "yes" or "no" response, also known as yes/no questions.

Touch-tone input for yes/no questions

In situations where you want callers to respond with touchtone input for "yes" or "no," ask them to press 1 for yes or 2 for no. For example:

"If this is correct, press `1.' If not, press `2.'"

It is best to instruct callers to press 1 and 2, although you may want to use 1 and 0. Even if you prompt callers to press only 1 and 2, you can set up your application to accept additional numbers. For example, 1 for yes and 2 and 0 for no. Whatever numbers you use to represent yes and no, use the same numbers throughout the application. Do not confuse callers by using 2 for no in one place and 0 for no in another.

Spoken input for yes/no questions

In situations where you want callers to respond with spoken input, instruct them to say "yes" or "no," rather than a number. Callers find this natural, and make fewer mistakes than if you ask them to say a number meaning yes or no. For example:

Instead of prompting... prompt... If this is correct, say 1, if it is not correct, say 2 Is this correct? Please say yes or no, now.

Write your yes/no questions similarly throughout the application, so that callers will know what to expect.

After asking a yes/no question, pause to give the caller time to respond, then present the possible answers. The prompt will stop playing as soon as the recognizer detects a spoken "yes" or "no" or a touchtone signal. For example:

"You said `64587.' Is this correct?" {a 1.5 second pause} "Please say `yes' or `no'."

Touch-tone input for yes/no questions

In situations where you want callers to respond with touchtone input for "yes" or "no," ask them to press 1 for yes or 2 for no. For example:

"If this is correct, press `1'. If not, press `2'."



It is best to instruct callers to press 1 and 2, although you may want to use 1 and 0. Even if you prompt callers to press only 1 and 2, you can set up your application to accept additional numbers. For example, 1 for yes and 2 and 0 for no. Whatever numbers you use to represent yes and no, use the same numbers throughout the application. Do not confuse callers by using 2 for no in one place and 0 for no in another.

Spoken input for yes/no questions

In situations where you want callers to respond with spoken input, instruct them to say "yes" or "no," rather than a number. Callers find this natural, and make fewer mistakes than if you ask them to say a number meaning yes or no. For example:

Instead of prompting... prompt... "If this is correct, say 1. If it is not correct, say 2."

"Is this correct? Please say yes or no, now.

Write your yes/no questions similarly throughout the application, so that callers will know what to expect.

Recognizing "yes" and "no" is best done with WholeWord speech recognition.

Yes/no questions with barge-in (WholeWord speech recognition)

After asking a yes/no question, pause to give the caller time to respond, then present the possible answers. The prompt will stop playing as soon as the recognizer detects a spoken "yes" or "no" or a touchtone signal. For example:

"You said `64587'. Is this correct?" {a 1.5 second pause} "Please say `yes' or `no'."

Yes/no question without barge-in

If barge-in is not allowed, you have two options:

• Ask the question, but do not list the options. For example:

"You said `645987'. Is this correct?"

This method is very successful for experienced callers. If callers are confused, try the second method.

Yes/no questions


• List the options, but do not leave an extended pause between the question and the options. For example:

"Would you like to place another order? Please say `yes' or `no'."



Pace the application Use the following guidelines to design the pace and speed of your applications.

When callers must wait

If you know callers will have to wait, it is a good idea to let them know. For example, the application could say:

"Please wait while your request is processed."

If you know that the caller may have to wait for longer than a few seconds for the application to continue (because of a database call or host connection, for example), it is a good idea to fill the gap during the wait. You could record a long phrase, perhaps music, and play it to the caller while the information is being located. Or, play a different phrase every seven to ten seconds to let callers know that work is being done. To do this, you must use an external function.

Allow time for caller responses

Pace the interaction so that callers have time to enter the required information and listen to the prompts and announcements. You can determine how comfortable callers are with the pace of the interaction by testing the application.

Do not let the application respond to caller actions too quickly. After callers are asked to make an entry, play a speech phrase consisting of about a half second of silence before the next prompt or error message. Since many telephones have the keypad built into the receiver, this pause leaves time for callers to lift the receiver back to their ears after pressing the keys. If your calling population includes senior citizens, this pause can give them more time to react.

Adjustable pacing

Write your application to allow pauses to be adjusted easily. You can include a pause as mentioned earlier, but you can also change the length of the pause during your application testing. In the beginning of your application, define a field called entry_pause. Assign to entry_pause the speech phrase number associated with one of the silence phrases.

Then, throughout the application, speak the field entry_pause before the prompts that follow caller entries. If you find during testing that the application responds too quickly, all you need to do is go to where you set the field value and use a longer silence phrase. With this method, you can make many changes in the application by changing only one line. You can do the same thing for other pauses in your application, such as pauses between menu items.

Application errors


Application errors Use the guidelines in Application errors when designing your applications to process errors.

When caller errors occur

Caller errors occur when callers enter information that the application considers incorrect, or when callers enter nothing at all. When callers make errors, provide them with an informative error message. Tell them what went wrong and how to correct it. To assure that callers hear error messages, do not allow barge-in or dial through during at least the first part of error messages.

Allow callers no more than two or three tries to enter information. After the first error (and second, if allowing three), the application should speak out a prompt that contains more information, so that callers can get a better idea of what is required. After the last try, tell callers to hold for an attendant, then transfer the call.

When speech recognition errors occur

Speech recognition errors occur when the recognizer cannot match the caller's speech to a phrase it is prepared to recognize.

Use the following guidelines for processing speech recognition errors:

• Choose one concise phrase and use it consistently within a single application. For example:

Instead of phrases such as... Use phrases such as... We are sorry, but your speech cannot be understood. Please repeat the category you want.

Sorry. Please repeat.

• When using a word list of five or fewer items, reprompt with a "sorry" phrase, then give a list of the valid options. For example:

"Sorry. Please say checking, savings, interest rates, loan rates, or operator, now."

• When using a large word list, include some helpful information in the reprompt. For example:

"Department, please." < Excuse me? > "Sorry. Please say the name of the department you want, or hold to speak with an attendant."



Effective wording of error messages

To speak out an informative error message using IVR Designer, use the Initial Prompt field on the Response tab within a Prompt and Collect node. Set this field to False for Try Again and True for Reprompt. Be sure to specify the informative error message in the associated Voice Response field. Specify an appropriate error message for each type of error that can occur (Initial Timeout, Too Few Digits, or Not on List), as shown in the following examples for touchtone input:

• If the first prompt is:

"What time would you like your wake-up call?" and the caller does nothing (Initial Timeout error)

A more informative prompt could be:

"Please enter the time you would like your wake-up call. Use the telephone keypad to enter two digits for the hour and two digits for the minutes."

• If the first prompt is:

"Enter the date of the lottery." and the caller presses some touch tones, but not enough (Too Few Digits error)

A more informative prompt could be:

"Please enter the date of the lottery for which you want to hear winning numbers. Use the telephone keypad to enter two digits for the month, and two digits for the day. If a month or day has only one digit, use a zero before the digit."

Avoid using negative or accusing words when indicating an error. Words such as "invalid," "bad," "wrong," or "incorrect" can make callers feel threatened. "Sorry" is a brief way to say that the input was not recognized or was incorrect, and "Please repeat" or "Please enter again" are brief ways to ask callers to act again.

Touch-tone and speech recognition


Touch-tone and speech recognition Although you might already know how to design good touchtone applications, the information in this section will help you understand and appreciate the differences between touchtone recognition and speech recognition, and how the technologies affect application design.

Touchtone input and spoken input are processed in fundamentally different ways, so the application designer must take care to use each feature in a way that is tailored to how callers will interact with the application.

The following table compares and contrasts touchtone interactions with speech recognition interactions.

Possible input What the system can recognize

How the system processes the input

Conclusion

One or more tones Touchtone signals Takes touchtone signals and maps to a number on the keypad

Excellent mapping between input and what the recognizer "knows"

Any noise that a person can make, or any background noise that can be heard over the telephone

A set of word models restricted by grammar

Takes a speech sample and tries to match it to the active word models

Imperfect mapping between input and what the recognizer "knows"

Recognizer differences between touch-tone input and spoken input

The way in which the Avaya IR system processes touchtone input and spoken input is fundamentally different, so the application designer must take care to use each feature in a way that is tailored to how callers will interact with the application.

The following table compares and contrasts touchtone interactions with speech recognition interactions.

Possible Input What the System Can Recognize

How the System Analyzes the Input

Conclusion

One or more tones Touchtone signals Takes touchtone signals and maps to a number on the keypad

Excellent mapping between input and what the recognizer "knows"



Possible Input What the System Can Recognize

How the System Analyzes the Input

Conclusion

Any noise that a person can make, or any background noise that can be heard over the telephone

A set of word models restricted by grammar

Takes a speech sample and tries to match it to the active word models

Imperfect mapping between input and what the recognizer "knows"

Application examples

Suppose that you are working on an application that callers use to report problems with telephone service. Part of your transaction involves asking callers for a telephone number. For a touchtone interaction, you could prompt "Enter your 10-digit telephone number." The caller can do one of three things: press 10 keys, press fewer than 10 keys, or do nothing.

• If the caller presses 10 keys, the application reads back the telephone number for confirmation: "Did you enter 614-860-4001?"

• If the caller presses fewer than 10 keys, the application detects this and reprompts the caller for a valid entry.

• If the caller does nothing, the application receives no touchtones. When this happens, the application can reprompt, providing more information.

For a similar speech recognition interaction, you could prompt, "Say your 10-digit telephone number." The caller can say anything at all in response (words or other sounds) or say nothing. The recognizer listens, then attempts to map the sounds to the appropriate grammar (US_DIG, with minimum and maximum digits set to 10), and come up with a series of digits. No matter what the caller says, the recognizer does the same thing: it listens to the sounds coming through the telephone, and attempts to map 10 digits, or using phrase screening, rejects the utterance.

• If the caller says 10 digits, the recognizer tries to map the speech to 10 digits, then reads back the result for confirmation: "Did you say 614-860-4001?"

• If the caller says fewer than 10 digits, the recognizer attempts to map the speech to 10 digits, then reads back the result for confirmation: "Did you say 618-604-0001?"

• If the caller remains silent and there is background or line noise, the recognizer rejects the utterance. The recognizer returns a null string to the application, and the application can reprompt, giving the caller more information. This is considered a "correct rejection."

• If the caller says "I do not have a phone number yet," the recognizer rejects the utterance.

What can be done to improve the application design in this example? What could increase the chance that callers will say what the recognizer is prepared to accept? Your application



could first ask if the caller has the required information, by prompting: "Do you have your telephone number available?" Callers who say no can be transferred to the attendant, while callers who say yes can be prompted for the number.

Touchtone input used with spoken input

You can use WholeWord speech recognition to allow callers without touchtone telephones to use the voice response system by speaking "yes" or "no."

There are three different approaches for planning the application:

• Write two separate applications that are nearly identical, one to process touchtone input and one to process spoken input.

• Write a single application to process both touchtone and spoken input.

• Modify a touchtone input application to process both types of input.

Separate touchtone and speech recognition applications

This approach allows you to use prompts that are best for touchtone entry in one application and those that are best for speech recognition entry in the other.

In many cases, touchtone recognition may be more accurate and cost less than speech recognition. Therefore, you probably want callers with touchtone telephones to use their keypads to interact with the application. To encourage this, start your application with a dial 1 prompt. A dial 1 prompt gives callers a chance to indicate that they have a touchtone telephone, and helps speed the call.

The following illustration shows a flowchart for a dail 1 prompt.



A single touchtone and speech recognition application

An application that uses touchtone recognition and speech recognition together requires that every prompt be acceptable for both entry methods.

Note: Use this method only if your system resources can process the extra load, since many callers with touchtone telephones may choose to use speech recognition instead. Remember that recognition accuracy is lower for spoken input than for touchtone input.

When using a single application:



1. Structure your prompts so they give callers the choice of using the touchtone keypad or speaking.

2. At the beginning of the application, tell callers that entries may be made with either the keypad or by speaking. For example, the application might say:

"Welcome to XYZ Technologies. During this call, you can use your telephone touchtone keys to make entries, or you can simply speak your responses."

3. Make sure that the prompts are appropriate for either kind of input. There are two ways to do this:

― Tell callers to "enter" the information. For example:

"Enter the zip code of the restaurant you visited."

― Present the prompt as a question. For example:

"What is the zip code of the restaurant you visited?"

Either method is appropriate. To accomplish this in IVR Designer, write the application the same as you would for speech recognition input. For digits, the application automatically accepts touchtone input in place of the spoken input. For "yes" and "no," you must identify in the application what touchtone keys are associated with the words "yes" and "no," and specify the action associated for each. For IVR Designer applications, insert the appropriate branches on the Prompt and Collect node.

You also must tell callers to press a touchtone key instead of saying "yes" and "no," in case they want to indicate their response with a touchtone key. The prompts to accomplish this could be:

Prompt: "Would you like to leave us a message regarding the service agreement?" {pause} "Please enter yes or no."

Reprompt: "Please say `yes' or `no'. Or, for yes, press 1. For no, press 2."

Use touch-tone input when speech recognition fails

If you are using speech recognition, you may increase the number of successful interactions by encouraging callers to use touchtone input when spoken entries have been recognized incorrectly.

Touchtone input may be more accurate than spoken input. You can reprompt callers to indicate their response with touchtone input if they have a touchtone telephone. The implementation is not difficult, since an application written to accept spoken input will also accept touchtone input.

A typical prompt set might look like this:



"Please enter the 6-digit code for the fax information you want." < "135683" > "You entered 135688. Is this correct?" < "No" > "Please reenter the code. If you have a touchtone telephone, you may want to enter the code using your keypad, instead."

Modify a touch-tone-only application to include spoken input

When you modify a touchtone input application to support spoken input (in addition to or in place of touchtone input), remember to examine the application to see what the prompts say and what action is expected from callers. Think about the capabilities of the speech recognition software you will be using, and where they might fit into the application.

The following table shows the words the wordlist might contain for a homework assignment application:

Word Maps to option listen to homework Listen to homework option

homework Listen to homework option

listen Listen to homework option

leave a message for the teacher

Leave a message for the teacher option

leave a message Leave a message for the teacher option

teacher Leave a message for the teacher option

choose a different class Choose a different class option

different class Choose a different class option

different Choose a different class option

class Choose a different class option

If you plan to use WholeWord speech recognition, your application will be able to recognize the words "yes" and "no" and connected digits. In places where the touchtone application prompts for digit entry (especially long sequences), you may want to introduce custom grammars, checksums, or grouping to get the highest recognition accuracy possible.

Dial through and barge-in


Dial through and barge-in Use the following guidelines to design your applications to encourage or discourage dial through and barge-in.

Using dial through and barge-in with error messages

For error messages, require callers to listen to at least part of each error message, so the interaction stops and the mistake can be corrected. For touchtone and WholeWord speech recognition input, turn off dial through or barge-in during the first part of each error message. For example:

Turn dial through or barge-in off and prompt: "Sorry. Please enter..." Turn dial through or barge-in on. "...your customer number."

Using dial through and barge-in consistently

Callers expect and appreciate consistency. Therefore, it is a good idea to apply dial through and barge-in consistently in your applications. Allowing callers to barge-in during some prompts and not others in the same application could cause confusion. You may find, however, that your callers may want to barge-in during some prompts, and may be able to accept some inconsistency. During your design testing, determine what will work best for your calling population, and design your applications accordingly.

How to word prompts for dial through and barge-in

The wording, length, and structure of prompts can discourage callers from responding during a prompt. You want to ensure that the caller's responses are consistent with how you have implemented dial through and barge-in.

How to encourage dial through and barge-in

Experienced callers like to shorten the call by responding during the prompt, and thus save time because they know what to say or do. Therefore, if you have the dial through or barge-in capability enabled for a prompt, you should encourage callers to respond when they are ready, even during the prompt. To encourage dial through or barge-in for a menu, leave a pause after each option. Using the Prompt & Collect action, play an option, then play a series of silence phrases equal to 1.5 seconds. Silence is not needed after the final option. For example:

"For sales, say `1' {1.5 second pause} For service, say `2' {1.5 second pause} For an attendant, say `zero'."



Barge-in uses system resources also used by speech recognition. If resources are limited, you could disable barge-in until you have expanded your speech recognition resources.

How to discourage dial through and barge-in

If you have the dial through or barge-in capability disabled for a prompt, you want callers to respond only after the prompt is finished to optimize the recognition. To discourage dial through or barge-in for a menu, do not leave a long pause between options. For example:

"For sales, say `1' For service, say `2' For an attendant, say `zero'."

When barge-in is turned off or unavailable, make sure that your recorded prompts have no silence at the end. Callers may respond during the silence. When this happens, the recognizer will not hear part of the caller's response.

Bilingual, multilingual, and non-US English applications


Bilingual, multilingual, and non-US English applications

Your Avaya IR system can support up to two different WholeWord speech recognition software packages in several available languages. Use the guidelines in Bilingual, multilingual, and non-US English applications to effectively use speech recognition for languages other than US English.

Bilingual applications

The Avaya IR system allows you to provide callers with bilingual service. The system plays prompts and announcements, and recognize speech, in several languages. In some cases you can provide this type of service with a single application. In other cases, you will need to use a separate application for each language.

Selecting a language

All bilingual services, whether simple or complex, should ask callers for their preferred language at the beginning of the application. The system then selects the application (or part of the application) that speaks and recognizes speech in the language the caller chooses.

Use a language gate

The part of the application that asks the caller to pick one of two languages is called a language gate. Since the system can recognize only a single language for each Prompt & Collect statement, the language gate must be written carefully. The speech recognition language gate illustrated below includes two questions, one in each language. Each question asks the caller to say a vocabulary word in one of the languages. The application then branches to a different application, depending on the caller's response.

You can also have a language gate for a touchtone-only application. First, greet the callers in each language. Then say, for example, "For English, press one. Para Español, marque dos." The code, then executes a different application, based on caller input.

Dates, times, and monetary amounts

If your application does not need to speak dates, times, monetary amounts, or numbers to the caller, you can use a single application to handle the interactions in both languages. Write the application in two different parts, with each part prompting and recognizing speech in a single language. When the caller chooses a preferred language in the beginning of the application, branch to the correct section.



If your application must speak dates, times, monetary amounts, or numbers to the caller, each language must be processed in a separate application. A single application can have only one set of enhanced basic speech phrases, the phrases that are used to speak numbers. Therefore, each application can speak only numbers in a single language.

Enhanced basic speech allows the system to play commonly used words to callers from professional recordings made by Avaya. The best way to speak a numeric entry back to a caller is to use enhanced basic speech for the local language. You can install as many of these languages as you have space for on your system disks. One language will be available for each application, but your system can support several different applications.

Multilingual applications

If you have at least two Avaya IR systems, each with one or two WholeWord speech recognition software packages, you can process callers in up to four languages with what appears to callers as a single application. You could start with the above language gate. Instead of transferring to the attendant if the caller does not say "yes" or "sí" at one of the expected times, you could transfer the call to an application on another system. The second system could include a language gate in the other two languages, then branch to the correct application (or to the attendant) depending on the caller's response.

Text-to-Speech in applications


Text-to-Speech in applications Text-to-Speech in Applications provides guidelines for designing applications that use Text-to-Speech.

Text-to-Speech converts ASCII text to spoken words. This ability is especially useful when it is not practical to prerecord the information to be read, for example if the information is lengthy, changes often, or comes from a database. Text-to-Speech is also useful for testing applications.

Use Text-to-Speech for prompts and announcements

Touch-tone input

When Text-to-Speech is used with touchtone input, callers can interrupt, or dial through, the prompt or announcement, just as they can when the prompt has been prerecorded.

If callers have problems dialing through a prompt or announcement with touchtone input, make sure that dial through is enabled. When using dial through, remember to flush all touchtone input from the buffer whenever the application plays an error message.

Spoken input

When Text-to-Speech is used with speech recognition, callers can barge-in during the prompt or announcement. If you have long announcements, you can prompt callers to press a touchtone key or speak when they have heard all of an announcement that they want to hear.

Use both Text-to-Speech and prerecorded speech prompts and announcements

A single application can speak prompts and announcements in either prerecorded speech or Text-to-Speech, or a combination of the two. New callers find Text-to-Speech more difficult to understand than prerecorded speech. Therefore, some application designers choose to speak out unchanging information (including most prompts) with prerecorded speech, unless the number of phrases makes pre-recording unmanageable. The best way to decide between these two alternatives is to test both with some of your callers.

The following example shows how you might use both Text-to-Speech prompts and pre-recorded prompts in an application. With a wordlist including 350 names, instead of prerecording all of the names, you could use Text-to-Speech to speak the recognized name for verification. Then use prerecorded speech for the rest of the prompts. For example:



"Name, please." (prerecorded speech) < John Smith > "John Smith" (Text-to-Speech) "Yes or no?" (prerecorded speech)

How to get the most out of Text-to-Speech

Use the following guidelines to improve Text-to-Speech performance in your applications.

Help callers adjust to Text-to-Speech output

Your callers may need to adjust to the computer voice of Text-to-Speech output to understand it well. To help them, you could speak out some less important information before speaking out the information callers need. This gives callers a chance to become familiar with the rhythm and intonation of Text-to-Speech.

Because the sound of Text-to-Speech may be unfamiliar to your callers, consider giving them the option of having the information repeated, or spelled, if necessary. Spelling is especially useful with names, as Text-to-Speech may not pronounce names as the caller would.

Use complete sentences

Text-to-Speech works primarily as a reading machine. It operates under the assumption that the information it is reading is structured in standard sentences (using punctuation, capitalization, subject, object, and verb). In order to make Text-to-Speech output sound most natural, use good grammar, complete sentences, and punctuation in the input text to be spoken.

What if the information you want to speak is not written in complete sentences? Since data fields cannot be punctuated, you may be able to control the output by changing the speaking rate and pauses between the information.

Pauses

You can control the pace of the Text-to-Speech output by inserting pauses. If you are speaking text that you control, the easiest way to do this is with punctuation within the words to be read. Remember to punctuate exactly like you would in a sentence (for example, do not leave a space before a period or a comma).

When speaking out a large block of text, you may hear a pause where you do not want a pause. First, check if there is any stray punctuation causing the pause. If not, you can insert a short recorded silence phrase before the sentence during which you heard the pause. This should eliminate the misplaced pause. If the text block is from a remote database, however, this may not be possible.

Text-to-Speech in applications


Eliminate typographical errors

Text-to-Speech pronounces exactly what is written, so typographical errors can cause mispronunciations. To make Text-to-Speech output as understandable as possible, look for and listen for typographical errors in the ASCII text, and remove them when you test the application.

Remember Text-to-Speech pronunciation differences

Text-to-Speech relies on built-in rules, but cannot account for all exceptions. Therefore, it may mispronounce words, especially some names. If Text-to-Speech mispronounces a word, use phonetic spelling to correct the pronunciation. For example, Text-to-Speech pronounces the name "Bagge" as "baggy," but the correct pronunciation is with a silent e. You can change the spelling of the name to "bag" so that Text-to-Speech pronounces it correctly.

Another way to overcome mispronunciation or misunderstandings is to spell some of the information, especially for names. Design the application to speak the name, then spell it out. Or, you can give callers the option of having a name spelled out.

How to test Text-to-Speech applications

Writing applications with understandable Text-to-Speech output is a process of trial and error. It is very important to plan the application, then test it with real data to ensure that the speech is understandable. Once you can understand the output well, test the application with some representative callers. Refine and test it again until you and the callers are satisfied with the result.


Designing applications that use speech

This section provides:

• Information about the speech filesystem

• Information about speech terminology

• An overview of the Avaya IR features available for speech development



The speech filesystem All speech to be played as part of an application resides in a mounted filesystem. By default, speech filesystems reside in /voice1, which is linked to /home2. These two filesystems can be used interchangeably. With the Avaya IR system, you can define where in /voice1 or /home2 speech files are stored.

Speech encoding and storage

Each speech phrase requires a minimum of 8 KB of space.

Default speech directory

The default speech directory is designated as /voice1/vfs/talkfiles. It is organized into 8-KB blocks, which allows for quick and efficient retrieval of speech files.

Specifying a speech directory

Use the following procedure to change the directory in which speech files are stored from the default (/voice1/vfs/talkfiles):

1. Stop the voice system.

2. Access the /vs/data/irAPI.rc file.

3. Add the following entry, where directory is the full path of the new directory where you want to store speech files:

SPEECHDIR= directory

The SPEECHDIR variable specifies the new directory.

4. Restart the voice system.

The speech administration tools (for example, list, add, copy, erase, and vdf) are available for use only with speech files stored in the speech directory defined by the SPEECHDIR variable in the irAPI.rc file.

Saving and restoring speech files

Speech files are backed up when a system backup is performed.

Adding a second speech disk

If you require speech-intensive applications, or if your system has 72 or more channels (telephone network connections), it is recommended that you add a second disk specifically for storing speech.

The speech filesystem


Defining phrases

A phrase is a unit of speech, such as a letter, number, word, sentence, or paragraph, that a speech application script speaks to a caller. Examples of phrases include a welcome message, a bank balance, or the name of a month. Every phrase in a speech application script is identified by a phrase tag or phrase number. The application speaks a phrase to callers by referencing either the phrase tag or the phrase number in the application. See "Defining phrase tags" and "Defining phrase numbers" for more information.

Defining phrase tags

A phrase tag is a string of up to 50 characters that identifies the contents of a phrase used by an application script. In other words, a phrase tag identifies a specific phrase. When you define a message to be played during a transaction, you specify a given phrase by its phrase tag (as opposed to its content).

The two types of phrase tags are as follows:

• Enhanced Basic Speech (EBS):

― Currency (such as dollars and cents)

― Time – hours, minutes, and seconds on the 12-hour (a.m./p.m.) or 24-hour clock

― Days of the week

― Months

― Numbers

― Characters

The EBS package includes prerecorded speech formats corresponding to the above types of phrases for all supported languages. For a list of these formats, see EBS format tables on page 89.

IVR Designer uses predefined EBS phrase tags for spoken output, such as digits and letters in various inflections. For more information about IVR Designer, see the EBS-related topics in the IVR Designer online help.

Note: Predefined EBS phrase tags begin with a colon (:). Therefore, do not use a colon as the first character in any custom phrase tag.

• Custom speech

Custom phrase tags are designed specifically for the application you are developing and are usually more than one word in length. Examples:

― "Your account balance is"



― "Please enter your account number"

― "The current interest rate is"

Defining phrase numbers

A phrase number is a number that identifies the contents of a phrase used by an application script. A script speaks a phrase to callers by referencing either the phrase tag or the phrase number. A phrase number is assigned to a phrase when you add the phrase to an application (for example, when you add a phrase through a Prompt and Collect node in a IVR Designer application).

Defining talkfiles

A talkfile is a list of phrases usually associated with an application script. Talkfiles are stored under the directory /speech/talk. All of these files have a .pl extension. The first line in the file shows the talkfile number. The rest of the file displays the phrases (as they were entered in the application) preceded by their phrase numbers. The actual phrases are located in the speech filesystem.

Each talkfile can contain as many as 65,535 phrases. The talkfile number and phrase tag or phrase number together uniquely identify a phrase.

Defining speech files

A speech file is a file containing an encoded speech phrase. Speech files can be stored anywhere, although the default speech filesystem is located in the /voice1/vfs/talkfiles directory.

Defining the speech filesystem

A speech filesystem is a filesystem where speech resides and is defined in the irAPI.rc file. Only one speech filesystem can be active at a given time.

Speech development tools and features


Speech development tools and features Nearly all applications involve playing speech to a caller. The following speech development tools and features are available for the creation, editing, recognition, and inclusion of speech in an application.

• Avaya IVR Designer

• Proxy Text-to-Speech Feature

• Speech Recognition Features

― WholeWord Speech Recognition

― Natural Language Speech Recognition (NLSR)

Avaya IVR Designer

The Avaya IVR Designer application development tool enables you to design applications that specify every detail of the interaction between the Avaya IR system and its callers. For example, the greeting heard by the caller when connecting with the service, the menu of options offered, the way callers are prompted for credit card numbers and other pertinent information, how long to wait for caller responses, and the relevant databases that need to be accessed are all parts of an application that you can define and implement with either of these tools.

Once an application is designed, you can use IVR Designer to test, generate, transfer, and install it. You can also record and edit Speech phrases with IVR Designer.

IVR Designer applications are developed on a Windows-based PC and then installed on the Avaya IR system.

For more information about IVR Designer, see the IVR Designer online help.

Proxy Text-to-Speech (PTTS) feature

The Avaya IR system has a number of features available that can greatly enhance your ability to use it effectively. Among these is the Proxy Text-to-Speech (PTTS) feature that lets you convert text input to spoken output. Text-to-speech processing must be done using one or more auxiliary computers connected to the Avaya IR system in a client/server configuration.

The current release of the PTTS feature supports two basic classes of languages:

• Japanese

• Microsoft Speech Application Programming Interface (SAPI)-compliant languages, which typically include English and most western European and Latin American languages



With the open architecture provided by this feature, you can also add other customized languages, possibly with the assistance of an independent software vendor (ISV).

The PTTS feature consists of software that is installed on a Avaya IR client system and on one or more customer-provided servers running the Windows NT 4.0 operating system. These computers communicate through socket interface connections, called PTTS connections, over an Ethernet Local Area Network (LAN). Multiple Avaya IR clients and their associated PTTS servers can be placed on a single LAN. The Avaya IR client establishes the PTTS connections and submits text to a PTTS server for conversion.

The PTTS feature supports multiple languages, and even the use of multiple languages within a single IVR application. Characteristics of the PTTS speaking voice, such as gender, rate of speech, volume, pitch, and intonation, can be customized. Barge-in (talkoff) can also be enabled to allow a caller to interrupt speech playback.

PTTS is licensed on a per-connection basis. The PTTS and TTS features share the same licensing. This means that if you already have TTS licenses, you can also use them for PTTS.

Speech recognition features

Speech recognition is a Avaya IR system feature that allows the system to recognize and respond to spoken voice responses from the caller. The system offers WholeWord and Natural Language speech recognition.

WholeWord speech recognition

WholeWord speech recognition recognizes entire words, not phonemes or parts of words. However, WholeWord speech recognition is not restricted to recognizing single words. For example, "calling card" can be recognized as a whole word.

Standard versus custom vocabulary

Avaya provides a standard WholeWord speech recognition vocabulary that includes:

• The digits 0 to 9 and "oh"

• The words "yes" and "no"

The standard WholeWord recognition vocabulary also provides connected-digit recognition (the use of two or more digits in a sequence, such as an account number).

The standard speech vocabulary is best suited for applications that require callers to respond with "yes" or "no" (such as a survey application) or for number-intensive applications (such as a banking application that requires callers to enter account numbers).

You can purchase or create a custom vocabulary if the standard WholeWord speech recognition vocabulary does not meet your needs.

Speech development tools and features


Natural Language Speech Recognition

While WholeWord speech recognition can recognize specific words or phrases, even when extraneous words or phrases are thrown in by the caller, they have no ability to recognize what part the recognized speech plays in the overall statement. In other words, these technologies are all designed to recognize specific words or phrases.

Natural Language Speech Recognition (NLSR) takes the speech recognition process further by providing a more natural conversational interface with IVR systems. NLSR can be used to recognize particular words and phrases and to interpret and assign meaning to the speech it recognizes.

For example, under the more basic forms of speech recognition, a caller can respond only to specific prompts, such as "Say `one' if you want information about..." or "Say `yes' if this is correct." NLSR enables you to write applications that ask the caller more open-ended questions, such as a banking application that presents the caller with a list of options and then asks "What would you like to do?" Then, when the caller responds "I'd like to know the balance of my checking account, please," the system can recognize what kind of information the caller is asking for (the balance in a checking account ) and can automatically direct the call to a new prompt that asks for the caller's checking account number. This new technology provides a more natural way of interacting with callers.

It is worth noting that NLSR is also able to take into account grammatical structures. This allows it, for instance, to recognize and deal appropriately with differences in statements like the following caller responses:

"I would like to fly from Chicago to LAX."

"I need to get from LAX to Chicago."

NLSR is also capable of understanding natural numbers ("seventy-six" instead of "seven six"), natural dates ("July 26th" instead of "zero seven two six") and natural currency ("25 dollars" instead of "two five zero zero").

The NLSR offer assumes you are using one or more Avaya IR systems in conjunction with one or more NLSR computers in a client/server configuration. This setup assumes that the Avaya IR is the client and the NLSR computer is the server. Beyond that, the exact NLSR system architecture is dependent on what other components you are using in conjunction with this offer.

All computers in the system communicate using an Ethernet PCI local area network (LAN) connection.



Developing speech Developing speech provides background information for the process of creating speech on the Avaya IR system.

Speech processing begins with the creation of encoded and digitized speech files for disk storage. The content of each speech file is a single speech phrase that is spoken at some point in an application dialog.

A speech phrase can consist of any of the following elements:

• A complete sentence

• A single word

• A silence period of specified duration

• Music

• A tone (for example, a "beep")

Speech phrases are typically specific to a single application. You determine the speech phrase content based on the application requirements. However, some speech phrases, such as generic greetings or prompts, may be used in multiple applications.

During a call, the individual speech phrases specified in the application are downloaded by the system from a hard disk drive to the speech resource. The speech resource actually plays the speech.

Determining the transaction

Background

The application provides the automated version of the communication between the caller and the agent. The transaction is one component of the application that involves the actual exchanges between the caller and the agent. The transaction is also referred to as the call flow.

Before you can begin speech development, you must determine the transaction for the application. It is also a good idea to develop an outline of the application, as well as a general idea of what speech phrases and prompts are necessary. For example, you must decide what type of service you are going to provide, as well as the language and the gender in which the speech will be recorded.

Developing speech


Reference

For information on:

• Planning a voice response application, see Planning voice response applications.

• Developing an application using IVR Designer, see the topics for Creating an Application in the IVR Designer online help.

• Developing an application using Response Application Programming Interface (IRAPI), the Transaction Assembler Script (TAS) language, or C language, see Developing voice applications.

Planning the voice script

The voice script includes the exact phrases to be recorded, based on the transaction you determine. The following are suggestions to consider while writing the voice script:

• Track the contents of the voice script by using phrase numbers. Number each phrase in the written voice script. (Note that this is done for you automatically in IVR Designer applications.)

• Write out every word you expect to be spoken. Edit the voice script to change any poorly written or repetitive phrases. The voice script should be as clear as possible so that a speaker can use it to record phrases.

• Ensure that changes are written into the voice script if changes are made during recording.

• Make all commands short and easy to understand. Also, users tend to remember only the ends of phrases, so place the needed caller action at the end of a phrase, for example, "For account information, press one."

• Make prompts clear, but courteous. Remember to welcome users to your company and the system. Thank them at the end.

• Use vocabulary that is understandable and not beyond the scope of your users. For example, do not use computer or programming terminology unless it is familiar to all of your users.

• Use the following types of phrases in your voice script:

― Long phrases that stand alone, for example,

"Welcome to the XYZ order entry system."

Long phrases are easier to speak for a recording because they stand alone.

― Short phrases that you plan to concatenate, for example,



"Your balance is" "Press 1"

Typically, short phrases include phrases that you will use repeatedly.

• Anticipate the environment in which the phrases will be used. That is, whether the phrase will be used at the beginning, in the middle, or at the end of a sentence. The following example shows each use of the word "enter."

" Enter your account number." (phrase at the beginning of the sentence)

"You must enter your account number." (phrase in the middle of the sentence)

"Please press enter." (phrase at the end of the sentence)

If your application contains a phrase that is used in more than one environment, you must record the phrase separately for each one. In the above example, you would need three recordings of the phrase "enter" – one phrase with rising inflection for use at the beginning of a sentence, one with medial inflection for use in the middle of a sentence, and one with falling inflection for use at the end of a sentence. Recording words with the proper emphasis is discussed below in Writing the Voice Script.

• Avoid a long string of adjectives. The following is an example of a poorly designed instruction:

"Check the 5-digit class schedule number, listed to the left of the specific course, in the course offering schedule book."

The following is a better example of how to word this instruction:

"In the schedule book for course offerings, find the specific course you are interested in. To the left of the title is a 5-digit number used for class scheduling. Press the keys or say that number now."

• Review the voice script to verify that the prompts and responses make sense.

Writing the voice script

In writing the voice script to be recorded by a professional speaker, prepare a document that produces the best recordings possible. Mark the target phrases in a way that is easy for the speaker to recognize. Placing quotation marks around the important phrases is helpful. This is called framing.

Using framing in voice scripts

Human speech is a continuous, uninterrupted signal. It should not be assumed that you can remove a word from one phrase and place that same word in another phrase that is being recorded for a different use. Individual words that you plan to concatenate must be carefully recorded with the proper inflections and sounds framing them.

Developing speech


To achieve a better recording of short words and phrases, use quotation marks to frame those words you want to emphasize. For example, to achieve accurate recordings of the word "enter," use quotation marks in your voice script as follows so that the speaker concentrates on the word "enter:"

"Enter" the pound sign.

Please press "enter."

The following are examples from a well-prepared voice script that uses framing. The information in quotation marks is the information that the professional speaker should focus on, while the remaining information is the framework.

To learn more about our investment opportunities, press the "star key."

"This amount represents" the total balance.

"Please enter" two or one.

You have "a balance of" two hundred dollars.

You can deposit "up to" five hundred dollars.

Analyzing speech inflections

Three types of inflection exist with speech phrases:

• Rising inflection

Rising inflection is usually used in questions and at the beginning of some words. For example, when you ask, "Can I help you?", the word "you" is spoken with rising inflection.

• Medial inflection

Medial inflection is usually used in the middle of a word or statement. For example, when you speak the number "302" (as "three oh two"), the "0" is spoken with medial inflection.

• Falling inflection

Falling inflection is usually used at the end of a word or statement. For example, when you speak "2.0", the "0" is spoken with falling inflection.

Note: Enhanced Basic Speech formats are available with rising, medial, and falling inflections. See EBS format tables on page 89.

Placing frame words

Place words or phrases before and after the word or phrase that you need recorded, if possible. These phrases should be familiar phrases that guide the speaker into speaking the word or phrase with the correct inflection. For example, if you want an accurate recording of



the word "and" with medial inflection, you could record the word "and" in both of the following frames:

Installing "and" verifying Cutting "and" pasting

You can remove the words that frame "and" later since they are not needed. These frame words are important, though, because the frame words enable a speaker to speak the word "and" in the context necessary to ensure that it is concatenated properly when used in a phrase.

Note: The word "and" is part of the Avaya Enhanced Basic Speech package.

Selecting speech sounds for framing

Words that end with the r or l sounds do not make good framing words because those sounds carry over to the next word. In this example,

December "eighth"

"December" is not a good frame word because it ends in an r sound, which affects the vowel quality of "eighth." A better frame word is "August," as follows:

August "eighth"

Including voiceless speech sounds

By contrast, placing a voiceless stop before and after your target word will help achieve an accurate recording. Voiceless stops are sounds like p, t, and k. When a voiceless stop is spoken, the stream of air is blocked and the vocal cords do not vibrate, resulting in a momentary silence. In the example above, the final t of "August" provides a silence that makes it easy to isolate "eighth."

Other voiceless sounds useful to end or begin a frame or space are f and s.

Selecting a speech development method

As an application developer, you have several options from which to choose for including speech in your application.

The following options require you to record speech:

• Hiring a professional speaker

• Purchasing an Avaya custom speech package

• Producing self-recorded custom speech with the IVR Designer development tool

Developing speech


The following options do not require you to record speech:

• Purchasing the EBS (Enhanced Basic Speech) package

• Using TTS (Text-to-Speech)

• Sharing speech already recorded in another application

• Importing speech from another application

Hiring a professional speaker

Hiring a professional speaker, such as an actor or an announcer, gives you recorded speech of high quality. Consider the following when choosing a professional speaker:

• Have all phrases prepared for the speaker to read in advance of the recording session. See Planning the voice script on page 55 and Writing the voice script on page 56 for guidelines.

• Audition several speakers of both sexes. Record and digitize their voices to evaluate the encoded quality.

• Ensure that the speaker is able to maintain the following:

― Constant speaking rhythm and general intonation throughout the recording session (this ensures that phrases spoken early in the session result in normal-sounding speech when they are concatenated with phrases spoken later in the session)

― Constant acceptable level of volume

― Clear pronunciation

― Constant orientation and distance from the microphone

• Ensure that alphabetic and numeric characters that are to be recorded with rising, medial, and falling inflections are spoken with the appropriate inflections.

• Use the same speaker for all speech associated with a specific application.

If you hire a professional speaker, you can edit the speech phrases for the application script. See Editing speech on page 62, for more information about editing speech.

Purchasing an Avaya custom speech package

You can purchase a professionally recorded custom speech package from Avaya. You write out the script and Avaya records and digitizes the speech. Custom speech packages are available with both male and female voices. Custom speech contains phrases designed specifically for the application you are developing. For example, "Thank you for calling Avaya," is a custom speech phrase.



An advantage of purchasing a custom speech package from Avaya is that the speakers who record the custom speech phrases are often the same speakers who record the EBS (Enhanced Basic Speech) phrases. Therefore, a continuity can exist among scripts that use both custom and enhanced basic speech.

Producing self-recorded custom speech

IVR Designer allows you to record speech and store it yourself. You may want to begin with the Enhanced Basic Speech phrases mentioned previously. The standard set includes letters and digits in different speaking inflections and many commonly used phrases, such as the words used to speak dates, times, dollar amounts, etc. You can then use the recording capabilities provided with IVR Designer to record your own speech for phrases unique to your application.

Speech recorded with IVR Designer default speech editor is saved in .wav files. However, when these speech files are installed on the Avaya IR system through IVR Designer, they are converted to G.711 coding.

Note: The quality of speech recorded through IVR Designer is not as high as the quality produced from professionally recorded speech.

Reference

For information on recording speech with IVR Designer, see the Phrase Editor and Audio recording tips topics in the IVR Designer online help.

Purchasing the EBS (Enhanced Basic Speech) package

You can purchase the professionally recorded EBS (Enhanced Basic Speech) package from Avaya. The EBS package provides the following:

• The most commonly used words and phrases, including the letters of the alphabet, pronounced and recorded in rising, falling, and medial inflections

• Essential numbers ("zero" through "twenty," "thirty," "forty," "fifty," "sixty," "seventy," "eighty," "ninety," "hundred," "thousand," and "million")

• Days of the week

• Months of the year

• Ordinal numbers 1 through 31 (that is, "1st" through "31st")

• The words "dollars" and "cents"

The EBS package speaks information using a variety of built-in speech formats. For example, if you want the system to speak a number using a money format, you might use number phrases followed by the phrase "dollars and," then the number of cents and the phrase

Developing speech


"cents." For a complete listing of the available EBS formats, see EBS format tables on page 89.

Using PTTS (Proxy Text-to-Speech)

The PTTS package is an option that eliminates the need for recording speech. You enter the phrases to be spoken, and PTTS synthesizes the speech.

PTTS functionality is supported through the IVR Designer application development interfaces as well as through TAS script instructions. The talkoff function and other system features for voice response work with PTTS as they work with other speech files.

PTTS, Enhanced Basic Speech, and prerecorded phrases can be used in the same application.

Sharing speech

Sharing speech allows two or more applications to share common speech phrases, only one copy of which exists on your hard disk. If you have more than one application on a system, it will probably be more convenient for you to use the shared speech feature. Sharing speech provides a performance advantage in that shared speech phrases need to be:

• Administered and recorded only once

• Stored only once, allowing you to conserve disk space

Importing speech

You can import speech phrases from other applications and edit them.

For IVR Designer applications, you can use the Phrase Editor to import the .wav file corresponding to the phrase you want. Then you can edit the phrase with the audio editing application installed on your PC.



Editing speech Typically, IVR Designer is used to remove unwanted silence from the beginnings and endings of recorded speech phrases. However, the audio application provided with the IVR Designer package can be used to cut and paste segments of speech within the body of a phrase.

You can also edit speech files using a customer-provided audio application installed on your IVR Designer PC.

To edit speech files with the IVR Designer audio application, see information about the Phrase Editor in the IVR Designer online help.

Recognizing WholeWord speech input


Recognizing WholeWord speech input Recognizing WholeWord speech input describes the capabilities of WholeWord speech recognition and the factors that influence the accuracy of recognition.

How WholeWord speech recognition works

Overview

WholeWord speech recognition is available as an optional installable package on the Avaya IR system. WholeWord speech recognition allows you to write applications that prompt for and understand spoken input from callers. This feature supports a standard vocabulary that includes:

• The digits 0 to 9 and "oh"

• The words "yes" and "no"

Processing involved during WholeWord speech recognition on the Avaya IR system includes a caller response, the action of the recognizer, and processing.

Caller response

During a Prompt and Collect action, the system prompts the caller for a response. If the Prompt and Collect action allows for voice input, the system locates and reserves a free recognizer resource.

The recognizer

The WholeWord speech recognition software is also called the recognizer. The recognizer compares the incoming speech sample to the word models indicated by the recognition type chosen in the Prompt and Collect action. The recognizer computes a score for each of the models. The score represents the likelihood that the incoming speech matches a word model indicated by the recognition type. The recognizer returns the most likely candidate to the specified variable. For IVR Designer applications, the variable is stored in the Save Response In field in the Prompt and Collect, Automenu, and Menu nodes (see the appropriate node description in the IVR Designer online help).

For the following example the variable is [CollectedDigits] for an IVR Designer application. If none of the candidates sufficiently match, the input is rejected and a "?" or an empty string value is returned to the script. For example, for a prompt of "1, 2, or 3" the application developer selects the US_1_3 recognition type, which is used for a response consisting of "1", "2", or "3." The caller's voice response to the prompt is compared to a model of the numbers "1", "2", and "3," and a score is computed for each number. Whichever score is



highest determines the recognized result. A value of "1", "2, or "3" is returned in [CollectedDigits]. If no value scores high enough, the recognizer returns a "?"as the value. The application then decides what to do next, based on the value of the field. For strings of digits, the recognizer first determines up to four of the top scoring strings and their resulting scores. The recognition DIP then returns to the script the top scoring string whose length falls between minimum and maximum number of digits specified in the application. The string is then stored in [Collected Digits].

Bilingual capabilities

You can load and operate any two WholeWord speech recognition language packages on a single system simultaneously. The bilingual speech recognition capability is available within the same call, but not within the same prompt. For example, an initial prompt can be used to determine which language the caller prefers to use. However, a custom grammar has the ability to combine bilingual recognition capabilities in the same prompt.

Standard WholeWord speech recognition types

Description

A recognition type allows you to indicate which keyword or words are possible selections for each prompt. All of the recognition types and words used by an application constitute that application's vocabulary. A complete recognition type includes:

• Mathematical models of the words (see "Models and speaker independence" for more information)

• A grammar (see "Grammars" for more information)

• Specifications of maximum and minimum numbers of digits (see Fixed-Length Versus Variable-Length Connected Digits for more information)

• A recognition data interface process (DIP) – optional (see Recognition DIPs for more information)

The standard WholeWord speech recognition package provides several commonly used recognition types. In IVR Designer applications, the recognition type is selected through the Response tab of the Prompt and Collect, Announce, Menu, Automenu and Voice Capture nodes (for more information, see the appropriate node description in the IVR Designer on-line help).

Models and speaker independence

Each word of the system's vocabulary is represented by one or more mathematical models that contain the speech signal characteristics of the word. The speech recognition process



compares a person's voice to the set of predeveloped speech models. Each model is constructed from thousands of samples of the spoken word. Regional accents and dialects associated with a particular language are incorporated into each model. Each model also includes a mix of male and female speakers so that the system recognizes callers of either gender speaking in any of those dialects with any of those accents. The recognition type determines which models the incoming speech is compared to.

Grammars

A grammar, which is selected by a recognition type, is a set of rules that specifies allowable vocabulary words and vocabulary word combinations at any one point in the script (for example, "four," "five," "six," "no"). While collecting spoken input, the speech recognition algorithm uses models and grammars to generate a list of candidates that most closely resemble this spoken input. The algorithm returns the most likely match to the script or, if no match fits, rejects the input. When input is rejected, the algorithm returns a "?" or an empty string to the script. This return message is the same for all of the languages supported. All grammars provided in the speech recognition package share the same set of models for words that are common to their package's vocabulary.

Keyword recognition types

Keyword recognition types are used for isolated word recognition, that is, responses of a single word or digit. The following table shows the standard WholeWord speech recognition types, which are used when prompting the caller to speak a response of one word or digit. The US_1_3 recognition type, for example, means that callers are expected to say a single word, either "one," "two," or "three." A prompt that might use the 1_3 digit grammar type could be structured as follows: "For checking account balance, say `one'. For savings account balance, say `two'. For interest rates, say `three'."

Language "Yes" or "No"

One digit 1_3

One digit 1_3 or "no"

One digit 1_5


One digit 0_9 or "oh"

Australian English AU_YN AU_1_3 AU_1_3N AU_1_5 AU_1_5N AU_DIG

Brazilian Portuguese

BP_YN BP_1_3 BP_1_3N BP_1_5 BP_1_5N BP_DIG

Canadian French CF_YN CF_1_3 CF_1_3N CF_1_5 CF_1_5N CF_DIG

Castilian Spanish CS_YN CS_1_3 CS_1_3N CS_1_5 CS_1_5N CS_DIG

Dutch NL_YN NL_1_3 NL_1_3N NL_1_5 NL_1_5N NL_DIG

French FR_YN FR_1_3 FR_1_3N FR_1_5 FR_1_5N FR_DIG

German GR_YN GR_1_3 GR_1_3N GR_1_5 GR_1_5N GR_DIG

Italian IT_YN IT_1_3 IT_1_3N IT_1_5 IT_1_5N IT_DIG



Language "Yes" or "No"

One digit 1_3


One digit 1_5


One digit 0_9 or "oh"

Japanese JN_YN JN_1_3 JN_1_3N JN_1_5 JN_1_5N JN_DIG

Latin-American Spanish

MS_YN MS_1_3 MS_1_3N MS_1_5 MS_1_5N MS_DIG

UK English UK_YN UK_1_3 UK_1_3N UK_1_5 UK_1_5N UK_DIG

US English US_YN US_1_3 US_1_3N US_1_5 US_1_5N US_DIG

Connected-digit recognition types

Connected-digit recognition types are used for connected-word recognition, that is, responses of more than one word or more than one digit string. The spoken string can be fixed in length from 1 to 10 digits, or it can be of a variable length. Grammars are provided for the 1-digit to 10-digit fixed-length and the 1-digit to 24-digit variable-length strings.The following table lists the connected-digit recognition types.

Note: Languages other than US English do not allow strings of greater than 10 digits. With US English, use of a custom grammar is recommended.

Language Fixed Length 1-10 Digits or Variable Length 0-24 digits (US English only)

Australian English AU_DIG

Brazilian Portuguese BP_DIG

Canadian French CF_DIG

Castilian Spanish CS_DIG

Dutch NL_DIG

French FR_DIG

German GR_DIG

Italian IT_DIG

Japanese JN_DIG

Latin-American Spanish MS_DIG

UK English UK_DIG



Language Fixed Length 1-10 Digits or Variable Length 0-24 digits (US English only)

US English US_DIG

For better accuracy, you must specify the desired string length when selecting the recognition type for a fixed-length string. A U.S. telephone area code (614, for example), consists of three words; therefore, the minimum and maximum values are "3." If a variable-length string (US English only) of one to four words is required, "1" is the minimum value and "4" is the maximum value.

In IVR Designer applications, the minimum and maximum number of digits in the string are specified through the Minimum Length and Maximum Length fields in the Response tab of the Menu, Prompt and Collect, or Automenu node (for more information, see the appropriate node description in the IVR Designer online help).

Connected-digit recognition

Connected digits are strings of naturally spoken digits, which may or may not include a pause. All packages recognize spoken digit strings. Connected-digit recognition packages allow you to collect input by specifying a fixed-length of 1 to 10 digits or, for US English only, a variable-length of 1 to 24 digits. Number entry is an essential component if you want callers to input numbers with more than one digit, for example, "1, 3, 5" or "2, 4, 6, 8". Recognition accuracy is better for fixed-length strings than for variable-length strings.

Fixed-length versus variable-length connected digits

The capability to recognize fixed-length strings of 1 to 10 digits is provided with WholeWord speech recognition packages. A fixed-length string is a string of digits that is always made up of the same number of digits. For example, a U.S. Social Security number is a fixed-length number, since it always consists of nine digits. By contrast, a variable-length string indicates a string of digits that varies, for example, a street address.

Note: The variable-length string is available for US English only.

Recognition accuracy is best when you use fixed-length strings. For strings longer than 10 digits, use of a custom grammar is recommended (for more information, see Custom grammars on page 71). Using the provided variable-length grammar as an alternative results in decreased accuracy. If your application must accept a variable-length digit string, you may be able to increase recognition accuracy by using a two-step entry process. First prompt the caller for the number of digits, and then prompt for the digits. For example:

"How many digits are in the next code?" "Please say the three-digit code now."

The script can then select a fixed-length recognition type for the appropriate number of digits.



Recognition DIPs

A recognition data interface process (DIP) is used to help increase an application's accuracy. For example, certain digit strings, such as credit card numbers, have check digits built into them. Verifying a check digit is done most efficiently through a DIP. However, a DIP is not necessary for many recognition types. If there is no further information to consider for a string other than what is in the grammar, a DIP is not needed. Specifically, none of the standard WholeWord speech recognition types, such as "yes" and "no," needs a DIP.

For some recognition types, there may be tradeoffs that determine how much of the structure of the input is built into the grammar and how much should be left for the DIP.

Word spotting

WholeWord speech recognition supports word spotting. Word spotting is the ability of the system to ignore extraneous speech during speech recognition. For example, if a caller says, "I want number five, please," the system recognizes the word "five" as a valid response and ignores the rest of the input. In other words, callers do not have to speak the key word, which in this case, is "five" in isolation. The caller can speak other words, and the system can distinguish the key word from the extraneous words.

This means that the caller's input is not limited to the words in the system vocabulary. For example, in the phrase "Uh, yes please," the vocabulary word "yes" is recognized if the system is using the standard vocabulary.

However, to maintain good recognition accuracy, it is advisable to structure the application to prompt the caller for the required information only.

Phrase screening

Phrase screening is the ability of the system to determine whether or not a candidate key word is a close enough match to be declared a valid key word. For example, if the prompt states, "Please respond with `yes' or `no'," and the caller speaks the word "what," the system informs the caller that the response is invalid. The application can be designed to then replay the prompt, "Please respond with `yes' or `no'."

However, to maintain good recognition accuracy it is advisable to structure the application to prompt the caller for the required information only. Although the system can screen phrases, recognition accuracy is best when the application is written to encourage the caller to speak only what is required.



Recognition confirmation

Recognition confirmation is the ability of the system to repeat the caller's spoken response back to the customer for confirmation. For example, a script prompts a caller, "Please say your area code," and the caller says, "Six, one, four." Using recognition confirmation, the system repeats what it recognizes the caller's response to be and then prompts, "If this is correct, say `yes', if not say `no'." The caller then confirms whether the system recognized the spoken input properly.

For more information about recognition confirmation in IVR Designer applications, see information about the Confirmation Input Mode field on the Confirmation tab of the Menu, Prompt and Collect, Automenu, or Voice Capture node in the IVR Designer online help.

Barge-in

Barge-in, also called "allow interrupt" or "recognize during prompt," is the ability of the system to allow callers to interrupt or barge in during voice playback by speaking a vocabulary word. Speech recognition accepts either speech or touchtone input in response to a prompt. Barge-in operates for speech much like the talkoff option does for touchtone input, where a caller can interrupt the prompt by pressing a touchtone key on the telephone keypad. For more information on touchtone interrupts, see Dual Tone Multifrequency (DTMF) support on page 71.

Experienced callers appreciate being able to shorten the transaction time by not being required to listen completely to each prompt. You can enable or disable barge-in for any of the prompts in your application.

Note: The system is able to detect touchtones immediately. However, it does take a few seconds longer to detect valid speech, as opposed to a cough, sneeze, and so on. You should expect a slight delay when using barge-in.

For isolated word recognition, the prompt does not stop until the system recognizes a valid vocabulary word. Once the prompt completes playback, the initial timeout field eventually ends the recognition if no valid input is received.

For packages that support connected-digit recognition, the playback of the prompt stops between the recognition of the first and last word of the input, when the system decides that valid input has started.

Enabling or disabling barge-in

At the beginning of an application, after the answer instruction, you must place an SR_Prompt instruction to enable barge-in. If a barge-in resource is available, it is reserved for this call. Otherwise the return code to SR_Prompt is negative, and barge-in is not available.



For information about using SR_Prompt in IVR Designer applications, see the Standard external functions topics in the IVR Designer online help.

You can also enable or disable barge-in a Prompt and Collect action (assuming barge-in has been globally enabled with a SR_Prompt instruction) so a prompt can be interrupted by voice or touchtones. Enabling barge-in for prompts in IVR Designer applications is done by setting the Allow Interrupt field to "true" in the Response tab of the Menu node, the Prompt and Collect node, or the Automenu node (for more information, see the appropriate node description in the IVR Designer online help.

If your application does allow barge-in, be sure your prompts are worded so that callers know they cannot speak until the prompt is finished. For example, look at the wording and the <pause> length of the prompts in Discouraging Barge-In. There are no large gaps of silence to tempt callers to speak barge in.

Discouraging barge-in

The following example includes short pauses that tell the caller that the system is waiting for a response. The caller answers at the time of the short pause.

"For sales say, `one'.'" (short pause) "For service, say, `two'." (short pause) "To speak with a representative, say `three'."

The following example does not include pauses. The caller waits until the prompt is completed before answering.

"You can order up to five copies. Please say how may copies you want."

If there is silence at the end of a prompt, the caller might speak but the system might not be prepared to listen. Make sure that there is no silence at the end of your recorded phrases when barge-in is disabled.

Encouraging barge-in

The following examples are designed to encourage callers to barge in when barge-in is enabled. Note that the pauses are longer than in the examples in Discouraging Barge-In, so callers are encouraged to respond after hearing the desired option and the word "now."

"For sales say, `one' now." (pause of 1 to 1.5 seconds) "For service, say, `two' now." (pause of 1 to 1.5 second) "For a representative, say `three' now." (pause of 1 to 1.5 seconds)

System response for barge-in

For an application using speech recognition with barge-in, callers who choose to talk over the prompt message can not barge-in until most of the digit string is spoken. The distinction in response is as follows:



• When a fixed-length digit recognition type is used, the prompt can be interrupted after N -2 (N minus 2) digits are spoken plus a system delay of 0.75 second, where N is the total number of digits to be collected. For example, for the US_9DIG recognition type, the prompt can be interrupted after seven digits.

• When short prompts are used, callers might not detect delays in the barge-in point because the prompt frequently completes before the caller speaks much input.

Dual Tone Multifrequency (DTMF) support

Even with WholeWord speech recognition installed, callers still have the option of responding to prompts with touchtones rather than speaking. Speech recognition accepts either speech or touchtone input in response to a prompt. Talkoff is the ability of the system to allow callers to interrupt during voice playback by pressing a key that generates a DTMF touchtone. Talkoff operates for touchtones much like barge-in does for speech, where a caller can interrupt a prompt by speaking.

Often the response time for talkoff is faster than for barge-in. This is because touchtones were designed to be recognized by machines and are rarely confused with other sound or voice input. However, WholeWord speech recognition must perform the more complex task of separating the desired input from other sound or voice input that might be present simultaneously. The system does not terminate a prompt until it processes enough input to ensure with relatively high confidence that the input is valid. For a prompt requiring single-digit input, talkoff and barge-in may appear equally fast since the input is completed with a single touchtone or a single spoken digit. Prompts for multidigit input reveal the difference between the response times for talkoff and barge-in. For information comparing talkoff and barge-in, see Barge-in on page 69.

Custom grammars

Recognition types are the choices associated with the Input ASR Mode field of the Response tab on Prompt and Collect, Menu, and Automenu nodes in IVR Designer.

The system uses the recognition type, along with other fields, to select a speech recognition grammar to be used for that prompt. Certain digit strings and custom vocabulary words may require custom recognition types and associated custom grammars for acceptable recognition accuracy. Examples include a credit card number or a merchant number. These digit strings have specific limitations on the position of certain digits within the string. For example, a telephone area code in North America requires a number 2 through 9 for the first digit, 0 through 9 for the second digit, and 0 through 9 for the third digit.

Custom recognition types help limit the recognition possibilities, which results in better accuracy.

For more information, contact your Avaya representative.



Custom vocabulary

Avaya can create a custom vocabulary to supply your application with speech recognition software for words not included in the standard package. For example, the vocabulary might include the words "checking" and "savings." With a custom vocabulary, the application could prompt the following:

"For your checking account balance, say `checking' or to hear your savings account balance, say `savings'."

A custom vocabulary requires application analysis by Avaya, speech data collection, model creation, and custom grammar work. For more information, contact your Avaya representative.

Custom DIPs

You can improve recognition accuracy by using an application with a DIP. DIPs, which are typically written in the C programming language, interact with your script to help access external information. Once a request is received from a transaction state machine (TSM) script, for example, the DIP processes the message and returns the results to the corresponding script.

WholeWord speech recognition accuracy

Overview

The accuracy of WholeWord speech recognition depends not only on the recognition algorithms, but also on the models, grammars, DIPs, prompt structure, calling environment, user behavior, and the recognized data itself. Each of these factors can impact recognition accuracy positively or negatively. Also, measures of accuracy must be based across the entire calling population. Therefore, any attempt to measure accuracy must include a statistically representative sample of the calling population.

Positive influences on WholeWord speech recognition accuracy

The items described below have a positive impact on WholeWord speech recognition accuracy.



Isolated word recognition

Isolated word recognition is very high. The smaller the number of choices in an isolated word recognition type, the better the accuracy. For example, "US English Digits 1 to 3" is more accurate than "US English Digits 1 to 5", which in turn is more accurate than using "US English 1 digit (0-9 and `oh')".

Fixed-length digit string

For connected-digit recognition, a fixed-length recognition type provides better accuracy than a variable-length recognition type. If possible, avoid the use of variable-length strings in WholeWord speech recognition applications.

Validation of data

Try to verify the recognized result against a database or a host field. This helps improve the overall accuracy of an application, especially when a longer string is input.

Reprompt

If the keyword is not spoken, and the system does not misinterpret extraneous words for a keyword, the system can reprompt the caller. If the accuracy measurement is based on a WholeWord speech recognition application with a confirmation and reprompt step, the accuracy increases.

Prompt structure

The prompt structure can greatly affect accuracy by promoting a clearly articulated response, helping the caller to barge in at the appropriate time or to wait until the prompt is complete before talking when barge-in is disabled, and providing consistent instructions on what the caller should say to get the desired result.

• Menu prompts

For best results, build menu prompts with the following structure:

<desired result> <action required>

Examples:

"To hear your checking account balance, say 1." "To hear your savings account balance, say 2."

Placing the action required at the end of the prompt helps eliminate the possibility that the caller might forget what is required while listening to the description of the desired result. In addition, if you want to encourage your callers to barge in when they hear their desired result, you can add a small pause after the action-required phrase.

• Yes and no prompts



Structure yes and no prompts as yes and no questions. For example:

"Would you like to hear your order number again?"

If the caller does not respond to the prompt, the follow-up prompt could be as follows:

"Would you like to hear your order number again? Please say `yes' or `no'."

This wording is more natural than the following:

"To hear your order number again, say `yes'. Otherwise, say `no'."

To encourage the use of barge-in, add a pause of about 1.5 seconds following the action required phrase. For example:

"Would you like to hear your order again? (pause) Please say `yes' or `no'."

Calling experience and informative prompts

In an application where the calling population is closed and callers are experienced or trained to use the application, recognition accuracy improves.

Lengthy prompts that provide detailed instructions on how to respond may improve accuracy, but are generally unacceptable unless the application has infrequent users. Users who interact with system prompts infrequently (for example, once or twice a year) are more willing to listen to a lengthy prompt than those who do so frequently.

Custom grammars and DIPS

Custom grammars improve the recognizer's ability to "score" the candidate by selectively limiting the recognition possibilities. The recognizer assigns a score to each input based on closeness of match to the models for the selected grammar. Custom DIPS help to further process the recognition result with information that is unavailable to the recognizer.

Negative influences on WholeWord speech recognition accuracy

The items described below have a negative impact on WholeWord speech recognition accuracy.

Environment

A very noisy environment, such as an airport or train station, can cause recognition accuracy problems. In certain cases, speech data can be collected to build custom word models based on the noisy environment to improve recognition accuracy.



Extraneous words within responses

The system can sometimes misinterpret extra words that are spoken alongside the keyword if they have the same characteristics as the key word.

Information type

Attempting to recognize data that is not normally spoken in the form of the digits 0 through 9 adversely affects accuracy. For example, dollar amounts and days of the month are not usually spoken in digit form 0 through 9. To speak the date December 15 using digits, the caller would have to say "1-2-1-5." Training callers to speak information in this format can increase application accuracy. However, if callers also attempt to speak natural numbers, such as "fifteen," speech recognition will not work.

The Natural Number Speech Recognition package, available from Avaya, does allows you to accept and use more natural caller responses, such as "December 15th" instead of "1-2-1-5" or "twenty-two dollars and thirty-seven cents" instead of "2-2-3-7". You can also use the Natural Language Speech Recognition offer to get this same kind of flexibility (for more information, see Using NLSR in voice applications on page 77).

Regional and national accents and dialects

Although WholeWord speech recognition is based on thousands of speech samples per word, the system can still misinterpret strong regional or national accents or dialects.

Connected-digit string length

Connected-digit string recognition can be thought of as a sequence of single-digit recognitions performed as one operation. For example, assume that the per-digit accuracy is X % and that a digit string of one digit will be correct X % of the time. Taking into consideration that this is a probabilistic, exponential model, when longer digit strings are used, the overall expected accuracy will be X n %. Therefore, a two-digit string will have an overall expected accuracy of X 2 % and a 10-digit string will have an overall accuracy of X 10 %. As a result, string accuracies are affected by the length of the string. Shorter string lengths are more accurate than longer string lengths. In addition, individual digit accuracies, as well as overall string accuracies, vary according to the language and noise conditions of different national networks.

Connected-digit string accuracy can be maximized in various ways:

• Accuracy is always better for shorter strings than for longer strings.

• Fixed-length strings are more accurate than variable length strings since the recognizer knows to look for " X " number of digits.

• With custom programming, it is possible to further improve the accuracy of an application by having the recognizer return a list of possible strings. When these can be validated



against external information such as comparing potential account number strings against a database of valid account numbers, the correct string can frequently be chosen.

• The recognizer can also be given a custom digit string grammar that can guide the recognizer when the digit string must conform to specific digit sequence rules. To obtain custom grammars, contact your Avaya representative.

For a WholeWord speech recognition string of digits, the per-digit accuracy is comparable to isolated word recognition. However, the accuracy of the whole string is lower than the per-digit accuracy, and steadily decreases as more digits are added.

Application-related limitations

The capability of the system and WholeWord speech recognition is application dependent. If the system is underengineered for a particular application, it may not perform satisfactorily.

Specific application-related factors that affect the number of supported WholeWord speech recognition channels include:

• The percentage of time spent recognizing speech input

• The percentage of callers who use touchtone entries, which require fewer hardware and software resources

• The number of simultaneous speech recognition calls expected

• The use of barge-in with WholeWord speech recognition, which increases the hardware and software resources required to process each transaction.

Using NLSR in voice applications


Using NLSR in voice applications Natural Language Speech Recognition (NLSR) lets you create IVR applications that offer the caller a more natural way of interacting with the software. NLSR uses a client/server configuration in which the Avaya IR system uses one or more external NLSR servers to process speech data collected from callers during Prompt and Collect actions. NLSR is a flexible new way to take advantage of external vendor NLSR engines within IVR applications.

NLSR grammars

A prerequisite to creating and deploying NLSR applications is creating the required NLSR grammars. Check with your NLSR vendor for the specifics on how to create and install the required grammars.

In addition to creating the actual NLSR grammars, you must also create corresponding "stub grammars" for each NLSR grammar you intend to use in your application. For information about how to create stub grammars, see Creating stub grammars.

Barge-in and NLSR

Barge-in is a capability provided by some speech recognition technologies, including NLSR, that allows callers to speak or enter their responses during a prompt and have those responses recognized and acted upon immediately without having to play the entire prompt (similar to the Speak with Interrupt capability for Announce nodes).

Note: In the following discussion of Avaya IR applications, the use of the term "node" refers to elements used in IVR Designer applications.

Barge-in is not exactly the same as the Speak with Interrupt feature used for Announce nodes. The Speak with Interrupt feature works only with touchtone input. Barge-in, which works with WholeWord and NLSR input, can accept either touchtone or spoken response inputs.

Thus, the Announce node cannot use spoken responses to interrupt the Announce prompt, only touchtone input.

By contrast, the Prompt and Collect node, the Menu node, and the Automenu node prompts can all be interrupted using either touchtone or spoken input from the caller.

Note: You can restrict barge-in to touchtone-only input in these nodes by selecting Touchtones as the only Input ASR Mode. However, if you select a WholeWord



or NLSR grammar as the Input ASR Mode, the system also accepts touchtone input, so you effectively get both types of barge-in.

To use barge-in, you must use an SR_Prompt external function in IVR Designer.

Note: When creating NLSR applications in IVR Designer that use barge-in, you should use Touchtone for all Input ASR Mode settings and make sure that you do not set "Reserve ASR Resource Before Playing Prompt" to True on the Response tab (Prompt and Collect and Automenu nodes).

You can, if you want, treat different types of inputs from the caller differently in your application. When a response to a prompt is received from a caller, the system sets the $CI_RECOG system variable to identify the type of recognizer that performed the recognition. For example, if the caller responds using touchtone input, the system sets the $CI_RECOG variable to 0 (zero). If the caller responds with a spoken reply, the system sets the $CI_RECOG variable to 4. So, you can have the application look at the value stored in the $CI_RECOG variable after a caller responds to a prompt and take different actions according to whether the caller responded with touchtone or spoken input.

Using NLSR external functions in an IVR Designer application

In a typical IVR Designer application that uses NLSR, external functions are used to:

• Allocate NLSR resources on the NLSR server (allocPROXY) and release NLSR resources when the application is finished with them (deallocPROXY)

• Exchange command and response strings with the NLSR server (requestPROXY)

Using NLSR in voice applications


The following illustration shows how these external functions might be used in a typical application. Note that this is only one example of a typical call flow.



These external functions allow you to incorporate natural language speech recognition into your IVR Designer applications. For more information about using external functions, see the on-line help for IVR Designer.

Putting it together


Putting it together Putting it together describes the considerations for using speech-related features in applications, such as why certain features work well together and when you can use certain features together.

Using NLSR with other features

Natural Language Speech Recognition (NLSR) allows you to create a more natural, conversational style of interacting with the Avaya IR system. Depending on the external vendor's speech recognition engine and its capabilities, you may not need any other speech recognition technologies in your system.

There may, however, be times when it is more advantageous to use a variety of speech recognition technologies, depending on what kind of speech you need to recognize at each prompt. NLSR can be used in combination with other recognition technologies such as WholeWord.

If, for example, you are looking for a simple "yes" or "no" response from a caller, it may be more efficient to use WholeWord speech recognition rather than tying up your NLSR resources.

In the end, however, a great deal depends on your NLSR engine and its capabilities, when trying to answer the question of whether to use other speech recognition technologies in conjunction with NLSR.

Getting the most out of Text-to-Speech

The following tips can help you use standard TTS most effectively in prompts and announcements.

• When TTS prompts are used with touchtone input, callers can interrupt the prompt just as they can when the prompt is prerecorded.

• Callers can also interrupt TTS prompts with WholeWord speech recognition input.

Using Text-to-Speech and prerecorded speech together

An IVR Designer application can speak prompts and announcements in prerecorded speech only, TTS only, or a combination of prerecorded speech and TTS.



For example, in one application, recorded speech is used for all phrases except the customer's name. TTS allows the system to speak the contents of a "cust_name" variable, which contains the customer's name as a character string. To have this name spoken without TTS, you would have to record every possible customer name, save the phrase tag numbers of each, and associate the phrase tag number with the customer account number. Then the system would speak the phrase tag number corresponding to the customer's account number.

Furthermore, each time you add a customer's name to the list, you would have to update your application, record the new name, recompile your application, transfer, and reinstall it on the Avaya IR. Obviously, this would involve a huge amount of work just to maintain the names in the system. In cases like this, it might make more sense to use TTS to speak the customer's name.

Using WholeWord and Natural Language Speech Recognition together

WholeWord and NLSR speech recognition can be used in a single application script. This allows flexibility in what you can ask callers to say. In IVR Designer applications, you can specify that a Prompt and Collect node use either of these three speech recognition technologies, depending on what you want to prompt callers to say. In general:

• If you want callers to say "yes" or "no," a series of digits, or a single digit, choose WholeWord speech recognition.

• If you want callers to speak a word or phrase from a custom vocabulary, choose NLSR.

• If you want to allow callers more freedom to speak their responses with a system capable of recognizing and interpreting what they say, use NLSR.

Note: Only one recognizer can be used in each single prompt.

Comparison of recognition types

The following table summarizes the similarities and differences between WholeWord speech recognition and NLSR.

WholeWord Recognition Natural Language Speech Recognition Word-based Depends on external vendor NLSR engine

Requires data collection in model building for vocabulary words other than digits 0 through 9, "oh", and the words "yes" and "no"

Depends on external vendor NLSR engine

Putting it together


WholeWord Recognition Natural Language Speech Recognition Single or connected digits Single or connected digits, single word or

phrase

Standard and custom grammars Custom or standard external vendor NLSR grammars

Barge-in supported Depends on external vendor NLSR engine

Phrase screening supported Phrase screening supported

Limited vocabulary Vocabulary limited by external vendor NLSR engine

Word spotting supported Depends on external vendor NLSR engine, but word spotting usually supported



Enhanced Basic Speech formats Enhanced basic speech (EBS) formats specify algorithms that convert the values in IVR Designer variables to prerecorded phrases. EBS formats are available for application development in numerous languages.

This section contains tables that list the formats in the EBS packages for all supported languages. The tables are designed to be used as reference when you create speech applications using EBS. Background information is also provided for the EBS formats.

For information on using EBS formats in IVR Designer applications, see the topics about variables in IVR Designer online help.

Languages available

The following table lists the languages for which EBS is available and, for each language, shows the gender of the speaking voice (female or male), the abbreviation, and the phrase pool name.

EBS Version 6.0 Speaking Voice

Abbreviation Phrase Pool Name

Australian English Female ebsAE AU_English


Female ebsBP BR_Portug

Canadian French Female ebsCF Can_French

Cantonese Chinese

Female ebsCT Cantonese

Castilian Spanish Female ebsCS Cast_Span

Czech Female ebsCZ Czech

Dutch Female ebsDT Dutch

French Female ebsFR French

German Female ebsGR German

Hindi Female ebsHD Hindi

Hungarian Female ebsHU Hungarian

Indonesian Female ebsIN Indonesian

Italian Female ebsIT Italian

Japanese Female ebsJP Japanese

Enhanced Basic Speech formats


EBS Version 6.0 Speaking Voice

Abbreviation Phrase Pool Name

Korean Female ebsKO Korean


Female ebsLS LA_Spanish

Malay Female ebsMA Malay

Mandarin Chinese Female ebsMD Mandarin

Polish Female ebsPL Polish

Slovak Female ebsSQ Slovak

Thai Female ebsTH Thai

United Kingdom (UK) English

Female ebsUK UK_English

United States (US) English

Female ebsUS US_English

United States (US) English

Male ebsUSM US_English

Background information

Common formats

The EBS package for each language contains the following common formats:

• D (date)

• T (time)

• N (numbers)

• N$ (currency)

• C (characters)

While common to all languages, these formats may be defined differently from language to language, as appropriate to the conventions of usage in each language. For example, T (time) is spoken as THMAM in some languages, but as TH24M in others, depending on the language specification (see "Variations on the common formats"). The definition reflects the most normal or customary manner of speaking the phrase in the language.



Variations on the common formats

The common EBS formats may be enhanced to include different ways to be spoken, depending on the language specification. The most frequently occurring variations on the common formats are listed below. However, some languages also contain other variations. (For information on inflections used in the formats, see "Inflections.")

• Date formats always start with D, and these modifiers may follow:

― YY – year spoken with four digits

― Y – year spoken with two digits

― M – month spoken as a number (rather than as a word)

― SP – month spoken as a word (rather than as a number)

― D – day (number)

― W – weekday (name)

― f – falling inflection

• Time formats always start with T, and these modifiers may follow:

― H – hour

― 24 – 24-hour clock

― M – minutes

― AM – 12-hour clock (AM/PM)


• Number formats always start with N, and these modifiers may follow:

― M – male form

― F – female form

― N – neutral form

― m (or mmm) – medial inflection

― f (or mmf) – falling inflection

― r (or rmm)-- rising inflection

― rmf – total inflection



• Decimal number formats always start with ND, and the number that follows indicates the number of decimal places after the decimal point.

The input string is assumed not to have a decimal point in it. For example, if 12345678 is input with format ND4, the number 1234.5678 is spoken.

• Currency formats always start with N$, and these modifiers may follow:

― Dx – where x indicates the number of decimal places


• Character formats always start with C, and these modifiers may follow:

― m (or mmm) – medial inflection

― f (or mmf) – falling inflection

― r (or rmm) – total inflection

― rmf – total inflection

Note: When you select a variable Type in the Spoken As column in the IVR Designer Variables Manager, by default IVR Designer automatically assigns the variable a common format (D, C, T, N, or N$). You can either accept the default or change it to one of the variations available for that common format. For example, when you select the character Type, the character variable defaults to the C format. You can then select another character format, if one is available in the language you have selected. For US English, you could select Crmf, Crmm, Cmmf, or Cmmm. See the section on variables in IVR Designer online help, for more information on defaults for formats.

Inflections

Inflection is a change in voice intonation appropriate to the context in which a speech phrase occurs. For example, typically in natural speech, rising inflection occurs in questions, medial inflection (no inflection) occurs in the middle of words and phrases, and falling inflection occurs at the end of words and phrases. The EBS package includes formats for inflections.

The EBS format tables use the following terminology to describe inflections:

• Rising inflection – The first character or number is spoken with rising inflection and all other others with medial inflection.

• Falling inflection – The last character or number is spoken with falling inflection and all others with medial inflection.

• Total inflection – The first character or number is spoken with rising inflection, the last with falling inflection, and all others with medial inflection.



Note: Unless otherwise specified, formats use medial inflection.

Grammatical gender

Words in some languages are spoken differently depending on whether they are grammatically male, female, or neutral. The EBS format tables use the terminology male form, female form, and neutral form to describe gender-specific formats.

Converting applications to other languages

An application containing EBS formats can have the formats converted to another language by changing the language option. However if the original application uses formats not available for the new language, then the converted application will not be identical. Therefore, advance planning is advisable for applications that may be converted to other languages. A recommended strategy is to create the original application using only the common formats available in all languages, create duplicate applications for the target languages, and adjust the formats on a per-application basis, if needed. (For more information, see "Common formats.")

Maximum values for numbers and currency

A variable defined as a number or as currency on the Avaya IR system has 4 bytes and can support a numeric value up to 2,147,483,647. To support larger numbers, for some languages the number and currency formats also accept inputs as characters. These character variables can handle values up to 15 digits (999,999,999,999,999) plus a decimal point and can be preceded by a minus sign (-) to indicate a negative number.

The following table distinguishes the languages that receive only number variable support from EBS for number and currency formats from the languages that also receive character variable support.



Number Variable Support Only

Character Variable Support

Australian English

Cantonese Chinese

Castilian Spanish

Dutch

German

Hindi

Indonesian

Korean

Malay

Mandarin Chinese

Thai

US English


Canadian French

Czech

French

Hungarian

Italian

Japanese


Polish

Slovak

UK English

Speaking phrase numbers and packed talkfile numbers

The NX format is a Avaya IR system feature used to speak:

• A phrase with a specified phrase tag number

• Packed talkfile numbers and phrase numbers

This format is included in the EBS tables for all supported languages.

EBS formats

The following tables provide a complete list of EBS formats by language.

Australian English EBS formats

Format Description D Date – spoken month, 2-digit day, 2-digit year

DMDYY Date – 2-digit month, day, 4-digit year

DMDY Date – 2-digit month, day, year

DMD Date – 2-digit month, day, no year

DMSPDYY Date – spoken month, 2-digit day, 4-digit year

DMSPDY Date – spoken month, 2-digit day, 2-digit year



Format Description DMSPD Date – spoken month, 2-digit day, no year

T Time – hour, minute, AM/PM

TH24M Time – hour, minute, 24-hour clock

THMAM Time – hour, minute, AM/PM

N Number – medial inflection

Nrmf Number – total inflection

Nmmf Number – falling inflection

Nrmm Number – rising inflection

Nmmm Number – medial inflection

ND Decimal number – no decimal places

This format may not be valid for IVR Designer. See the topic on variables in IVR Designer online help for specific information.

ND0 Decimal number – no decimal places

This format may not be valid for IVR Designer. See the topic on variables in IVR Designer online help for specific information.

ND1 Decimal number – 1 decimal place

ND2 Decimal number – 2 decimal places








N$ Currency – whole dollars

N$D0 Currency – whole dollars

N$D2 Currency – dollars and cents

N$D1 Currency – dollars with 1 decimal place

N$D3 Currency – dollars with 3 decimal places







Format Description N$D8 Currency – dollars with 8 decimal places


C Characters – spoken individually, medial inflection

Crmf Characters – spoken individually, total inflection

Crmm Characters – spoken individually, rising inflection

Cmmf Characters – spoken individually, falling inflection

Cmmm Characters – spoken individually, medial inflection

NX The NX format is used to speak a phrase with a specified phrase tag number, or packed talkfile numbers and phrase numbers.

Brazilian Portuguese EBS formats



DMSPDY Date – spoken month, 2-digit day, year

DMSPD Date – spoken month, 2-digit day, no year

DMSPfYY Date – same as DMSPDYY but with falling inflection

DMSPfY Date – same as DMSPDY but with falling inflection

DMSPf Date – same as DMSPD but with falling inflection




THMAMf Time – hour, minute, AM/PM, falling inflection

TH24Mf Time – hour, minute, 24-hour clock, falling inflection

N Number – total inflection

Nmf Number – falling inflection

Nrm Number – rising inflection


NM Number – male form

NF Number – female form

NN Number – neutral form




Format Description ND1 Decimal number – 1 decimal place









N$ Currency – reais and centavos

N$D2 Currency – reais and centavos







Canadian French EBS formats



DMSPDY Date – spoken month, 2-digit day and year


DMSPfYY Date – same as DMSPDYY, but with falling inflection

DMSPfY Date – same as DMSPDY, but with falling inflection

DMSPf Date – same as DMSPD, but with falling inflection

T Time – hour, minute, 24-hour clock






Format Description TH24Mf Time – hour, minute, 24-hour clock, falling inflection

TPD Time – hour, minute, 24-hour clock

THMAMPD Time – PDT (Pacific Daylight Saving Time), hour, minute, AM/PM

TH24MPD Time – PDT, hour, minute, 24-hour clock

THMAMPDf Time – PDT, hour, minute, AM/PM, falling inflection

TH24MPDf Time – PDT, 24-hour clock, falling inflection

TPS Time – hour, minute, 24-hour clock

THMAMPS Time – PST (Pacific Standard Time), hour, minute, AM/PM

TH24MPS Time – PST, hour, minute, 24-hour clock

THMAMPSf Time – PST, hour, minute AM/PM, falling inflection

TH24MPSf Time – PST, hour, minute, 24-hour clock, falling inflection

TMD Time – hour, minute, 24-hour clock

THMAMMD Time – MDT (Mountain Daylight Saving Time), hour, minute, AM/PM

N Number – total inflection







ND0 Decimal number – no decimal places, "virgule zero"










NDF6 Decimal number – 6 decimal places, decimal part spoken as number




Format Description NDF8 Decimal number – 8 decimal places, decimal part spoken as number


N$ Currency – same as N$D2

N$D2 Number – dollars and cents







Cantonese Chinese Enhanced Basic Speech formats

For United States currency the word "maygum" is spoken first to indicate United States currency.

Format Description D Date – 4-digit year, 2-digit month and day

DYMDD Date – 4-digit year, 2-digit month and day

DMD Date – month followed by day

T Time – time, period followed by time

THMAM Time – time, period followed by time

N Number – integer, medial inflection













Format Description N$ Currency – whole dollars











NYD0 Currency – whole yuan

NYD1 Currency – yuan with 1 decimal place

NYD2 Currency – yuan, miao, and seen

NYD3 Currency – yuan with 3 decimal places










Castilian Spanish Enhanced Basic Speech formats







Format Description T Time – hour, minute, AM/PM



N Number – neutral form














N$ Currency – whole pesetas

N$D0 Currency – whole pesetas

N$D2 Currency – pesetas and centimos

N$EU Currency – whole Euros

N$D0EU Currency – whole Euros

N$D2EU Currency – Euros and cents









Czech Enhanced Basic Speech formats

Format Description D Date – day, spoken month, 4-digit year

DDMSPYY Date – day, spoken month, 4-digit year

DDMYY Date – day, month, 4-digit year

DMMSP Date – day, spoken month, no year

DDM Date – day, month, no year

DDMSPYYf Date – day, spoken month, 4-digit year, falling inflection

DDMYYf Date – day, month, 4-digit year, falling inflection

DMMSPf Date – day, spoken month, no year, falling inflection

DDMf Date – day, month, no year, falling inflection



TH24MS Time – hour, minute, second, 24-hour clock

TH24Mf Time – hour, minute, falling inflection

TH24MSf Time – hour, minute, second, falling inflection

N Number – male form, medial inflection

NMm Number – male form, medial inflection

NMf Number – male form, falling inflection

NFm Number – female form, medial inflection

NFf Number – female form, falling inflection

NNm Number – neutral form, medial inflection

NNf Number – neutral form, falling inflection

ND0 Decimal number – whole number spoken as "number comma 0", no decimal places











Format Description ND9 Decimal number – 9 decimal places

NDX Decimal number – variable number of decimal places, decimal separator in argument

Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number.

NDX1 Decimal number – 1 decimal place, spoken as a fraction

NDX2 Decimal number – 2 decimal places, spoken as a fraction


NDXS Decimal number – up to 3 decimal places, spoken as a fraction; otherwise NDX

NDX0S Decimal number – up to 3 decimal places, spoken as number with leading zeros; otherwise NDX

ND0f Decimal number – whole number, spoken as "number comma 0", falling inflection

ND1f Decimal number --1 decimal place, falling inflection

ND2f Decimal number --2 decimal places, falling inflection






ND8f Decimal number – 8 decimal places, falling inflection


NDXf Decimal number – variable number of decimal places, falling inflection, decimal separator in argument

NDX1f Decimal number --1 decimal place, spoken as a fraction, falling inflection

NDX2f Decimal number – 2 decimal places, falling inflection

NDX3f Decimal number – 3 decimal places, spoken as a fraction, falling inflection

NDX0Sf Decimal number – up to 3 decimal places, spoken as a number with leading zeros; otherwise NDX

NDXSf Decimal number – up to 3 decimal places, spoken as a fraction, falling inflection; otherwise NDX

N$ Currency – whole crowns

N$D0 Currency – whole crowns



Format Description N$D2 Currency – crowns and hellers

N$DX Currency – crowns, spoken as a decimal number with a variable number of decimal places, decimal separator in argument

N$D2f Currency – crowns and hellers, falling inflection




N$DXEU Currency – Euros, spoken as a decimal number with a variable number of decimal places, decimal separator in argument

N$D2fEU Currency – Euros and cents, falling inflection


Cspd Characters – spoken individually, variable pace

Cmf Characters – spoken individually, falling inflection

Cmm Characters – spoken individually, medial inflection


Dutch EBS formats


DMSPD Date – spoken month, 2-digit day, 4-digit year

DMSPD Date – spoken month, 2-digit day, 2-digit year




N Number – same as NN













N$ Currency – whole gulden

N$D0 Currency – whole gulden

N$D2 Currency – gulden and cents










French EBS formats



DMSPDY Date --spoken month, 2-digit day and year


DMSPfYY Date – same as DMSPDYY but with falling inflection

DMSPfY Date – same as DMSPDY but with falling inflection

DMSPf Date – same as DMSPD but with falling inflection

DMSPlYY Date – same as DMSPDYY but preceded by "le"

DMSPlY Date – same as DMSPDY but preceded by "le"

DMSPl Date – same as DMSPD but preceded by "le"






Format Description N Number – total inflection







ND0 Decimal number – no decimal places, "virgule zero"










NDF0 Decimal number – no decimal place

NDF1 Decimal number – 1 decimal place, decimal part spoken as number









N$ Currency – francs and centimes

N$D2 Currency – francs and centimes

N$F Currency – whole francs

N$F0 Currency – francs with no decimal places

N$F1 Currency – francs with 1 decimal place



Format Description N$F2 Currency – francs with 2 decimal places

N$F3 Currency – francs with 3 decimal places







N$EU Currency – Euros and centimes

N$D2EU Currency – Euros and centimes

N$FEU Currency – whole Euros

N$F0EU Currency – whole Euros

N$F1EU Currency – Euros with 1 decimal place

N$F2EU Currency – Euros with 2 decimal places














German EBS formats




Format Description DMSPDYY Date – spoken month, 2-digit day, 4-digit year


DMSPD Date – spoken month, 2-digit day

T Time – 24-hour clock, no seconds

TH24M Time – 24-hour clock, no seconds








ND3 Decimal number – 3 decimal places t







N$ Currency – whole marks

N$D0 Currency – whole marks

N$D2 Currency – marks and pfennig

N$DM Currency – whole Deutsch marks

N$DM0 Currency – whole Deutsch marks

N$DM2 Currency – Deutsch marks and pfennig










Format Description Cmmm Characters – spoken individually, medial inflection


Hindi EBS formats

Format Description D Date – same as DDMSPYY

DDMSP Date – 2-digit day, spoken month

DDMSPY Date – 2-digit day, spoken month, 4-digit year

T Time – time period followed by time

THMAM Time – time period followed by time

N Number – integer, medial inflection (default)

ND0 Decimal number – no decimal place










N$ Currency – dollars and cents





N$D4 Currency – dollars with 4 digits decimal places







Format Description N$D9 Currency – dollars with 9 with decimal places

NRD0 Currency – whole rupees

NRD1 Currency – rupees with 1 decimal place

NRD2 Currency – rupees with 2 decimal places

NRD3 Currency – rupees with 3 decimal places

NDR4 Currency – rupees with 4 decimal places









Hungarian EBS formats

Format Description D Date – 4-digit year, spoken month and day

YYMSPDD Date – 4-digit year, spoken month and day

MSPDD Date – no year, spoken month and day

YYMSPDDf Date – 4-digit year, spoken month and day, falling inflection

MSPDDf Date – no year, spoken month and day, falling inflection





TH24MSf Time – hour, minute, second, 24-hour clock, falling inflection

N Number – alternate NMm format, medial inflection

NMm Number – medial inflection

NMf Number – falling inflection

NM2m Number – alternate NMm format, medial inflection



Format Description NM2f Number – alternate NMf format, falling inflection

ND0 Decimal number – whole number spoken as "number comma 0", no decimal places















NDX0S Decimal number – 3 or fewer decimal places, spoken as a whole number with padding zeros

NDXS Decimal number – 3 or fewer decimal places, spoken as a fraction; otherwise NDX

ND0f Number – whole number, spoken as "number comma 0", falling inflection

ND1f Decimal number – 1 decimal place, falling inflection











Format Description NDXf Decimal number – variable number of decimal places, spoken as a whole

number with padding zeros, falling inflection

NDX1f Decimal number – 1 decimal place, spoken as a fraction, falling inflection



NDXSf Decimal number – 3 or fewer decimal places, spoken as a fraction, falling inflection; otherwise NDX

NDX0Sf Decimal number – 3 or fewer decimal places, spoken as a fraction, falling inflection; otherwise NDX

N$ Currency – whole forints

N$D0 Currency – whole forints

N$D2 Currency – forints and filers

N$DX Currency – forints as a decimal number, variable number of decimal places


Cspd Characters – spoken individually, variable pace




Indonesian Enhanced Basic Speech formats

Format Description N Number – integer, medial inflection (default)



ND2 Decimal number – 2 decimal places, numbers after decimal point spoken digit-by-digit

ND2W Decimal number – 2 digits after decimal point spoken as number










D Date – spoken month, 2-digit day, 4-digit year




TH24M Time – hour, minute, 24 hour clocks

N$ Currency – whole Indonesian rupiah

N$R Currency – whole Indonesian rupiah

N$D0 Currency – whole US dollars

N$D2 Currency – US dollars and cents

C Characters – Indonesian, spoken individually, medial inflection

Cm Characters – English, spoken individually, medial inflection

Cf Characters – English, spoken individually, falling inflection

Cr Characters – English, spoken individually, rising inflection

CIm Characters – Indonesian, spoken individually, medial inflection

CIf Characters – Indonesian, spoken individually, falling inflection

CIr Characters – Indonesian, spoken individually, rising inflection


Italian Enhanced Basic Speech formats

Format Description D Date – same as DDMSPYY but with falling inflection


DDMSPY Date – day, spoken month, 2-digit year

DDMSP Date – spoken month, 2-digit day, no year

DDMSPYYf Date – same as DDMSPYY but with falling inflection

DDMSPYf Date – same as DDMSPY but with falling inflection

DDMSPf Date – same as DDMSP but with falling inflection

T Time – hour, minute, 24-hour clock, falling inflection




Format Description TH24M Time – hour, minute, 24-hour clock



N Number – rising inflection




NN Number – "uno"

NF Number – "una"

NM Number – "un"











N$ Currency – lire, medial inflection (default)

N$f Currency – lire, falling inflection

N$EU Currency – Euros and cents, medial inflection

N$fEU Currency – Euros and cents, falling inflection









Japanese Enhanced Basic Speech formats

Format Description D Date – spoken 4-digit year, month, and day

DSPYYMD Date – spoken 4-digit year, month, and day

DSPYYMDW

Date – spoken 4-digit year, month, day, and day of the week

DSPYMD Date – last 2 digits of year spoken, month, and day

DSPYMDW Date – last 2 digits of year spoken, month, day, and day of the week

DSPMD Date – spoken month and day

DSPMDW Date – spoken month, day, and day of the week



N Number – integer, total inflection (default)











N$ Currency – whole yen (default)

N$D2 Currency – yen, 2 decimal places



Korean Enhanced Basic Speech formats

Format Description D Date – 4-digit year, month, day

DYYMD Date – 4-digit year, month, day




Format Description T Time – time period followed by time

TAMHM Time – time period followed by time

N Number – integer, cardinal number (default)

NT Number – ordinal






















NW Currency – whole won






Latin-American Spanish EBS formats



DMSPDY Date – spoken month, 2-digit day, 2-digit year

DMSPD Date – spoken month, 2-digit day



TH24M Time --hour, minute, 24-hour clock















C Character – spoken individually (default)

N$ Currency – whole pesos

N$D0 Currency – whole pesos

N$D2 Currency – pesos and centavos

NDOL$ Currency – whole dollars

NDOL$D0 Currency – whole dollars

NDOL$D2 Currency – dollars and centavos

NPN$ Currency – whole pesos nuevos

NPN$D0 Currency – whole pesos nuevos

NPN$D2 Currency – pesos nuevos and centavos



Format Description NCOL$ Currency – whole colones

NCOL$D0 Currency – whole colones

NCOL$D2 Currency – colones and centavos

NSUC$ Currency – whole sucres

NSUC$D0 Currency – whole sucres

NSUC$D2 Currency – sucres and centavos

NQUE$ Currency – whole quetzales

NQUE$D0 Currency – whole quetzales

NQUE$D2 Currency – quetzales and centavos

NLEM$ Currency – whole lempiras

NLEM$D0 Currency – whole lempiras

NLEM$D2 Currency – lempiras and centavos

NCOR$ Currency – whole cordobas

NCOR$D0 Currency – whole cordobas

NCOR$D2 Currency – cordobas and centavos

NGUA$ Currency – whole guaranis

NGUA$D0 Currency – whole guaranis

NGUA$D2 Currency – guaranis and centimos

NSOL$ Currency – whole soles

NSOL$D0 Currency – whole soles

NSOL$D2 Currency – soles and centavos

NBOL$ Currency – whole bolivares

NBOL$D0 Currency – whole bolivares

NBOL$D2 Currency – bolivares and centimos

NPTA$ Currency – whole pesetas

NPTA$D0 Currency – whole pesetas

NPTA$D2 Currency – pesetas and centimos




Malay Enhanced Basic Speech formats






N Number – integer (default)




ND2W Decimal number – 2 digits after decimal point spoken as number








N$ Currency – whole Malaysian ringgits

N$R Currency – whole Malaysian ringgits

N$R2 Currency – Malaysian ringgits and cents



C Characters – English, spoken individually, medial inflection




CIm Characters – English, spoken individually, medial inflection




Mandarin Chinese Enhanced Basic Speech formats

Format Description D Date – 4-digit year, month and day

DYYMD Date – 4-digit year, month and day


DTWYYMD Date – 4-digit year per Taiwanese Republic calendar, month, day


THMAM Time – hour, minute, 24-hour clock

N Number – integer, with digit 2 spoken as "ur" (default)

N2 Number – integer, with digit 2 spoken as "lyang"











N$ Currency – whole yuan











NYD0 Currency – whole yuan

NYD1 Currency – yuan with 1 decimal place



Format Description NYD2 Currency – yuan, chiao, and fun








NQD0 Currency – whole quai

NQD1 Currency – quai with 1 decimal place

NQD2 Currency – quai with 2 decimal places








C Characters – spoken individually

Cmmm Characters – spoken individually


Polish EBS formats





DMMSPf Date – day and month, no year, falling inflection

T Time – hour and minute as numbers, 24-hour clock

TH24M Time – hour and minute as numbers, 24-hour clock



Format Description TSPH24M Time – spoken hour and minute, 24-hour clock

TSPH24MS Time – spoken hour, minute, and second, 24-hour clock

TOH24M Time – hour and minute in form "at time"

TH24Mf Time – hour and minute as numbers, falling inflection

TSPH24Mf Time – spoken hour and minute, falling inflection

TSPH24MSf Time – spoken hour, minute, and second, falling inflection

TOH24Mf Time – hour and minute in form "at time," falling inflection

N Number – up to 1 billion, male form, medial inflection

NMm Number – up to 1 billion, male form, medial inflection

NMf Number – up to 1 billion, male form, falling inflection

NFm Number – up to 1 billion, female form, medial inflection

NFf Number – up to 1 billion, female form, falling inflection

NNm Number – up to 1 billion, neutral form, medial inflection

NNf Number – up to 1 billion, neutral form, falling inflection

ND0 Decimal number – whole number spoken as "number comma 0"

















Format Description NDX0S Decimal number – 3 or fewer decimal places, spoken as a number with

leading zeros; otherwise NDX

NDXS Decimal number – 3 or fewer decimal places, spoken as a fraction; otherwise NDX

ND0f Decimal number – whole number spoken as "number comma 0", falling inflection


ND2f Decimal number --- 2 decimal places, falling inflection










NDX3f Number – 3 decimal places, spoken as a fraction, falling inflection


Note: A number passed to a function can contain either a period (.) or a comma (,) to identify a number of decimal digits spoken for that number)

NDX0Sf Decimal number – 3 or fewer decimal places, spoken as number with leading zeros; otherwise NDX


N$ Currency – zlote and grosze, up to 1 billion, falling inflection

N$D0 Currency – whole zlote, up to 1 billion, medial inflection)

N$D2 Currency – zlote and grosze, up to 1 billion, medial inflection

N$D2f Currency – zlote and grosze, up to 1 billion, falling inflection

N$DX Currency – zlote, up to 1 billion, decimal form

N$EU Currency – Euros and cents, up to 1 billion, falling inflection

N$D0EU Currency – Euros, up to 1 billion, medial inflection

N$D2EU Currency – Euros and cents, up to 1 billion, medial inflection



Format Description N$D2fEU Currency – Euros and cents, up to 1 billion, falling inflection

N$DXEU Currency – Euros, up to 1 billion, decimal form

C Characters – spoken individually, falling inflection

Cspd Characters – spoken individually, variable pace, medial inflection




Slovak EBS formats



DDMYY Date – day, month, 4-digit year


DDM Date – day, month, no year


DDMYYf Date – day, month, 4-digit year, falling inflection

DMMSPf Date – day, spoken month, falling inflection

DDMf Date – day, month, falling inflection




TH24Mf Time – hour, minute, falling inflection

TH24MSf Time – hour, minute, second, falling inflection

N Number – male form, medial inflection

NMm Number – male form, medial inflection

NMLm Number – male form, for animate subjects, medial inflection

NMf Number – male form, falling inflection

NMLf Number – male form, for animate subjects, falling inflection

NFm Number – female form, medial inflection

NFf Number – female form, falling inflection



Format Description NNm Number – neutral form, medial inflection

NNf Number – neutral form, falling inflection

ND0 Decimal number – whole number spoken as "number comma 0"










NDX1 Decimal number-- 1 decimal place, spoken as a fraction





NDXS Decimal number – 3 or fewer decimal places spoken as fraction, falling inflection; otherwise NDX

ND0f Decimal number – whole number spoken as "number comma 0", falling inflection













Format Description NDX2f Decimal number – 2 decimal places, spoken as a fraction, falling inflection





N$ Currency – whole crowns

N$D0 Currency – whole crowns

N$D2 Currency – crowns and hellers

N$DX Currency – crowns spoken as a decimal number, variable number of decimal places




N$DXEU Currency – Euros as decimal number with a variable number of decimal places





Thai EBS formats

Format Description D Date – Buddha year, spoken as a whole number

DWY Date – Western year, spoken as a whole number

DWYD Date – Western year, spoken digit by digit

DWYS Date – Western year, spoken in short form

DBY Date – Buddha year, spoken as a whole number

DBYD Date – Buddha year, spoken digit by digit

DBYS Date – Buddha year, spoken in short form



Format Description T Time – hour, minute, AM/PM



N Number – integer (default)











N$ Currency – whole Thai baht

N$T0 Currency – whole Thai baht

N$T2 Currency – Thai baht and satang



C Characters – English, spoken individually, medial inflection





UK English EBS formats

Format Description D Date – day, month, 4-digit year

DDMSP Date – day and month

DDMSPY Date – day, month, 2-digit year

DDMSPYY Date – day, month, 4-digit year



Format Description DDMSPf Date – day and month, falling inflection

DDMSPYf Date – day, month, 2-digit year, falling inflection

DDMSPYYf Date – day, month, 4-digit year, falling inflection

DDMSPO Date – "on" day, month

DDMSPYO Date – "on" day, month, 2-digit year

DDMSPYYO Date – "on" day, month, 4-digit year

DDMSPOf Date – "on" day, month, falling inflection

DDMSPYOf Date – "on" day, month, 2-digit year, falling inflection

DDMSPYYOf

Date – "on" day, month, 4-digit year, falling inflection

DMDYY Date – same as DDMSPYY

DMDY Date – same as DDMSPY

DMD Date – same as DDMSP

DMSPDYY Date – same as DDMSPYY

DMSPDY Date – same as DDMSPY

DMSPD Date – same as DDMSP




THM24 Time – hour, minute, 24-hour clock

THM24f Time – hour, minute, 24-hour clock, falling inflection

N Number – integer, rising inflection

Nrmf Number – integer, total inflection

Nrmm Number – integer, rising inflection

Nmmf Number – integer, rising inflection

Nmmm Number – integer, rising inflection

ND Decimal number – no decimal places


ND1 Decimal number – one decimal place

ND2 Decimal number – two decimal places

ND3 Decimal number – three decimal places

ND4 Decimal number – four decimal places



Format Description ND5 Decimal number – five decimal places

ND6 Decimal number – six decimal places

ND7 Decimal number – seven decimal places

ND8 Decimal number – eight decimal places

ND9 Decimal number – nine decimal places

N$ Currency – pounds and pence, medial inflection

N$f Currency – pounds and pence, falling inflection

N$EU Currency – Euros and cents, medial inflection

N$fEU Currency – Euros and cents, falling inflection

N$D0 Currency – pounds

N$D1 Currency – pounds with one decimal place

N$D2 Currency – pounds with two decimal places

N$D3 Currency – pounds with three decimal places

N$D4 Currency – pounds with four decimal places

N$D5 Currency – pounds with five decimal places

N$D6 Currency – pounds with six decimal places

N$D7 Currency – pounds with seven decimal places

N$D8 Currency – pounds with eight decimal places

N$D9 Currency – pounds with nine decimal places




Crmf Characters – spoken individually, falling inflection

Crmm Characters – spoken individually, medial inflection

US English EBS formats

Format Description D Date – spoken month, ordinal day, 2-digit year

DMDY Date – 2-digit month, day, year

DMDYY Date – 2-digit month, day, 4-digit year

DMD Date – 2-digit month, day

DMSPDYY Date – spoken month, ordinal day, 4-digit year



Format Description DMSPDY Date – spoken month, ordinal day, 2-digit year

DMSPD Date – spoken month, ordinal day



N Number – same as Nmmm


Nmmf Number – falling inflection

Nrmm Number – rising inflection

Nmmm Number – medial inflection

ND Decimal number – no decimal place








ND7 Decimal number – 7 decimal places,






N$D2 Currency – dollars "and" cents











Format Description Crmf Characters – spoken individually, total inflection






Designing applications that use ASAI

Access to ASAI capabilities is provided through IVR Designer external functions. Subsets of the Notification, Third Party Call Control, and Routing capabilities of ASAI are integrated into these external functions.

Note: The Avaya IR system ASAI feature does not provide access to the Set Value, Value Query, Request Feature, and Third Party Domain Control capabilities of ASAI. The Request Feature capability, however, is used internally by the Avaya IR system ASAI feature to log channels in and out of an ACD split on the DEFINITY G3 switch.



ASAI application types The capabilities provided by the ASAI feature support three classes of applications:

• Voice response applications

• Routing applications

• Data screen delivery applications

These classes of applications can all run simultaneously on a Avaya IR system. This implies that a Avaya IR ASAI system provides coresident voice response and DEFINITY G3 switch-to-host gateway capabilities. A single call, for instance, can first be routed by the Avaya IR system, handled with a voice response application on the Avaya IR system, and then be monitored by the same system as the call is ultimately delivered to a live agent. Furthermore, integration of the voice response and gateway capabilities allows agents to interact with callers based on the data collected in a voice response application through a host screen. The delivery of a data screen to an operator that contains information about the incoming caller is called a screen pop.

ASAI voice response applications

In voice response applications using the ASAI feature, incoming calls can be routed to the Avaya IR system over telephony channels via an ACD split on the DEFINITY G3 switch.

As a call is delivered to the Avaya IR system, it receives ASAI information related to the call through the Ethernet LAN circuit card in the Avaya IR system. ASAI allows it to receive the DNIS and/or ANI information of an incoming call to a telephony line over this D-channel. The DNIS and ANI information can be used to control the voice application used for the call. The ASAI information related to the call is made available to the specific voice application that interacts with the caller. In addition, the call control capabilities of ASAI can be used to transfer the call away from the Avaya IR system if the caller needs to speak to a live agent. The ASAI feature provides the following for voice response applications:

• Channel sharing – The DNIS and/or ANI information associated with the incoming call is used to select a particular IVR Designer application to service the call. This allows telephony ports to be shared across many applications. With port sharing, the same number of ports can handle more calls while maintaining the same grade of service. Alternatively, the same number of calls can be handled at a higher grade of service.

• ANI service – Providing this service allows applications to be customized according to the calling party number or a range of numbers, for example, an area code.

• Call information – Once the call is answered by the Avaya IR system, the ASAI information related to the call (such as ANI and DNIS) can be retrieved for use in the voice application that is handling the call.

ASAI application types


• Enhanced transfer – The use of ASAI call control capabilities allows the transfer to be faster, quieter from the caller's perspective, and more reliable. In addition, the G3 ASAI feature of direct agent calling can be used to transfer the call. This allows the call to be delivered to a specific agent while maintaining accurate ACD split statistics. Calls placed to specific agents without the direct agent calling feature do not count as ACD calls in calculating and reporting ACD split statistics. Finally, data that is captured in the voice application can be saved and associated with the transferred call. This enables a host application to deliver data screens to agents that are based on data collected by the voice application that previously serviced the caller and any combination of ANI and/or DNIS information. See "Data screen delivery applications" for more information. The availability of ANI for application selection or within the voice application permits the design of unique voice response applications. Examples include:

― Locator service. A local or host database can be used to determine the closest car dealers, ATMs, stores, and so on.

― Weather reports. A weather report for the caller's area can be provided.

― Pay-per-view. A cable company can use ANI to automate customer selection and billing of pay-per-view programs.

― Caller-dependent transfers. The full 10-digit ANI can be used to identify callers and determine where they should be transferred if they need to speak to a live agent. This is desirable if, for instance, the caller is a preferred customer or is usually handled by a specific agent.

― Geographically based call transfers. The area code and/or exchange can be used to determine where callers should be transferred if they need to speak to a live agent. This is desirable if, for instance, agents handle calls from specific geographic regions.

Routing applications

In routing applications using the ASAI feature, the Avaya IR system is used as a routing server to support the routing capabilities of ASAI and the call vectoring feature on the DEFINITY G3 switch. The DEFINITY G3 switch generates these call-routing requests when a call is processed by specific call vectors on the switch.

Information as to where to route calls can reside on the Avaya IR system in a local database or can be provided by a host to which the Avaya IR system is connected. Call routing is typically based on ANI or call-prompting data collected by the DEFINITY G3 switch.

The use of routing capabilities can significantly improve the efficiency of a call center as shown in the following examples:

• Priority service – Important or "priority" callers such as major clients can be routed to a common agent group but queued at a higher priority so that they are serviced faster. These callers can also be routed to the specific agent who normally handles their transactions.



• Call redirection – Callers dialing into a particular call center application can be redirected to other call center applications. For example, callers who have delinquent accounts can be redirected to a collections department when they call a sales department.

• Call screening – Fraudulent callers can be disconnected before being connected to an agent so that no network costs are incurred and no agent time is wasted.

• Geographically-based service – Where service is provided on a regional basis, callers can be routed to the agent group that is responsible for their region.

Data screen delivery applications

In data screen delivery applications, an application that resides on the host delivers a specified data screen related to a caller or dialed number to an agent at the same time that a voice call is delivered to the agent's telephone. This reduces both the agent time and network time required to service the caller.

Note that the delivery of data screens is not a function of the Avaya IR system itself. The system acts only as a communications gateway between the DEFINITY G3 switch and the host computer. A monitoring application on the Avaya IR system provides the ability to track the status of calls on the switch. This monitoring application receives information about calls delivered to live agents and forwards this information to the application on the host. The host application in turn uses this information to deliver a data screen to the agent receiving the call.

The information made available to the host includes which agent receives a particular call and the ASAI information associated with the call, such as ANI, DNIS, and any DEFINITY G3 switch call-prompting information collected from the caller. In addition, the call may have been serviced by a Avaya IR system voice application and then transferred to a live agent. In this case, information collected in the voice application can be saved and passed to the host at the time the call is delivered to the agent. Monitoring applications on the Avaya IR system can therefore be used to support data screen delivery for three different call-flow scenarios:

• Avaya IR system-to-agent transfers – In this scenario, calls are delivered to the system and then transferred to a live agent. As described previously, data screens delivered to agents in this scenario can be based on information collected in a voice application in addition to ASAI information such as ANI and DNIS and call-prompting information collected by the DEFINITY G3 switch.

• Incoming call directly to agent – In this scenario, incoming trunk calls are delivered directly to live agents. Data screens delivered to agents are based primarily on ANI and DNIS and/or call-prompting information. Data screens are not based on data collected in a voice application, since a voice application is not used to collect data from the caller.

• Agent-to-agent transfers – In this scenario, calls are transferred between live agents. Here, for example, "screening" agents can be used to collect information from the caller and handle simple transactions. The call can subsequently be transferred to "specialized" agents to handle more complex or detailed transactions. In these scenarios, data screens can be based on information keyed in to the host application by live agents. The host

ASAI application types


application can save data collected and entered by a screening agent and then use this data as the basis for data screens delivered to specialized agents who can receive the call. Note that the information available for the other two scenarios (that is, ANI, DNIS, call-prompting information, and voice-application data) is also available in this scenario. This information can be used in conjunction with data entered by a live agent to provide the basis for data screens.

Note: You must plan your call flows carefully if you are using multiple ASAI adjuncts with the same DEFINITY G3 switch. Once a call is monitored by a particular Avaya IR system, the call cannot be redirected or transferred to a domain that is monitored by another system or ASAI adjunct. This is a consideration primarily for data screen delivery applications. For example, if you have agent-to-agent transfers for data screen delivery applications, agents must restrict transfers to domains monitored by the same Avaya IR system that monitors calls delivered to them. Also, for example, you might have Avaya IR system-to-agent transfers to support data screen delivery based on data collected by the Avaya IR system. In this case, you should configure multiple Avaya IR systems to "front end" mutually exclusive sets of live agents. These considerations do not apply if you are using only one Avaya IR ASAI system and it is the only ASAI adjunct.

The Avaya IR system-to-agent transfer scenario described above is supported using the enhanced-transfer capability provided for ASAI voice-response applications. The enhanced-transfer capability allows data collected in the voice application to be saved and associated with the transferred call. Data saved in this fashion can be included in the call-event information that is passed to the host at the time the transferred call is delivered to an agent.

The ability to save voice application data is useful in many ways. A voice application can be used to collect a variety of information such as account number, social security number, personal identification number, desired service, and so on. In many cases, this type of information is more useful than ASAI information such as ANI to both the host application and the live agents handling calls.

The ability to save voice application data with the enhanced transfer capability provides a useful bridge between voice response and data screen delivery applications. It provides true integration (in addition to coresidency) of the voice response and switch-to-host gateway capabilities offered with the Avaya IR system's ASAI feature. This mechanism for embedding voice application data in call event information for the transferred call can significantly reduce the complexity of the host application. Without this mechanism, the host application is typically required to associate information from two different physical interfaces (one interface from the voice response unit to receive data collected from the caller and another interface from the monitoring device over which call events are received). Also, the host application is typically required to track and associate multiple events for multiple calls (the initial incoming call to the voice response unit and the second, transferred call that is delivered to an agent). With the ASAI feature, a single message to the host over a single interface provides all the information needed to deliver a data screen based on data collected in a voice application.



ASAI versus the converse vector step The Converse Vector Step (CVS) allows the switch to maintain control of a call while capabilities of the Avaya IR system are being used. Whether to use ASAI or the CVS depends on several factors, including cost, traffic, and desired functionality. For example, the CVS feature, used in an application, could support a low-cost ANI routing application. Large volumes of traffic may require an ASAI-based solution due to the more efficient ASAI adjunct routing. See Converse vector step routing on page 185, for more information about the CVS.

The following provides a list of the capabilities and limitations of using the two features on telephony lines.

• Both ASAI and CVS provide the delivery of ANI, DNIS, and switch call prompting digits for calls. The CVS provides this information on an in-band basis while ASAI makes the data available on an out-of-band basis. The ASAI out-of-band exchange of data is faster.

Note: CVS allows a maximum of two parameters to be delivered.

• The Avaya IR system ASAI actions A_Event and A_RouteSel can be used in monitoring and routing applications even if the calls are delivered via the CVS.

In addition, both ASAI and the CVS have some unique properties that may influence the decision as to which feature to use:

• ASAI properties

― When the Avaya IR system is used as a gateway for switch-to-host applications, the A_Tran external function simplifies call-flow development using screen pops based on data collected by the Avaya IR system.

― Dynamic port allocation is simpler because ANI and DNIS service administration is supported.

• CVS properties

― CVS allows a call to remain in a live agent queue while interacting with the Avaya IR system.

― Queue position and administered digit string can be passed to the Avaya IR system using the CVS. Queue position could be used as the basis for an anticipated delay announcement. An administered digit string could be used to identify specific annoucements to be played to callers.

Avaya Interactive Response system application design



The Avaya IR system ASAI feature provides four additional IVR Designer external functions that are used to access ASAI capabilities.

• A_Callinfo – This external function is used within a voice response application to retrieve ASAI information about a call delivered to a telephony channel, for example, calling party number (ANI) and called party number (DNIS) for the call. This external function therefore provides access to the Notification capability of ASAI for calls delivered to the Avaya IR system.

• A_Event – This external function is used within routing applications to receive information about call routing requests sent by the DEFINITY G3 switch. This external function is also used in monitoring applications to receive information about calls delivered to an ACD agent. This external function therefore serves a dual role by providing access to both the Routing and Notification capabilities of ASAI.

• A_RouteSel – This external function is used within routing applications to respond to call-routing requests previously received via the use of the A_Event external function. This external function therefore provides access to the Routing capability of ASAI and allows the Avaya IR system to send ASAI call routing information to the switch.

• A_Tran – This external function is used within a voice response application to transfer a call away from a telephony channel on the Avaya IR system. This external function makes use of the Third Party Call Control capability of ASAI to effect the transfer.

ASAI voice application design

ASAI voice response applications are designed using the A_Callinfo and A_Tran external functions within voice response applications. Other standard IVR Designer nodes are also used in the voice application to answer the call, greet the caller, collect data, and so on.

The A_Callinfo and A_Tran external functions are used only in applications that handle calls delivered to an Avaya IR system telephony channel. These two external functions are not used in routing and monitoring applications where, in contrast to voice applications, a call is not present at a telephony channel.

For ASAI voice response applications, incoming calls are routed to the Avaya IR system over telephony channels configured either as extensions in an ACD split or as agent ID's under a VDN in an EAS environment on the DEFINITY G3 switch. The Avaya IR system uses the Notification capability of ASAI to monitor the ACD split or VDN. As a call is offered, the Avaya IR system receives event reports indicating the status of the call, for example, call offered, queued, alerting, and connected event reports. The Avaya IR system uses the information contained in these event reports to provide the following capabilities:



• DNIS and ANI service – The DNIS and/or ANI information associated with the incoming call is used to select a particular IVR Designer application to service the call. A unique dialed number can be provided for each unique voice response application. Each dialed number is typically represented by a unique VDN on the DEFINITY G3 switch. Calls to these different VDNs can be routed to the same Avaya IR system. The DNIS and/or ANI information associated with an incoming call is then used to select a particular application. An administrative screen on the Avaya IR system allows the different dialed numbers to be associated with a specific voice response application. This allows telephony channels to be shared across many applications. Prior to this capability, channels had to be dedicated to specific IVR Designer applications.

• Call information – Once the Avaya IR system answers the call, the ASAI information related to the call can be retrieved for use in the voice application that is handling the call. In particular, the A_Callinfo external function can be used to obtain ANI, DNIS, switch-collected user data (call prompting digits), call ID, and incoming trunk group ID if ANI is not available.

A user designing a voice application need not be concerned with processing the individual, lower-level ASAI event reports for incoming calls to the Avaya IR system. Rather, special software is provided as part of the ASAI feature. This software processes the event reports and stores the information contained in these reports on a per-call basis. The DNIS and/or ANI information associated with a call is used to start a specific voice application on the channel that receives the call. The A_Callinfo external function can then be used within the application to retrieve this information and use it in subsequent IVR Designer nodes.

A subset of the Third Party Call Control capability of ASAI is also supported for ASAI voice response applications. In particular, the A_Tran external function uses Third Party Call Control to transfer a call away from the telephony channel.

The use of the A_Tran external function within a voice response application invokes the Third Party Call Control operations of third-party take control, third-party hold, third-party make call, and third-party merge. This sequence of ASAI operations invoked with A_Tran effects a transfer of the incoming call to the destination specified with the Destination Number field in A_Tran. Hence, the application designer is not required to program many individual ASAI operations. The use of a single external function effects the transfer.

Standard switch-hook-flash transfers are still possible when the ASAI feature is used. The use of A_Tran, however, provides three significant enhancements over existing transfer mechanisms:

• Transfers are faster, quieter from the caller's perspective, and more reliable since third-party call control is used rather than the standard switch-hook-flash mechanism.

• The transfer can be completed using direct agent calling. This is done by setting the Destination Number field in A_Tran to the desired agent extension and by setting the Split Extension field to the ACD split logged into by the agent. Direct agent calling allows the transfer to be completed to a specific agent while maintaining accurate ACD split measurements. The DEFINITY G3 switch direct agent calling feature can only be invoked via ASAI.



• Information captured in the voice application can be saved for subsequent use in a data screen delivery application. Information assigned to the Avaya IR system Data field of A_Tran is saved by the Avaya IR system even after the voice application terminates. The Avaya IR system associates this data with the transferred call and makes this data available in call events passed to the monitoring application that monitors the transferred call.

The third enhancement is very useful for data screen delivery applications where the screens delivered to agents are based on data collected by the Avaya IR system. Since data collected in a voice application can be saved and is included in call events that are made available to the monitoring application, the host application is simplified. For instance, a CONNECT event (described later) that is made available to the monitoring application contains both the extension of the agent receiving the transferred call and the Avaya IR system data that was saved from the voice application that previously serviced the caller. This single event is then passed to the host, thereby providing all information needed by the host application in a single message.

Routing application design

Routing applications make use of the routing capability supported by ASAI and the call-vectoring feature on the DEFINITY G3 switch. In routing scenarios, calls are not physically delivered to telephony channels on the Avaya IR system. Instead, incoming calls to the DEFINITY G3 switch are directed to a vector containing an adjunct route step. The adjunct route step causes a route request message to be sent to the Avaya IR system. The route request message contains information pertaining to the call, for example, ANI. The Avaya IR system uses this information to determine where to route the call.

After the Avaya IR system determines where to route the call, a route select message is sent back to the DEFINITY G3 switch. The route select message contains a destination address provided by the Avaya IR system that the DEFINITY G3 switch uses to further direct the call. In routing scenarios, the Avaya IR system can be viewed as a routing server which the DEFINITY G3 switch calls upon to route calls processed with a routing vector.

Note that as a result of routing, the call might be directed to an Avaya IR system to collect more information from the caller. This would be the case, for example, if the information contained in the route request is not sufficient to identify the caller, for example, ANI not recognized.

Routing applications on the Avaya IR system are supported through the use of routing applications that are designed using the A_Event and A_RouteSel external functions. The A_Event external function is used to bring information contained in a route-request message that is sent by the DEFINITY G3 switch up to the application level. The A_Event external function returns a ROUTE REQUEST event when the DEFINITY G3 switch sends such a message. If no route-request messages are sent, the A_Event external function waits until it receives one. When a ROUTE REQUEST event is made available to the application, it reflects information in an ASAI route-request message sent by the DEFINITY G3 switch. Note that the A_Event external function is also used within monitoring applications to retrieve other types of events as discussed later.



Once a ROUTE REQUEST event is received in a application and the application determines where the call should be routed, the A_RouteSel external function is used to cause a route-select message to be passed back to the DEFINITY G3 switch. This in turn causes the call to be routed to the desired destination. Unlike voice response applications, routing applications are not associated with a particular call. A single routing application handles route requests for many calls. A routing application is designed to receive and process ROUTE REQUEST events. Because these events are controlled by vector processing on the DEFINITY G3 switch, they can arrive at any point in time. Hence, the primary difference between routing applications and voice response applications is that once they are activated, routing applications run continuously. Routing applications, therefore, have the following general structure:

1. An A_Event external function to wait for and retrieve a ROUTE REQUEST event from lower-level ASAI software on the Avaya IR system. Once the A_Event external function retrieves a ROUTE REQUEST event, the actions below are executed.

2. Other IVR Designer nodes that make use of the data made available in the ROUTE REQUEST event to determine where to route the call. Examples include read table and get/send host screen nodes to retrieve routing information from a local or host database.

3. An A_RouteSel external function to pass the routing information (that is, desired destination) from the application to lower-level ASAI software on the Avaya IR system. This causes an ASAI route-select message containing the routing information to be sent to the DEFINITY G3 switch.

A routing application can use any of the information returned in the ROUTE REQUEST event. Examples include the called-party number (for example, DNIS), calling party number (for example, ANI), and switch data (that is, call prompting information). Any one or combination of the data items returned in a ROUTE REQUEST event can be used as the basis for a routing decision.

The call is routed to the destination that is supplied in the Destination Number field of A_RouteSel. The destination can be on-switch (for example, station, ACD split, or VDN) or off-switch (for example, Direct Distance Dialing [DDD] number). Also, the call can be routed to a specific agent within an ACD split (direct agent routing). To do this, set the Destination Number field in A_RouteSel to the desired agent extension and the Split Extension field to the split logged into by the agent. Direct-agent routing is the preferred way to route calls to specific ACD agents since direct-agent calls are included in the calculations for ACD split statistics, for example, average speed of answer.

Monitoring application design

Monitoring applications on the Avaya IR system are used to support data screen delivery applications. The Notification capability of ASAI is used to track the progress of calls that are delivered to agents. A monitoring application on the Avaya IR system receives information about these calls and forwards this information to a host application. The host application in turn uses the information to format a data screen that is presented to agents receiving calls. Note, therefore, that the delivery of data screens is not a function of the Avaya IR system itself.



In data screen delivery applications, calls are not physically delivered to a telephony channel on the Avaya IR system. Rather, calls are delivered to ACD agents on the DEFINITY G3 switch. Note, however, that a call may have previously been delivered to a telephony channel to collect information from the caller.

Events

Use the A_Event external function to design a monitoring application. When used in monitoring applications, the A_Event external function returns the following types of call events:

• CONNECT Event – This event indicates that a monitored call is being delivered to an agent.

• ABANDON Event – This event indicates that a monitored call has been abandoned. ABANDON events are passed to a application whenever a caller hangs up before being connected to an agent.

• END Event – This event indicates that a monitored call has ended normally, that is, not abandoned.

The three call event types passed to a monitoring application reflect information contained in ASAI event reports for the call.

General structure

Unlike voice response applications, monitoring applications are not associated with a particular call. A single monitoring application handles call events for all of the calls that are delivered to a particular domain. A monitoring application is designed to receive and process call events that can arrive at any point in time as determined by how and when calls progress on the DEFINITY G3 switch. Hence, the primary difference between monitoring applications and voice response applications is that once activated, monitoring applications run continuously. Monitoring applications, therefore, have the following general structure:

1. An A_Event external function to wait for and retrieve a call event from lower-level ASAI software on the Avaya IR system. Once the A_Event external function retrieves a call event, the actions below are executed.

2. Other IVR Designer nodes are used to pass data to a host. Examples include get/send host screen nodes to send the data to an IBM host via the standard 3270 interface and a custom external function to pass the data to a custom DIP supporting an asynchronous interface.

A monitoring application can pass any combination of the three call-event types to a host. In addition, any combination of the data elements returned in a specific call event can be passed to a host. Examples include the called party number (for example, DNIS), calling party number (for example, ANI), and switch data (that is, call prompting information).



If you make changes to an existing monitoring application or add a new monitoring application, you must do one of the following:

1. Disable and then reenable the domain.

2. Stop and restart the voice system to activate the new application.

Call-flow scenarios

Monitoring applications on the Avaya IR system can be used to support data screen delivery for the following three different call-flow scenarios:

• Avaya IR system-to-agent transfers – In this scenario, calls are initially delivered to the system and then transferred from the Avaya IR system to a live agent. The transferred call can be monitored with a VDN type or ACD type of monitoring application if the call is transferred to a monitored VDN or ACD split domain. The transferred call can also be monitored with a CTL type of monitoring application that allows the call to be transferred to a nonmonitored domain or individual station. If the Data field of A_Tran was used to save voice application data, this data is made available in the Avaya IR system Data field of call events that are sent to the monitoring application. Hence, data screens that are delivered to agents in this scenario can be based on information that is collected in a voice application in addition to ASAI information such as ANI, DNIS, and call-prompting information that is collected by the DEFINITY G3 switch.

• Incoming call directly to agent – In this scenario, monitored VDNs or ACD splits deliver incoming trunk calls directly to live agents. Here, call events are passed to a VDN type or ACD type of monitoring application and contain only ASAI-related information such as ANI, DNIS, and/or call-prompting information. Data screens are not based on data that is collected in a voice application since a Avaya IR system voice application is not used to collect data from the caller. Since the Avaya IR system does not service calls in this scenario, no data is present in the Avaya IR system Data field of call events.

• Agent-to-agent transfers – In this scenario, calls are transferred between live agents. For example, screening agents can be used to collect information from the caller and handle simple transactions. The call can subsequently be transferred to specialized agents who can handle more complex or detailed transactions. In these scenarios, data screens can be based on information that is keyed in to the host application by live agents. The host application can save the data that is collected and entered by a screening agent and then use this data as the basis for data screens that are delivered to other, specialized agents who can receive the call. The agent-to-agent transfer can be placed to a monitored domain or to an individual station and monitored with a VDN type or ACD type of monitoring application. Note that the call might have first been delivered to the Avaya IR system and then transferred to an agent prior to the live agent-to-agent transfer. Hence, call events passed to the monitoring application in this scenario can contain the same information that is available for the other two call-flow scenarios. ASAI-related information such as ANI, DNIS, and call-prompting information and Avaya IR system data can be present in call events. This information can be used in conjunction with data that is entered by a live agent to provide the basis for data screens.

Using ASAI in a call center


Using ASAI in a call center ASAI can significantly improve the operations in a call center. This feature provides the following benefits:

• Enhanced customer service

Caller-dependent and region-dependent treatment for incoming calls is possible in routing and voice response applications. In addition, the direct agent calling feature that is available with these applications allows calls to be delivered to specific agents while maintaining accurate split measurements. These capabilities help to ensure that calls are quickly and reliably directed to the call center resource that is best suited to handle them. This minimizes the number of transfers that a caller experiences and allows callers to be serviced in a rapid, consistent, and personalized fashion.

In data screen delivery applications, information associated with a given call is available to each agent who receives the call. This eliminates the need for callers to repeat information to each agent. For example, a caller may be directed initially to a Avaya IR system telephony channel where the caller is prompted through an automated voice response application. At some point the caller may request to be transferred to a live agent to discuss a topic in more detail. With the Avaya IR system's ASAI feature, the identity of the caller and additional information collected from the caller by the voice-response application can be saved and presented in a data screen to the live agent receiving the transferred call. This eliminates the need for the caller to repeat information already collected when calls are transferred multiple times or are transferred between live agents. Thus, call holding time is reduced.

• Improved price and performance

The coresidency of voice response and switch-to-host gateway applications with the ASAI feature eliminates the need for multiple boxes with multiple interfaces to the host computer, thereby simplifying host application development. Access to ASAI capabilities using IVR Designer minimizes the effort required to implement the Avaya IR system's piece of the overall Avaya IR system/host application. In addition, the use of DNIS in voice response applications to enable telephony channel sharing means that the same number of Avaya IR system channels can service more calls.

• Reduced cost of doing business

Because the host screen application is ready to provide or accept information at the same time that the agent begins to speak with the caller, the use of data screen delivery applications reduces the time needed to service calls. Because calls are shorter, network charges are lower. The same number of agents can handle an increase in call volume since per-call service time is reduced. Also, certain calls can be eliminated entirely via the use of routing applications, for example, call screening for the identification of fraudulent calls.



Specific agent tasks might change when you add an ASAI application such as data screen delivery to the call center. You should determine what agent training is needed before the new service begins. Agents should be trained on what new information will appear on their data terminal screens and how to use that information to interact with calling customers. Before implementing a data screen delivery application with the entire agent population, conduct a trial to compare old call center operations with the new call center operations using a data screen delivery application. Be sure to explain the benefits of the application so that agents can take advantage of them.

If data screen delivery is performed for agent-to-agent transfers, carefully read the information on Agent-to-Agent Transfers. Agents must be trained to perform transfers properly so that the desired call events are passed to the host application. More specifically, for blind transfers, agents must transfer calls as follows:

1. Place the original call on hold by pressing the Transfer button once. This also causes a new call appearance to become active (dial tone is heard on this call appearance).

2. Dial the desired extension while hearing dial tone on the new, active call appearance.

3. Immediately press the Transfer button again after dialing the desired extension to complete the transfer.

In consult transfer scenarios, the agent may wait to talk to the second agent before completing the transfer. However, the agent must make sure that the original call is on transfer hold before completing the transfer. A call is said to be on transfer hold when the call is placed on hold by pressing the Transfer button. This is as opposed to regular hold where the call is placed on hold by pressing the Hold button.

For example, the agent may decide to return to the original caller before completing the transfer (for example, to say, "Please wait while I transfer you to Bill who can handle your question"). The agent must be sure to place the original call on transfer hold (not regular hold) before completing the transfer. If the agent used regular hold, the agent would be unable to return to the original caller.

Use the following procedure for consult transfer situations where the screening agent wants to go back and talk to the original caller before completing the transfer. In this procedure, Agent 1 is the screening agent who receives the original call from the calling customer. Agent 2 is the specialized agent who receives the transferred call. Although this procedure may seem cumbersome initially, it is the most natural set of steps to take in consult transfer scenarios where the screening agent wants to announce the transfer to the original caller after having talked to the specialized agent. This procedure also ensures that the Avaya IR system can properly identify the original call when the two calls are merged. If agents do not follow this procedure, inaccurate call events are reported to the host application.

1. Agent 1 places the original caller on hold by pressing the Transfer button once. This also causes a new call appearance to become active (dial tone is heard on this call appearance).

2. Agent 1 dials Agent 2 while hearing dial tone on the new, active call appearance.

Using ASAI in a call center


3. Agent 1 places the call to Agent 2 on regular hold by pressing the Hold button while the call to Agent 2 is still the active call.

4. Agent 1 returns to the original caller by pressing the call appearance for the original call. This makes the original call active once again. Agent 1 can now talk to the original caller.

5. After talking to the original caller for the second time, Agent 1 places the original caller on transfer hold again by pressing the Transfer button again. This is the second time Agent 1 has pressed the Transfer button. This causes a third, as yet unused, call appearance to become active. (Dial tone is heard on this call appearance, but this call appearance is not used for anything. Agent 1 goes to the next step and ignores the dial tone).

6. Agent 1 makes the call to Agent 2, which is currently on regular hold, the active call by pressing the call appearance for this call. At this point Agent 1 and Agent 2 are connected again and Agent 1 can inform Agent 2 that the transfer is about to be completed.

7. Agent 1 completes the transfer by pressing the Transfer button again. This is the third time Agent 1 has pressed the Transfer button.



Call-flow design

Avaya IR system-to-agent transfers

Avaya IR system-to-agent transfers are accomplished by using the A_Tran external function within a voice application that is servicing a caller. The use of A_Tran invokes ASAI Third Party Call Control operations to transfer a call away from the telephony channel to which the caller is connected. The caller is transferred to the destination that is identified in the Destination Number field of the A_Tran external function.

The transferred call can be monitored by a monitoring application so that data screen delivery applications can be supported for Avaya IR system-to-agent transfers. The transferred call can be monitored in two different ways:

• The call can be transferred to a VDN or ACD split domain that is monitored by the Avaya IR system with a monitoring application. Call events for the transferred call are passed to the application that is monitoring the domain to which the call is transferred.

• The call can be monitored using a CTL type monitoring application. In this case, the call can be transferred to nonmonitored domains and individual stations. Here, only call events for calls that are transferred from the Avaya IR system to agents are passed to monitoring applications. Other direct calls to an ACD split, for example, are not monitored. Therefore, no call events for the direct calls are passed to monitoring applications.

You can use a combination of the above two monitoring mechanisms on the same Avaya IR system.

In addition to monitoring the transferred call, the application developer can save data that is collected in the voice application for subsequent use in the data screen delivery application. To do this, use the Avaya IR system Data field of A_Tran. Any data saved that is in this field when the transfer is initiated from the voice application is presented in call events that are passed to the monitoring application that monitors the transferred call. The Avaya IR system Data field provides storage for 20 characters. Note that multiple data items can be stored in this field. A social security number and PIN number, for example, can be collected in the voice application, concatenated, and then saved in the Avaya IR system Data field. The monitoring application that receives this data in call events can then unbundle the information for use in data screen delivery when the transferred call is delivered to an agent.

Typical call flow for Avaya IR system-to-agent transfers

The following is a typical call flow for a Avaya IR system-to-agent transfer:

1. A call arrives at a telephony channel on the Avaya IR system. The caller is prompted through a voice response application.

2. The caller decides to speak to a live agent after entering an account number. The voice application transfers the call to a live agent group using the A_Tran external function. The

Call-flow design


account number that the caller input is saved by using the Avaya IR system Data field of A_Tran. The voice application terminates after the transfer is complete and the telephony channel is free to handle another call.

3. The transferred call is queued for an available agent. When the call is eventually delivered to an agent, a monitoring application on the Avaya IR system receives a CONNECT event for the call. The Avaya IR system Data field of this CONNECT event contains the account number that was previously saved by the voice application. The monitoring application passes the account number along with the connected agent information from the CONNECT event to the host.

4. The host application uses the account number to format a data screen concerning the caller and presents this data screen to the agent who receives the call. The host application does not need to associate multiple calls since all the necessary information for the transferred call is provided in a single CONNECT event.

One CONNECT event is generated for the entire scenario. This is the CONNECT event for the transferred call as it is delivered to the live agent. This CONNECT event contains the Avaya IR system Data information in addition to ASAI information that is related to the original call to the Avaya IR system. The ANI and DNIS for the original call prior to the transfer, for example, are reported in this CONNECT event. Also, the Other Call ID field contains the call ID of the call that was originally delivered to the Avaya IR system's telephony channel. Call events for calls to telephony channels on the Avaya IR system are not passed to monitoring applications. Also, one END event is generated when the call eventually terminates. As with the CONNECT event, the END event contains data that is pertinent to the original call. See Call flow examples on page 153 for a detailed call flow example.

Considerations for Avaya IR system-to-agent transfers

Additional considerations for Avaya IR system-to-agent transfers are as follows:

• In some cases, you might want to collect more data in a voice application than can be stored in the Avaya IR system Data field. The recommended method for handling this is to save the data collected by the voice application in the host application. Use A_Callinfo to retrieve the call ID of the call that is delivered to the telephony channel. Pass the call ID along with the data to the host from the voice application itself. The host application must buffer the data until the CONNECT event for the transferred call is received. The call ID in the Other Call ID field of the CONNECT event can be used to correlate the two calls.

• The call can be transferred again after having been serviced by the live agent. In this case, an END event is not reported until all transferring is complete and the call terminates normally. As in the case of a single transfer, the END event contains information pertinent to the original call. Rules for how subsequent call events are reported are discussed in Agent-to-Agent Transfers.

• The discussions on blind and consult transfers do not apply to Avaya IR system-to-agent transfers completed using the A_Tran external function. Also, the delay needed for agent-



to-agent transfers discussed later does not apply to Avaya IR system-to-agent transfers completed using the A_Tran external function.

• Transfers away from the Avaya IR system can still be accomplished by using standard flash transfer mechanisms. This type of transfer, however, precludes the ability to use the Avaya IR system Data field of the A_Tran screen to save voice application data for later use in data screen delivery applications. Also, the host application must view this type of transfer as an agent-to-agent transfer. Hence, the discussions on blind transfer versus consult transfer and the need to introduce delay for blind transfers from the Avaya IR system apply.

Agent-to-agent transfers

There are two options for call transfer in an agent-to-agent transfer scenario: blind transfer and consult transfer. These two options differ as to when the screening agent (the agent transferring the call) completes the transfer to the specialized agent (the agent receiving the transferred call) by pressing the Transfer button a second time.

• With a blind transfer, the screening agent presses the Transfer button a second time immediately after dialing. The screening agent does not talk to the specialized agent before completing the transfer. In addition, a delay is built into call handling so that the call is distributed to a specialized agent after the screening agent presses the Transfer button the second time.

• With a consult transfer, the screening agent waits until the specialized agent answers before pressing the Transfer button a second time.This allows the screening agent to talk to the specialized agent before completing the transfer.

Both of these call-transfer options are described in more detail later. To set up either a blind transfer or a consult transfer, it is important to understand two key concepts of how transferred calls are handled on the DEFINITY G3 switch.

Call monitoring in transfer scenarios

The Avaya IR system monitors VDN or ACD split domains by assigning monitoring applications. A call becomes monitored once it enters one of these monitored domains. The Avaya IR system must also monitor all domains to which this call can be directed. Once monitored, therefore, a call remains monitored for the duration of the call even though it can be transferred several times. Once a call becomes monitored, call events are passed to the monitoring application that is assigned to the domain the call entered. A CONNECT event, for example, is passed to a monitoring application when a specific agent is selected to receive the call. The screening agent may transfer calls to other monitored VDN and ACD splits or to individual stations. The original call to the screening agent must be monitored and therefore delivered to the screening agent via a monitored VDN or ACD split.

Call-flow design


Call ID management in transfer scenarios

The DEFINITY G3 switch assigns a call ID to each call. The call ID is provided in the Call ID field of call events for the call. In agent-to-agent transfer scenarios, there are multiple calls and, therefore, multiple call IDs as described in the following transfer scenario:

1. The original call is delivered to an agent and is assigned a unique call ID. The agent talks with the caller and decides that the call needs to be transferred to another agent.

2. The first press of a Transfer button places the original call on hold and allows another call to be placed from the transferring telephone.

3. A second call, temporarily independent of the first call, is placed from the transferring telephone. This call is assigned a call ID that is different from that of the original call. If this second call is placed to a monitored domain, the call immediately becomes monitored by the Avaya IR system and call events can be passed to a monitoring application. If this second call is placed to an individual station, the call does not become monitored until the transfer is complete as described in Step 4.

4. The second press of the Transfer button merges the original call which is on hold with the second call and drops the transferring telephone from the resultant call.

The Avaya IR system is informed about the completed transfer immediately after the merge that occurs in Step 4. It is only after this merge, therefore, that the Avaya IR system has the ability to associate the two calls.

With a blind transfer, this merge takes place before the merged call is delivered to the second, specialized agent. Hence, with blind transfer calls, the Avaya IR system can include information in the CONNECT event for the merged call that relates to the original call. In particular, the Avaya IR system retains the call ID of the original call and reports it in the Other Call ID field of the call events for the transferred call. This mechanism allows the host application to use call ID to associate the transferred call with the original call.

With a consult transfer, the merge takes place after the second call is delivered to the second, specialized agent. In this case, the original call is still on hold at the first agent's telephone when the second call is delivered to the second agent. Hence, for consult transfers, the Avaya IR system can only provide information that is related to the second call in the CONNECT event for the second call. In particular, the call ID of the original call is not reported in the Other Call ID field of the CONNECT event for the second call. The host application must use a mechanism other than call ID to associate the original call with the second call. The alternate mechanism is the CPN information as discussed below.

Blind transfer

With a blind transfer, the screening agent does not talk to the specialized agent before completing the transfer. With this type of transfer, the Avaya IR system retains the call ID of the original call and reports it in the Other Call ID field of call events for the transferred call. Also, other ASAI information such as ANI and DNIS that is related to the original call is reported in the call events for the transferred call.



A typical call flow for blind transfers is described below. In this call flow, Agent 1 is a live agent in a screening split who transfers calls to specialized agents. Agent 2 is a specialized agent who can either receive calls via a monitored VDN or ACD split or via a regular extension. Calls to Agent 1 in the screening split must be delivered via a monitored VDN or ACD split.

1. A call arrives for Agent 1.

2. Agent 1 answers the call and enters pertinent information about the caller.

3. Agent 1 transfers the call to Agent 2 by pressing the transfer button, dialing the VDN, ACD split, or individual extension and pressing the transfer button again.

4. Agent 1 is finished with the call.

5. The host application uses call ID information reported in CONNECT events to determine which data to display on Agent 2's data-terminal screen. The call ID from the Call ID field of the CONNECT event for the original call matches the call ID provided in the Other Call ID field of the CONNECT event for the transferred call.

Two CONNECT events are passed to monitoring applications for the entire scenario, that is, one for the original call to the screening agent and one for the transfer to the specialized agent. One END event is generated when the call eventually terminates. See Call flow examples on page 153 for detailed examples that include complete descriptions of call flows and call-event contents.

The following conditions should be noted for blind transfers:

• The domain that receives the original call and any domains that receive the transferred call must be monitored.

• Calls can be transferred either to a monitored domain or to a station. For a blind transfer to a monitored domain, the following must be considered:

― The agent must complete the transfer immediately after initiating it by pressing the Transfer button a second time.

― A delay must be built into the flow of the transfer so that the communications system can recognize the completion of the transfer before the receiving agent is selected for the call. You can create this built-in delay by transferring calls to a VDN. This VDN is associated with a vector that has a "wait" step in it. The vector directs the call to the desired split with a route to or queue to step.

For blind transfer to a station, the following must be considered:

― When an agent in a monitored domain completes a transfer to a station rather than to an ACD split, a CONNECT event is passed to a monitoring application. The agent must initiate and complete the transfer by pressing the Transfer button a second time for the CONNECT event to be passed to the application. The CONNECT event therefore only becomes available to the host application when the agent pushes the Transfer button the second time.

Call-flow design


• In call-center operations that use blind transfer, the host application can tag current call data by call ID. The call ID allows the application to determine which data is associated with the call as the call is transferred to a monitored domain or station.

• If for some reason calls are transferred to nonmonitored domains, unexpected operation can result. When the call placed by Agent 1 is not initially monitored, the Avaya IR system assumes that a transfer to a station is taking place. Hence, two CONNECT events for the transferred call are generated. One CONNECT event is generated when the transfer is completed by Agent 1 and another is generated when the call is actually delivered to Agent 2. Also, the Connected Party Number field of the first CONNECT event for the transferred call identifies the ACD split or VDN extension that was dialed by Agent 1, rather than identifying the extension of Agent 2. Note that the Connected Party Number field of the second CONNECT event for the transferred call identifies the extension of Agent 2.

• The END event that is reported for the transferred call contains information pertinent to the original call. For example, the original ANI for the caller is reported in the Calling Party Number field and the call ID for the original call is reported in the Other Call ID field. Also, an END event is reported for a call only when the call ultimately terminates. An END event is not reported when a call is transferred.

• The call can be transferred again after it is serviced by Agent 2. In this case, an END event is not reported until all transferring is completed and the call terminates normally. As in the case of a single transfer, the END event contains information that is pertinent to the original call. Rules for how subsequent CONNECT events are reported are as described in this section and depend on whether the call is transferred to a monitored domain or to a station and whether consult or blind transfer operation is used.

Consult transfer

With a consult transfer, the screening agent talks to the specialized agent before completing the transfer. With this type of transfer, the call ID for the original call is not retained by the Avaya IR system and is not reported in the Other Call ID field of call events for the transferred call.

A typical call flow for consult transfers is described below. In this call flow, Agent 1 is a live agent in a screening split who transfers calls to specialized agents. Agent 2 is a specialized agent who can receive calls via a monitored VDN or ACD split or via an individual station. Calls to Agent 1 in the screening split must be delivered via a monitored VDN or ACD split.

1. A call arrives for Agent 1.

2. Agent 1 answers the call and enters pertinent information about the caller.

3. Agent 1 presses the Transfer button.

4. Agent 1 dials the extension of the monitored domain or station to which the call will be transferred.

5. Agent 1 waits for Agent 2 to answer.



6. Agent 1 and Agent 2 consult privately about the caller.

7. Agent 1 presses the Transfer button again to complete the transfer.

8. Agent 1 is finished with the call.

9. The host application uses calling party information to determine which data to display on Agent 2's data terminal screen. The extension for Agent 1 is reported in the Calling Party Number field of the CONNECT event for the second call.

Two CONNECT events are passed to monitoring applications for the entire scenario, one for the original call to the screening agent and one for the call to the specialized agent. One END event is generated when the call eventually terminates.

See Call flow examples on page 153 for detailed examples that include complete descriptions of call flows and call-event contents.

The following conditions should be noted for consult transfers:

• With a consult transfer, Agent 1 and Agent 2 generally both view the call data in a private consultation while the caller is on soft hold.

• Calls can be transferred either to a monitored domain or to an individual station. For a consult transfer to a monitored domain, the following must be considered:

― When Agent 2 is selected to receive the call from Agent 1, a CONNECT event is made available to a monitoring application. Since Agent 1 stays on the line until Agent 2 answers, the two calls have not yet been merged. This implies that the CONNECT event for the second call does not contain information that is pertinent to the first call. The Other Call ID field for the second CONNECT event, for example, is NULL and does not contain the call ID of the first call. Also, for example, the Calling Party Number field contains the extension for Agent 1 and not the ANI for the caller. This is because the second call is viewed as a new, direct call to Agent 2 from Agent 1. The Avaya IR system cannot assume that the two calls will eventually be merged since in some cases, they will not be. Hence, the two calls cannot be correlated by using call ID from CONNECT events.

― In this case, the Calling Party Number field of the second CONNECT event should be used to correlate the two calls. This field contains the extension for Agent 1. The host application can assume that Agent 1 is performing a consult transfer. The host application can then retrieve the appropriate data from Agent 1's data-terminal screen and deliver it to Agent 2's data-terminal screen. After the two agents consult, Agent 1 can complete the transfer by pressing the Transfer button a second time. No additional CONNECT event is passed to a monitoring application when the transfer is completed.

For consult transfer to a station, the following must be considered:

― A CONNECT event for the second call is passed to a monitoring application only after the transfer is completed when Agent 1 presses the Transfer button the second time. This means that when Agent 1 and Agent 2 are talking privately, the host application

Call-flow design


will not have been notified about the second call to Agent 2. This is because the second call is placed to a station and not to a monitored domain. The Avaya IR system, therefore, does not receive events for the second call until the two calls are merged. The host application can be programmed to allow the receiving station to query for the data. After the transfer is complete, a CONNECT event is passed to a monitoring application. This CONNECT event contains information that is pertinent to the first call. The Other Call ID field of this CONNECT event, for example, contains the call ID of the original call that was delivered to Agent 1. Also, for example, the Calling Party Number field of this CONNECT event contains the ANI of the original caller.

• If for some reason calls are transferred to nonmonitored domains, an unexpected operation can result. When the call to Agent 2 from Agent 1 is not initially monitored, the Avaya IR system assumes that a transfer to a station is taking place. Hence, the Connected Party Number field of the CONNECT event generated when the transfer is completed by Agent 1 identifies the ACD split or VDN extension dialed by Agent 1, rather than the extension of Agent 2.

• The END event reported for the transferred call contains information that is pertinent to the original call. For example, the original ANI for the caller is reported in the Calling Party Number field and the call ID for the original call is reported in the Other Call ID field. This is true even though the second CONNECT event for consult transfers to monitored domains does not contain information that is pertinent to the original call. This is because the END event is reported after consult transfers to monitored domains are completed; that is, after the two calls are merged and can be associated by the internal software on the Avaya IR system. Also, an END event is reported for a call only when the call ultimately terminates (that is, an END event is not reported when a call is transferred). These properties for END events allow the host application to consistently use the Other Call ID field of END events to identify when and which calls have left the DEFINITY G3 switch entirely.

• The call can be transferred again after it is serviced by Agent 2. In this case, an END event is not reported until all transferring is completed and the call terminates normally. As in the case of a single transfer, the END event contains information that is pertinent to the original call. Rules for how subsequent CONNECT events are reported are as described in this section and depend on whether the call is transferred to a monitored domain or to a station and whether consult or blind transfer operation is used.



Host application planning and design In certain call center environments, the Avaya IR ASAI system is integrated with a host computer. An application must be provided on the host that works with the Avaya IR ASAI system. This host software application is not part of the Avaya IR ASAI product. The host application can use the information it receives from the Avaya IR ASAI system to do certain functions such as display call information on agent screens or route calls. The host application can also be called upon to provide the basis for an automated voice response application.

In some cases, particularly for voice response applications, the Avaya IR ASAI system integrates well with an embedded application and hence no changes are required. For routing and data screen delivery applications, however, you will probably have to modify an existing application or provide a new one to accommodate new functionality.

You may have several options for providing this host application. For example, you can develop your own application or modify an existing application to work with the Avaya IR ASAI system. This is typically done by the customer's data processing or information systems department. Alternatively, you can purchase a third-party software vendor application that is designed to work with the Avaya IR ASAI system.

Application development may require significant planning and coordination between different organizations within your company. The telecommunications, call center operations, and data processing organizations are all typically involved in the planning process. Schedules for application development or customization must be coordinated closely with plans to implement the Avaya IR ASAI system, ISDN services, and any additional communications system ACD features.

The voice response, routing, and data screen delivery applications enabled by a Avaya IR ASAI system can all potentially make use of ANI information delivered by the network. The use of ANI generates several considerations.

• You should allow for the possibility that the same caller will call from different telephone numbers. The same person, for example, might sometimes call from home and sometimes call from the office. The same database record should be used in both cases. Calls generated from a switch will probably have more than one ANI assignment. This is based on the different trunk groups used to generate the call and the fact that individual trunk circuits sometimes carry different ANI identities.

• You should allow for situations when ANI information is not delivered for a call.

― In voice response applications, the voice application should provide some sort of default call handling for cases where no ANI is available.

― In routing applications, the caller could be routed to an Avaya IR system so that additional information can be collected.

Host application planning and design


― In data screen delivery applications, an agent can ask the caller for this information.

• You might want to write an ANI learning module to automatically associate new ANI information with existing customer records. Agents and voice response applications can verify ANI information that is passed by the DEFINITY G3 switch to the Avaya IR system.

• You should allow for situations where a single ANI is associated with multiple calling customers. More than one customer, for example, can call from the same switch. Examples of how to handle such situations include bringing up a menu from which the agent can choose the appropriate customer and switching to traditional methods for bringing up customer data.

ASAI voice response application considerations • Voice response applications can make use of direct agent calling. Calls can be

transferred to specific agents within ACD splits after being serviced by a voice response application. In this case, your database must maintain the ACD split extensions that agents are logged into as well as the extensions for the agents themselves.

Routing application considerations • Unlike data screen delivery applications, routing applications make use of the host

application in an inquiry/response fashion. This implies that the addition of a Avaya IR ASAI routing application to your call center may have little or no impact on the high-level operation of the application. The most significant change to the host application will probably be the information stored in the database. Information as to how calls should be routed must be added to the database if it is not already present. An example is ANI-to-agent and/or ACD split mappings. If feasible, consider using a local Avaya IR system database to store routing information.

• Routing applications can make use of direct-agent calling. Calls can be routed to specific agents within ACD splits. In this case, your database must maintain the ACD split extensions that agents are logged into as well as the extensions for the agents themselves.

Data screen delivery application considerations • Prior to the use of data screen delivery applications, a host application typically waits for

input from agents before it performs an operation. Thus, the agent's input generally controls the application. With data screen delivery applications, a new input to the application is provided. While this input enables agents to work more quickly, it means that the host application must be modified. In particular, the host must use the call events provided by a monitoring application on the Avaya IR system to drive the screens on the agents' terminals. The interface to the system serves as a control link while the interface to the agent operates traditionally as an inquiry/response link. The interactions between these two properties of the application must be considered carefully.

Suppose, for example, that a call arrives for an agent before that agent is finished entering data from the previous call. This scenario can be handled in one of two ways:



― Agents can be trained to use Aux Work or After Call Work feature buttons on their telephones to make themselves unavailable for calls until they are finished entering data from the previous call.

― There is typically a point in the application's sequence of operations (for example, base transaction screen) where the agent is waiting for a new call and begins interaction with the application. The application could look for information from the Avaya IR system only at this point. The agent's telephone will alert the agent to the new call, and the agent can quickly finish work on the previous call. You may want to provide a quick way for the agent to move to this place in the interactions with the application.

• In data screen delivery applications, telephone extensions are used to identify agents who are receiving calls. The host application must therefore be able to associate extensions with particular data terminals. There are three possible ways to do this:

― The agent can be queried for the telephone extension when the application is started. This is the most flexible arrangement and handles the situation where data terminals and terminal IDs are not permanently associated with the same telephone. Agents do make mistakes in providing the telephone extension to the system. You should plan for these occasional mistakes and make sure that agents understand how to use the system properly. Discuss this issue with the person responsible for the company's agent operations.

― If an agent is always assigned to the same work position and hence, to the same extension, the extension information could be added to an agent profile.

― If the relationship between data terminals, terminal IDs, and telephones is relatively stable, administration of the host application can maintain a fixed mapping between telephones and terminals.

• The agent screen application should be able to operate even if the Avaya IR system is not delivering call events. If call information is not being delivered, the appropriate person or the application itself should notify agents that there is a problem and that they should operate in manual mode. The DEFINITY G3 switch continues to deliver calls to agents even if the ASAI link to the Avaya IR system is down.

• Your application should be able to accommodate cases where multiple CONNECT events are received for the same call. This can occur, for example, where direct-agent calling is used. A call might first ring at the initial agent's telephone and then at the telephone of a covering agent if the call is not answered by the initial agent. In this case, two CONNECT events are sent to a monitoring application when CONNECT events are triggered on an ASAI-alerting event report.

• Your application should be able to accommodate cases where the connected party identified in call events is not a known ACD agent. Depending on switch administration and the design of call vectors, calls can be redirected to domains (VDNs or ACD splits) other than the domain to which the call is originally offered. If calls cover or are redirected from a live-agent split to an AUDIX split, for example, call events can identify an AUDIX channel extension as the connected party.

Call flow examples


Call flow examples This topic provides the following examples of data screen delivery call flows and the contents of the call events that result from these call flows:

• Call to agent via ACD split

• Call to agent via VDNs with call prompting

• Call to VDN and abandoned in queue

• Call to VDN and abandoned after agent selection

• Agent-to-agent transfer via VDN and blind transfer

• Agent-to-agent transfer to a station via blind transfer

• Agent-to-agent transfer via VDN and consult transfer

• Agent-to-agent transfer to a station via consult transfer

• Avaya IR system-to-agent transfer via ACD split

In all call-flow scenarios, it is assumed that CONNECT events are triggered on ASAI alerting event reports. Hence, as shown in the scenarios, a CONNECT event is passed to a monitoring application when an agent is selected for a monitored call. An agent is considered to be selected for a call when the agent's telephone begins ringing or the agent hears a zip tone. CONNECT events can also be triggered on ASAI connected event reports. In this case, CONNECT events are passed to monitoring applications when agents actually answer monitored calls.

In all call-flow scenarios, it is assumed that the incoming call is delivered via an ISDN facility. This implies that the ANI is available in the ISDN SETUP message for the incoming call. If ANI is available, it is reported in call events as depicted in the call-flow scenarios. If ANI is not available, the incoming trunk group ID is reported instead.

Also, since it is assumed that incoming calls are delivered via an ISDN facility, a 10-digit called party number (CPN) is reported in call events. This number corresponds to the CPN that is provided in the ISDN SETUP message for the incoming call. Note that, as depicted in the call-flow scenarios, this number identifies a billing number and not the 800 number that is dialed by the caller. The use of switch administration to modify DNIS digits does not affect the reporting of the CPN for incoming ISDN calls.

Incoming calls can also be delivered via non-ISDN facilities. In this case, ANI is not available, so the trunk group ID is always reported instead. Also, for non-ISDN calls, the CPN identifies the ACD split or VDN extension to which the call is initially directed. Hence, for non-ISDN calls, the use of switch administration to modify DNIS digits can affect the reporting of the CPN. If modified by switch administration, the DNIS digits, as provided by the network, are



not reported in the CPN. Rather, the ACD split or VDN extension that results from the modification is provided in the CPN.

Scenarios 6 through 9 discuss agent-to-agent transfer calls. Note that the call events generated for agent-to-agent conference calls are the same as described in the transfer scenarios. The three functional differences for conference calls are:

• The screening agent uses the Conference button instead of the Transfer button.

• The screening agent stays on the call instead of being dropped off.

• The END event for the call is not generated until all parties disconnect from the call.

Call to an agent via an ACD split

A call arrives at the DEFINITY G3 switch and is delivered directly to a monitored ACD split (no vector processing takes place for the call). An agent is assigned to the call, interacts with the caller, and then terminates the call.

Example: 1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that

is associated with customer service.

Calls to that 800 number are presented to a monitored ACD split with the extension 7777.

2. The call is queued to the monitored ACD split 7777.

3. The call is assigned to an agent in that split with the extension 1234.

4. A CONNECT event is passed to the monitoring application for ACD split 7777 with the following information:

Connected Party Number 1234

Calling Party Number 3035551726

Called Party Number 9085557777

Switch Data

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field C

5. When the selected agent completes and disconnects the call, an END event is passed to the monitoring application for ACD split 7777 with the following information:

Call flow examples





Switch Data

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field E

Call to an agent via VDNs with Call Prompting

A call arrives at the DEFINITY G3 switch and is handled with call vectoring. The initial VDN/vector that processes the call makes use of the call-prompting feature on the DEFINITY G3 switch to collect information from the caller. In particular, the caller is asked to request a service, for example, "press 1 for gizmo service or press 2 for widget service." The call is then routed unconditionally to a second VDN that is monitored. The vector that is associated with the second VDN queues the call to an ACD split. Agents in this split can handle service calls for both products. The call-prompting information that is collected on the DEFINITY G3 switch can be used to determine which application to start up when the call is delivered to an agent in the common agent group. This allows a single 800 number to be advertised for both products.


is associated with customer service. Calls to that 800 number are initially handled with a vector that is associated with VDN 7771. VDN 7771 is not monitored. This vector prompts the user to enter a 1 or 2 and then routes the call to VDN 7772 with a "route to" step. In this example, it is assumed that the caller inputs a 1.

2. The call is routed to the monitored VDN 7772. The vector that is associated with VDN 7772 queues the call to an ACD split with a "queue to" step.

3. The call is assigned to an agent in the split with the extension 1234.

4. A CONNECT event is passed to the monitoring application for VDN 7772 with the following information:






Switch Data 1

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field C

5. When the selected agent completes and disconnects the call, an END event is passed to the monitoring application for VDN 7772 with the following information:




Switch Data 1

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field E

Call to a VDN and abandoned in queue

A call arrives at the DEFINITY G3 switch and is handled with a VDN or vector. The vector queues the call to an ACD split. The caller abandons the call while it is in the queue and before it is assigned to an agent.


is associated with customer service. Calls to that 800 number are processed by a vector that is associated with VDN 7771. VDN 7771 is monitored.

2. The vector that is associated with VDN 7771 queues the call to a vector-controlled split with a "queue to" step.

3. The caller abandons the call before an agent is assigned to the call.

Call flow examples


4. An ABANDON event is passed to the monitoring application for VDN 7771 with the following information:

Connected Party Number



Switch Data

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field A

Call to a VDN and abandoned after agent selection

A call arrives at the DEFINITY G3 switch and is handled with a VDN or vector. The vector queues the call to an ACD split. The caller abandons the call after is was assigned to an agent but before the agent could answer it.


is associated with customer service. Calls to that 800 number are processed by a vector that is associated with VDN 7771. VDN 7771 is monitored.

2. The vector that is associated with VDN 7771 queues the call to an ACD split with a "queue to" step.

3. An agent at extension 1234 is selected for the call.

4. The caller abandons the call before the agent at extension 1234 can answer.

5. An ABANDON event is passed to the monitoring application for VDN 7771 with the following information:




Switch Data

Trunk Group Id

Call Id 101



Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field A

Note that this is different from the previous scenario where the caller abandons the call while in the queue. Since an agent was selected for the call before it was abandoned, a CONNECT event is passed to the monitoring application. In the previous case where the caller abandons the call while it is in the queue, no agent was selected for the call; therefore, no CONNECT event is passed to the monitoring application before the ABANDON event. In this scenario, where the caller abandons the call after agent selection, the ABANDON event contains the extension of the agent who was selected for the call. This information can be used to cancel the CONNECT event for the call to the agent since the call terminates before the agent can interact with the caller. Alternatively, the host application could simply let the next CONNECT event for the same agent "overwrite" the previous CONNECT event for the call that was abandoned. The next CONNECT event comes when the next call is delivered to the agent.

Note also that this scenario only applies when CONNECT events are triggered on ASAI alerting event reports. If CONNECT events are triggered on ASAI CONNECT event reports, CONNECT events are passed to monitoring applications only when agents actually answer calls. Consequently, for cases where CONNECT events are triggered on ASAI CONNECT event reports, only an abandon while in the queue situation is possible. An abandon after agent selection situation will never occur or be reported.

Agent-to-agent transfer via a VDN and blind transfer

A call is delivered to an agent within a screening split. The screening agent transfers the call using a blind transfer to a group of specialized agents. A delay is built into the transfer by having the screening agent place the transfer call to a VDN. The vector associated with this VDN queues the call to the specialized agent group after delaying the call. This delay allows the transfer to be completed before the transfer call is delivered to a specialized agent.

Example 1. A caller calling from the telephone number 303-555-1726 calls a toll-free 800 number that

is associated with customer service. Calls to that 800 number are processed with a vector that is associated with VDN 7771. VDN 7771 is monitored.

2. The vector that is associated with VDN 7771 queues the call to the split of screening agents.

3. The call is assigned to an agent in the screening split with the extension 1234.


Call flow examples





Switch Data

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field C

5. The screening agent talks with the caller and determines that a transfer is necessary.

6. The screening agent at extension 1234 presses the Transfer button and dials 7770, which is the extension of a monitored VDN.

7. The vector associated with VDN 7770 delays the call placed by the agent at extension 1234 for 2 seconds with a "wait" step.

8. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. Note that no END event is reported at this time.

9. The vector associated with VDN 7770 queues the resultant call to the group of specialized agents with a "queue to" step.

10. A specialized agent at extension 4681 is selected for the transferred call.





Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data

Routing ID



Return Field C

12. The specialized agent at 4681 completes the call and disconnects.

13. An END event is passed to the monitoring application for VDN 7770 with the following information:




Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data

Routing ID

Return Field E

Note that for blind transfers to monitored domains as described in this scenario, the second CONNECT event identifies the original call in the Other Call Id field. Note also that this CONNECT event contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display information, VIS data, or switch data associated with the original call is also carried forward.

Agent-to-agent transfer to a station via blind transfer

A call is delivered to an agent within a screening split. The screening agent transfers the call using blind transfer to a specialized agent at an individual station.







Call flow examples




Switch Data

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field C


6. The screening agent at extension 1234 presses the Transfer button and dials 2022. Extension 2022 identifies an individual station that is associated with a single, specialized agent.

7. The call initiated by the agent at extension 1234 begins ringing at station 2022. Note that no CONNECT event is reported for this call at this time since the Avaya IR system is not yet monitoring this call.

8. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. Note that no END event is reported at this time.





Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data

Routing ID

Return Field C



Note that this CONNECT event for blind transfers to stations is not passed to a monitoring application until the screening agent completes the transfer by pressing the Transfer button a second time.

10. The specialized agent at 2022 answers the transferred call and begins interacting with the original caller.






Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data

Routing ID

Return Field E

Note that for blind transfers to stations as described in this scenario, the second CONNECT event identifies the original call in the Other Call Id field. Note also that this CONNECT event contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display information, VIS data, or switch data that is associated with the original call is also carried forward.

Agent-to-agent transfer via a VDN and consult transfer

A call is delivered to an agent within a screening split. The screening agent transfers the call using consult transfer to a group of specialized agents.





Call flow examples






Switch Data

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field C


6. The screening agent at extension 1234 presses the Transfer button and dials 7772, which is the extension of a monitored VDN.

7. The vector associated with VDN 7772 queues the call to the group of specialized agents.

8. A specialized agent at extension 4440 is selected for the call that was placed by the agent at extension 1234.





Switch Data

Trunk Group Id

Call Id 105

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field C

10. The screening agent and the specialized agent talk privately while the original caller is on hold.



11. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. The original caller is now connected to the specialized agent at extension 4440. Note that no END event is reported at this time.

12. The specialized agent at extension 4440 interacts with the original caller.






Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data

Routing ID

Return Field E

Note that for consult transfers to monitored domains as described in this scenario, the second CONNECT event does not identify the original call in the Other Call Id field. Note also that this CONNECT event does not contain ASAI information that pertains to the original call. Only call events passed to a monitoring application after the transfer is completed contain this information, for example, the END event or a CONNECT event for a subsequent blind transfer. Any LAI display information, Avaya IR system data, or switch data that is associated with the original call is also carried forward and reported in call events that are reported after the transfer is complete.

Agent-to-agent transfer to a station via a consult transfer

A call is delivered to an agent within a screening split. The screening agent transfers the call using consult transfer to a specialized agent at an individual station.



Call flow examples








Switch Data

Trunk Group Id

Call Id 101

Other Call Id

LAI Display Info

VIS Data

Routing ID

Return Field C


6. The screening agent at extension 1234 presses the Transfer button and dials 2022. Extension 2022 identifies an individual station that is associated with a single, specialized agent.

7. The second call that was initiated by the agent at extension 1234 begins ringing at station 2022. Note that no CONNECT event is reported for this call at this time since the Avaya IR system is not yet monitoring this call.

8. The specialized agent at extension 2022 answers the call from the screening agent at extension 1234.

9. The screening agent and the specialized agent talk privately while the original caller is on hold.

10. The screening agent at extension 1234 then presses the Transfer button again. This merges the two calls at the screening agent's telephone and drops the screening agent from the resultant call. The original caller is now connected to the specialized agent at extension 2022. Note that no END event is reported at this time.







Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data

Routing ID

Return Field C

Note that this CONNECT event for consult transfers to stations is not passed to a monitoring application until the screening agent completes the transfer by pressing the Transfer button a second time.

12. The specialized agent at 2022 interacts with the original caller.






Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data

Routing ID

Return Field E

Note that for consult transfers to stations as described in this scenario, the second CONNECT event identifies the original call in the Other Call Id field. Note also that this CONNECT event contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display information, Avaya IR system data, or switch data that is associated with the original call is also carried forward.

Call flow examples


Avaya IR system-to-agent transfer via an ACD split

A call is delivered to a Avaya IR system telephony channel and serviced by an ASAI voice response application. An account number is collected in the voice application in preparation for a data screen delivery application based on this account number. The call is then transferred to a live agent group.


is associated with customer service. Calls to that 800 number are processed with a vector that is associated with VDN 7771. VDN 7771 is not monitored.

2. The vector that is associated with VDN 7771 routes the call to the Avaya IR system split with a "route to" step. Note that this split is monitored, but not by a monitoring application used to retrieve call events. This split is monitored internally by the Avaya IR system to support ASAI voice response applications that make use of the A_Callinfo and A_Tran external functions.

3. The call is answered by a telephony channel and serviced by a voice response application. No CONNECT event is passed to a monitoring application for the call at this point. Assume, however, that this call is assigned call ID 101. This call ID would be available within the voice application by using the A_Callinfo external function.

4. The voice application collects an account number from the caller. In this example, it is assumed that the account number is 987654321.

5. The A_Tran external function is used within the voice application to transfer the call to the monitored ACD split 7777. The Destination Number field of A_Tran is set to 7777 and the Avaya IR system Data field of A_Tran is set to 987654321.

6. When the transfer is executed, the voice application terminates. This allows the telephony channel to service additional calls.

7. The call queues to the monitored ACD split 7777.

8. An agent at extension 1234 within ACD split 7777 is selected for the call.

9. A CONNECT event is passed to the monitoring application for ACD split 7777 with the following information:




Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101



LAI Display Info

VIS Data 987654321

Routing ID

Return Field C

10. The agent at extension 1234 answers the call and interacts with the caller.

11. The agent at extension 1234 completes the call and disconnects.

12. An END event is passed to the monitoring application for ACD split 7777 with the following information:




Switch Data

Trunk Group Id

Call Id 105

Other Call Id 101

LAI Display Info

VIS Data 987654321

Routing ID

Return Field E

Note that for Avaya IR system-to-agent transfers as described in this scenario, only one CONNECT event is reported to a monitoring application. This CONNECT event is reported when a live agent answers the transferred call. Not also that this CONNECT event contains data in the Avaya IR system Data field if such data was saved in the voice application by the use of the A_Tran external function. The CONNECT event also identifies the original call in the Other Call Id field and contains ASAI information that pertains to the original call, for example, original ANI and DNIS in the Calling Party Number and Called Party Number fields, respectively. Any LAI display information or switch data that is associated with the original call is also carried forward.

Note that the call can also be transferred from the Avaya IR system to a nonmonitored domain or individual station. In this case, the call events are the same as those described in this scenario. The call events, however, are passed to a CTL-type of monitoring application instead of a VDN-type or ACD-split-type of monitoring application. Also, A_Tran must be used to ensure that the CTL-type monitoring application receives the call events for the transferred call.


Designing applications that use Computer Telephony Integration (CTI)

You must invoke Computer Telephony Integration (CTI) external functions to either change the state of a call or to move information about a call. The following external functions are available for application development with IVR Designer:

• ctiCallInfo

• ctiCallState

• ctiConfer

• ctiDial

• ctiDiscon

• ctiHold

• ctiNotify

• ctiPrivData

• ctiRetrieve

• ctiTransfer

See the appropriate topic for details about a particular external function.



ctiCallInfo

Description

The ctiCallInfo external function provides the call ID, ANI, called number, and Avaya IR port extension associated with an active call at the Avaya IR.

Output • Call ID – Variable where the call ID will be stored.

(Type: num)

• ANI – Variable where the ANI of the call will be stored.

(Type: char, Size: 16)

• Called Number – Variable where the Called Number or DNIS will be stored.


• Station Extension – Variable where the Avaya IR Port extension will be populated.


• Skill – Variable where the skill/split hunt-group number will be stored.


Return values

The return code indicates whether the CTI DIP can find any call present at the Avaya IR port.

If successful, the result is > 0.

On failure, the result is <=0.

Usage notes

The ctiCallInfo function is often the first external function that is called in an application. It identifies the call ID of the call that has reached the Avaya IR. This is useful for any controlling function that might be used later in the application, such as placing the call on hold ( ctiHold ). It also identifies the number that was dialed by the caller. If the call was inbound from an ISDN trunk group, it also identifies the DNIS associated with the call. This feature is most useful in applications that dynamically assign a Avaya IR application on DNIS.

If there is more than one call present at a Avaya IR port, ctiCallInfo reports the latest call. For example, if one call is on hold while another call is active, ctiCallInfo reports only on the most recent call to arrive at the Avaya IR port, regardless of whether this call is on hold or not.

ctiCallInfo


Example

External Function

Function Name: ctiCallInfo

Use Arguments: cust_callid ani calledNum station_id skill



ctiCallState

Description

ctiCallState provides the state of all the calls present at the Avaya IR port extension.

Output • Call ID of Call #2 - Variable where the call ID of call #2 will be populated.

(Type: num)

• Call ID of Call #3 - Variable where the call ID of call #2 will be populated.

(Type: num)

• State of Call #1 - Variable where the state of call #1 will be populated. See "Usage notes"

(Type: num)


(Type: num)


(Type: num)

Return values

The return code indicates whether the CTI DIP can find a call present at the Avaya IR port.

If successful, the result is the call ID of call #1.

On failure, the result is -1.

Usage notes

A Avaya IR port can support up to 3 simultaneous calls. This external function can be used to determine the call ID and associated state (ALERTING, HELD, ESTABLISHED) of the calls present at the port. The states are represented by values:

Value State 0 None

1 Delivered

2 Established

3 Held

ctiCallState


Value State 4 Conferenced

5 Transferred

6 Initiated

7 Originated

Note: The ordering of the calls is determined by the arrival order. Call #1 is most likely the first call received by the Avaya IR.

Example

External Function

Function Name: ctiCallState

Use Arguments: call2id call3id call1state call2state call3state

Return Field: retcode



ctiConfer

Description

ctiConfer requests that two calls present at a Avaya IR port be conferenced together.

Input • Call ID of held call - Call ID of held call.

(Type: num)

• Call ID of active call - Call ID of active call.

(Type: num)

Return values

The return code indicates whether the two calls were conferenced.

If successful, the result is >0.


Usage notes

ctiConfer requires one of the calls involved in the transfer be on hold at the Avaya IR port prior to execution.

Example

External Function

Function Name: ctiConfer

Use Arguments: cust_callid interp_callid


ctiDial


ctiDial

Description

ctiDial requests a call be placed from the Avaya IR port to a destination.

Input • Phone number - The destination number to be dialed.


• User-user-information - Up to 96 bytes of user-provided data.


Return values

The return code indicates whether the call was successfully placed.



Example

External Function

Function Name: ctiDial

Use Arguments: "5552499" UUI




ctiDiscon

Description

ctiDiscon requests a call be placed from the Avaya IR port to disconnect a call.

Input • Call ID - The call ID to be disconnected.

(Type: num)

Return values

The return code indicates whether the call was successfuly disconnected.



Usage notes

ctiDiscon is best used in conjunction with the ctiCallState function to determine the state of a call before it is disconnected.

Also, the Avaya IR port itself will not detect any dial tone on the line after the call is disconnected. If the application needs to terminate before the call is disconnected, it must explicitly do so after a successful return.

Example

External Function

Function Name: ctiDiscon

Use Arguments: call2id


ctiHold


ctiHold

Description

ctiHold requests that a call that is active at the Avaya IR port be placed on hold.

Input • Call ID - The ID of the call to be placed on hold.

(Type: num)

Output • Error Code - Variable that is populated with an error code if the operation fails.

(Type: num)

Return values

The return code indicates whether the call was successfully placed on hold.



Usage notes

ctiHold is best used in conjunction with the ctiCallState function to determine the state of a call before it is placed on hold.

If an error is encountered, the CTI DIP will populate the Error Code field. The value will be of type CSTA_Universal_Failure_t.

Example

External Function

Function Name: ctiHold

Use Arguments: cust_callid error




ctiNotify

Description

ctiNotify provides answer notification to a voice application that has launched a call.

Input

None.

Return values

The return code indicates whether a tracked call has been answered.

If successful, the result is the call ID of the established call, which means that the tracked call is answered.

On failure, the result is -1, which means that the CTI DIP found no call at the Avaya IR port to track.

Usage notes

ctiNotify is most useful in outbound calling when used in conjunction with ctiDial. The function is solely dependent on receiving answer supervision on a timely basis from the network. Therefore, if the call is sent over a non-ISDN trunk to a destination, the function may return several seconds after the call is actually connected.

When the ctiNotify request is made, a message is sent to the CTI DIP. The CTI DIP checks the status of the calls that are currently at the Avaya IR port.

If a call is found to be either in the DELIVERED or ORIGINATED state, the CTI DIP:

Tags this call to receive answer notification.

Tracks the call that has been tagged.

When the tracked call is answered, sends the call ID of the answered call to the application.

If no call is currently in either the DELIVERED or ORIGINATED state, the CTI DIP returns a "-1" to ctiNotify. If ctiNotify receives a "-1," it tries up to three times to find a call at the Avaya IR port that is in either the DELIVERED or ORIGINATED state. There is a 500-millisecond pause between attempts.

Example

External Function

ctiNotify


Function Name: ctiNotify

Return Field: interp_callid



ctiPrivData

Description

ctiPrivData requests that any private data associated with the call at the Avaya IR port be provided. Currently this function supports User-to-User Information (UUI) and Universal Call ID (UCID).

Output • Private Data - A buffer that the CTI DIP will populate with private data associated with a

call.

(Type: char, size: up to 96 characters)

Input • Type - A constant that represents the type of private data that is requested

(Type: num)

0 = UUI

1 = II DIGITS (not currently implemented)

2 = UCID

• Call ID - The call ID of the current call at the Avaya IR port.

(Type: num)

• Vendor - The PBX vendor (for example, Lucent).

(Type: char, size: 32)

Return values

The return code indicates whether the CTI DIP successfully processed the message.

If successful, the result is 1.

On failure, the result is <=0, which indicates that no private data exists.

Usage notes

The information provided by this function is vendor specific. Currently, the only vendor private data that is implemented is per Lucent Technologies.

ctiPrivData


Universal Call ID (UCID) requires DEFINITY 6.3 or later and CentreVu CT 3.10 Version 2.0 or later.

Example

External Function

Function Name: ctiPrivData

Use Arguments: PDATA 0 CALLID "LUCENT"




ctiRetrieve

Description

ctiRetrieve requests that a held call at the Avaya IR port be retrieved.

Input • Call ID - Call ID of the held call

(Type: num)

Output • Error Code - Variable where the error code from the

CSTA_UNIVERSAL_FAILURE_CONF event will be populated (only if the operation fails)

(Type: num

Return values

The return code indicates whether the call was successfully retrieved.

If successful, the result is > 0, which indicates that the CTI DIP received a CSTA_RETRIEVE_CALL_ CONF event.

On failure, the result is <=0, which indicates that the call was not successfully retrieved.

Usage notes

This function is typically used only to recover from an error, for example, if the Avaya IR dials a busy number and the application needs to reconnect to the held party to inform them of the busy party.

Example

External Function

Function Name: ctiRetrieve

Use Arguments: cust_callid error


ctiTransfer


ctiTransfer

Description

ctiTransfer requests that two calls present at a Avaya IR port be connected.

Input • Call ID of held call - Call ID of held call

(Type: num)

• Call ID of active call - Call ID of active call

(Type: num)

Return values

The return code indicates whether the transfer occurred.

If successful, the result is >0, which indicates that the CTI DIP received a CSTA_TRANSFERRED_CALL_ CONF event.

On failure, the result is <=0, which indicates that the transfer failed to occur.

Usage notes

ctiTransfer requires that one of the calls involved in the transfer be on hold at the Avaya IR port prior to the execution of this function.

Example

External Function

Function Name: ctiTransfer

Use Arguments: cust_callid interp_callid



Designing applications that use Converse Vector Step (CVS) routing

To use the Converse vector step, you must:

• Set up parameters to facilitate data-passing from the switch within the framework of the application being developed.

• Define the data-return parameters to enable the Avaya IR system to send the collected data back to the switch.

IRAPI

It is possible to write an Intuity Response Application Programming Interface (IRAPI) application that is installed as a start-up service to collect calling party and/or called party information. This application sets the IRD_ANI and/or IRD_DNIS information elements before “exec’ing” the desired application via the number services tables. The irDial() and irGetInput() functions can be used to exchange data with the switch. For additional information about these capabilities, see Using IRAPI.


Designing VoiceXML applications

VoiceXML applications for Avaya IR present some unique application development considerations.



Object element interface Existing IVR installations have significant investments in older proprietary solutions. The Avaya IR system provides an interface to allow VoiceXML scripts to transfer control to a TAS script and back. The TAS script segment can be used to reach features of the IVR platform that can not be reached using web technology. It can also serve as a method of allowing the customers to migrate from TAS script to VoiceXML more slowly by allowing for hybrid VoiceXML/TAS applications.

This interface permits a developer to create a stub IVR Designer program that gets called from VoiceXML, and then immediately turns around and calls any one of the legacy DIPs or beyond-VoiceXML features of the Avaya IR system.

Some examples include:

• IC 6.0 functions

• 2B transfer, take-back-and-transfer, and ASAI call control

• Center Vu CTI functions

• GeoTel, Genisys, and other 3rd party DIPS

• Send FAX

• Arbitrary UNIX commands via exec UNIX function

Object element

The VoiceXML specification describes the object element as a method for exposing platform-specific functionality. In this case, the object element is used to transfer parameters and control to a TAS script via the IRAPI irSubProg() function. The TAS script can then perform actions on behalf of the VoiceXML script and return data to the VoiceXML script.

Object element interface


The following is an example object that is calling a TAS script called vxmlSubprog. It demonstrates passing parameters into the script and receiving information back from the script.

The custom Avaya object uses a classid attribute of com.avaya.subprog to specify the subprog action. The name attribute will be the returned data variable. Additionally, the subprog action requires an application name for the script to transfer control to. The object element uses param elements to pass information into the object. To get the application name, there must be a param element with the name application_name and a value string that is the name of an existing script/service to transfer control to. An error will be thrown in VoiceXML if the application_name parameter is missing.

Optionally, additional arguments can be passed in using addition param elements. To ensure the correct order of evaluation, the additional parameters must use a name of argN, where N will be the argument number in the range of 2 to 10. Argument 1, containing the name of the Avaya VXI process, is sent by the VoiceXML interpreter. The com.avaya.subprog object will automatically translate non-string arguments into strings for transmission to the script.

Ret2vxml external function

The child script must return to the parent at some point. If the script does not have any data other than a return value integer, then the script may call the quit instruction directly. If this is done, the objectname.retVal will contain the returned value. If the script needs to return data to the VoiceXML script, then it will need to call the external function Ret2vxml.t. The Ret2vxml accepts the following parameters:

Ret2vxml(VoiceXMLname, returnvalue, returnstring1, …, returnstring10)

Where:

• VoiceXMLname is the character string name passed to the child script as the first argument in the argument block.

• returnvalue is an integer value



• returnstring1 through returnstring10 are optional character strings that are returned to the VoiceXML application as ret1 to ret10.

Note that a return code of -1 will be sent to the VoiceXML application and the VoiceXML interpreter will disconnect the call if the call is terminated (the caller hangs up) during the execution of the script.

Example VoiceXML script

Object element interface


Example ScriptBuilder script

CallScript node

The CallScript node can also be used in a IVR Designer VoiceXML application to call and transfer data to a TAS application, which uses the Ret2vxml external function to return values to the VoiceXML application.



VoiceXML file locations VoiceXML (.vxml) and audio files can be located either locally on the Avaya IR system or remotely on a Web server.

Local application files

VoiceXML application files that are located locally, must be located in the /voice1/vxml/apps/appname/ directory where appname is directory name for all the files associated with a give application. Local files are referenced in VoiceXML documents using the file:// address type. For example, to reference the start.vxml file in the voice_it application, use the following address: file:///voice1/vxml/apps/voice_it/start.vxml.

Notice the three (3) slashes at the beginning of the address. Two of the slashes are part of the file:// address designation. The third slash is the beginning of the file location on the server (in this case, it designates the root level of the file system).

VoiceXML home directory

The home directory for the VoicXML feature is the /vs/data/vxml/ directory. This directory contains the following items:

• defaults.xml

• default.cfg

• vxmlFeatureTest.vxml

• default prompt files (audio) in the prompts directory

Web files

Files that are located remotely can reside anywhere on the Web (Internet or Intranet) as long as it is accessible from the Avaya IR system. Web files are referenced in VoiceXML documents using the http:// address type. For example to reference the start.vxml file on the VoiceIT Web site, use the following address: http://voiceIT.com/start.vxml.

For more information

See Administering VoiceXML.

VoiceXML audio file formats


VoiceXML audio file formats Avaya Voice Browser (AVB) supports standard audio formats for the Avaya IR platform. These formats are referenced in the default.cfg file as supported audio mime types.

AVB allows applications to use the following audio types:

• WAVE_FORMAT_MULAW (G.711)

• WAVE_FORMAT_PCM (Linear 8bit or 16bit at 8Khz)

• WAVE_FORMAT_ALAW

• audio/x-wav (Linear 8bit or 16bit at 8Khz)



Current issues with the Avaya VoiceXML feature There are two types of issues for this release of the Avaya VoiceXML feature:

• Considerations for application developers

• Unsupported features of the VoiceXML 2.0 specification

Considerations for application developers

Application developers should consider the following issues when developing VoiceXML applications:

• Redefining a variable that was set previously changes the value of the variable.

• Formats of data in the say-as tag must conform to the Text-toSpeech engine being used. See the appropriate vendor documentation for SSML and say-as tag support.

• session.connection.local.uri contains the same value as session.telephone.dnis.

• session.connection.remote.uri contains the same value as session.telephone.ani.

Unsupported features of the VoiceXML 2.0 specification

The following features of the VoiceXML 2.0 specification are not supported by the Avaya VoiceXML feature or are supported in a limited way:

• The DTMF termtimeout parameter is not supported.

• The record tag supports only the dtmfterm attribute. Recognition is not supported for record tag, so you can use only the modal=true attribute.

• The voice tag is not supported. To change gender, set the property promptgender in the defaults.xml file to either "male" or "female" to use the appropriate TTS voice.

• The xml:lang attribute is not supported for either the paragraph or sentence elements. To set the language used for TTS, set the xml:lang in either the vxml tag or the prompt tag.

• Only DTMF grammars are supported inside the transfer tag.

• The transferaudio attribute of the transfer tag is not supported.

• The maxtime_disconnect return value of the transfer tag is not supported.

• The Maxspeechtimeout event is not supported.

• The only valid value for the bargeintype attribute for any tag is speech.

• The error.unsupported.language, and maxspeechtimeout events are not supported.

Current issues with the Avaya VoiceXML feature


• The bargeintype, fetchaudiodelay, fetchaudiominimum, maxnbest, maxsppechtimeout, universals, *maxstale, and *maxage properties are not supported.

• The accept attribute for menu and option tags only supports exact.

• Use session.telephone.uui instead of session.connection.aai.

• session.connection.redirect is not supported.

• session.connection.originator is not supported.

• An undefined expression in the audio tag is not ignored.

• Multi-lingual ASR is not supported in this release.


Designing applications that use Siebel eBusiness Integration

Designing applications that use Siebel eBusiness Integration provides information about integrating voice response applications with Siebel eBusiness.



Introduction to Siebel eBusiness Integration Introduction to Siebel eBusiness Integration describes how to create applications for Avaya IR that can exchange data with Siebel eBusiness products.

The descriptions in this section assume:

• Familiarity with Siebel eBusiness (setup, administration, and use).

• Familiarity with Avaya IR application development, preferably using IVR Designer.

• Familiarity with the Extensible Markup Language (XML).

Any Avaya IR system running an application to interface with Siebel eBusiness needs to have Gold Systems Vonetix version 2.1 or higher loaded on the system.

Basic concepts

Applications on Avaya IR exchange information with Siebel eBusiness databases using XML documents. This is facilitated by Vonetix middleware on Avaya IR and the Business Integration Manager on Siebel eBusiness.

Vonetix enables the application to read, create, and send XML documents from Avaya IR. The Business Integration Manager manages the translation and transfer of XML documents within Siebel eBusiness, and accesses Siebel eBusiness databases using abstract objects that encapsulate the data of interest.

If the Computer Telephony Integration (CTI) feature is being used, then a call can be passed to the Siebel operator from Avaya IR. Information inserted by the application into the UUI field will then automatically be transferred to the Siebel eBusiness Desktop (as a "screen pop").

Creating an application

There are several basic steps involved in creating an application on Avaya IR to access and/or send data to a Siebel eBusiness database. These steps provide the basic organization of this guide for application developers:

1. Identify which data will be transferred from Siebel eBusiness to Avaya IR.

2. Identify which data will be transferred from Avaya IR to Siebel eBusiness.

3. Create a Siebel integration object that represents the data of interest.

4. Create a workflow within Siebel eBusiness that manages the exchange of information between Siebel eBusiness and Avaya IR.

5. Use Siebel eBusiness to generate a document type definition (DTD) for each integration object.

Introduction to Siebel eBusiness Integration


6. Use the DTD to generate a document type definition (DTD) for each integration object.

7. Create the Avaya IR application using IVR Designer. The application uses the XML template to generate an XML document which is sent to Siebel eBusiness.

Identifying data to be transferred

An application on Avaya IR will be doing one or both of the following:

• Querying Siebel eBusiness for information in a Siebel database (retrieve data from Siebel eBusiness).

• Updating a Siebel eBusiness database (send data from Avaya IR to Siebel eBusiness).

The first task for the application developer is to decide what data is of interest, and where it is.

Data on Siebel eBusiness

Data on Siebel eBusiness resides in standard database files, organized according to what Siebel calls the "Siebel Data Model".

The data is accessible through object-oriented software. The software enables a user to group related data from various parts of the database into a "business object" which can be treated as a unit.

Example: Names, occupations, and ages could be manipulated together as a "People" object. To get someone's name, the application would need to access the People object.

Data of interest may reside in several business objects.

When creating an application, it is important to identify the business object(s) that have data that will be queried and data that will be updated.

Data on Avaya Interactive Response

Data on Avaya IR can be:

• Collected directly from a caller (in a "prompt and collect" operation).

• Associated with the call (such as ANI or DNIS).

• Stored in a database.



• In a file.

Setting up Siebel

To access business objects, Siebel's Business Integration Manager uses a Siebel eAI (eBusiness Application Interface) Adapter, which translates business objects or some of their components into "integration objects" that can be used to create XML documents. Information can also go the other way: integration objects can be translated into business objects or some of their components through the eAI Adapter. Note that parts of several different business objects can be included in a single integration object.

The management of data within Siebel eBusiness is done using "workflows", which are customizable processes and rules. They control access, assembly, and distribution of integration objects. A workflow can deal with queries, updates, or both.

XML documents are exchanged with external applications (on a Avaya IR) via HTTP using the Business Integration Manager's XML Gateway and HTTP Gateway.

See the Siebel 2000 Bookshelf for more information.



Integration objects

Integration objects, like business objects, are made of components, which themselves are made of fields, as shown in the illustration. This is comparable to the parent-child-data relationships found in XML.

Siebel eBusiness has the ability to create integration objects using the Integration Object Builder through Siebel Tools (see the Siebel 2000 Bookshelf: Siebel Integration Guide for instructions).

Workflows

Workflows need to be created to enable the proper operations to be done within Siebel eBusiness. One or more workflows may be used, depending on the customer's needs.

A sample workflow for a query is shown in the following illustration. In this workflow, an XML document is received from Avaya IR, a Siebel database is queried, and an XML document is prepared and sent to Avaya IR.

The the following illustration shows a sample workflow for an update. In this case, data is inserted into a Siebel database after Siebel eBusiness receives an XML document from Avaya IR. An XML document is prepared and sent to Avaya IR.

The Siebel Workflow Guide in the Siebel Bookshelf describes how to set up workflows.

Document Type Definitions

XML files are generally used to transport data across networks using Hypertext Transfer Protocol (HTTP). Document type definitions (DTDs) provide information about how XML documents are formed.

Siebel eBusiness has the equivalent of a DTD for every integration object, which it uses to create outgoing XML documents and to decide whether incoming XML documents have the proper format (the documents are "validated" by Siebel eBusiness). Avaya IR does not use DTDs at all, but DTDs generated by Siebel eBusiness can be used to construct Avaya IR applications which will be able to send and interpret XML files.

To create a DTD, generate a schema for the integration object within Siebel eBusiness.

In the examples below, separate integration objects exist for query and update operations. Note that this may be the case more often than having one DTD for both operations:

Sample query DTD





<!ELEMENT BubbaAccountDetail (FincorpAccount+) >

<!ELEMENT FincorpAccount (AccountNumber?,

RelationshipLimit?,

CurrentBalance?,

LastName?)>



<!ELEMENT AccountNumber (#PCDATA) >

<!ELEMENT RelationshipLimit (#PCDATA) >

<!ELEMENT CurrentBalance (#PCDATA) >

<!ELEMENT LastName (#PCDATA) >

Sample update DTD



<!ELEMENT BubbaFundsTransferSr (FundsTransferSR+) >

<!ELEMENT FundsTransferSR (ContactFinancialAccounts?,

ContactLastName?,

FundsTransferFromAccountNumber?,

FundsTransferToAccountNumber?,

FundsTransferDollarAmount?,

TransactionId?,

SRNumber?)>

<!ELEMENT ContactFinancialAccounts (#PCDATA) >

<!ELEMENT ContactLastName (#PCDATA) >

<!ELEMENT FundsTransferFromAccountNumber (#PCDATA) >

<!ELEMENT FundsTransferToAccountNumber (#PCDATA) >

<!ELEMENT FundsTransferDollarAmount (#PCDATA) >

<!ELEMENT TransactionId (#PCDATA) >

<!ELEMENT SRNumber (#PCDATA) >

The DTD is used by the application differently for reading incoming documents and creating outgoing documents. Every XML document must match the element definitions given in the DTD.



• For XML documents being received by Avaya IR, the element names need to be known so that the application can parse the document and extract the data.

• For XML documents being sent by Avaya IR, an XML template can be created separately by the developer, which is then used to build the XML documents that will be sent. The documents are always populated with data. For queries, this data will typically be a key field. Updates include data that will be put into a Siebel database.

XML templates


XML templates XML documents sent from Avaya IR to Siebel eBusiness, whether they be for queries or updates, can be constructed using XML templates that derive from the DTDs supplied by Siebel eBusiness for the related integration objects.

As mentioned in Setting up Siebel, a DTD provides the application developer with the structure of the XML document that Siebel eBusiness expects. Of principal importance are:

• Element names.

• Element order.

• Data types.

A template has two main features:

• A header, which tells Siebel eBusiness which integration object is being addressed.

• A body of tag pairs, each having either no content or reusable content.

Interpreting DTDs

Following is a brief discussion of how to interpret DTDs.

The structure of a DTD can be seen by example:



<!ELEMENT BubbaFundsTransferSr (FundsTransferSR+) >


ContactLastName?,




TransactionId?,

SRNumber?)>

<!ELEMENT ContactFinancialAccounts (#PCDATA) >

<!ELEMENT ContactLastName (#PCDATA) >



<!ELEMENT FundsTransferFromAccountNumber (#PCDATA) >

<!ELEMENT FundsTransferToAccountNumber (#PCDATA) >

<!ELEMENT FundsTransferDollarAmount (#PCDATA) >

<!ELEMENT TransactionId (#PCDATA) >


The first two lines



are the header. The Siebel header will not be used in the XML template.

The remainder of the DTD defines the elements expected in the body of the XML document. Each line is called an "element declaration", as identified by the !ELEMENT label.

An element declaration typically has two parts:

1. The name of the element, identified by a tag.

2. A description of the element's contents (enclosed in perentheses).

In the example,


SRNumber is the element name, and #PCDATA describes the contents as parsed character data.

Slightly more complicated is the line


ContactLastName?,




TransactionId?,

SRNumber?)>

In this case, the contents of the element are a set of child elements, where each child's name is separated by a comma. Note that a "?", "*", or "+" following a child name indicates the number of instances of the element that are allowed (zero or more instances can be present between tags for "?" or "*"; zero or more instances must be present for "+").

XML templates


Creating the template

The XML template will need to be created and stored as a file on the Avaya IR. A header naming the integration object will need to be added to the tag pairs (start and end tags) derived from the DTD. The header takes the form

<SiebelMessage MessageID="" MessageType="IntegrationObject" IntObjectName="IntegObjName">

Where IntegObjName is the name of the integration object.

The DTD example shown above would be translated into the following template:

<SiebelMessage MessageID="" MessageType="IntegrationObject" IntObjectName="IntegObjName">

<BubbaFundsTransferSr>

<FundsTransferSR> <ContactFinancialAccounts></ContactFinancialAccounts>

<ContactLastName></ContactLastName> <FundsTransferFromAccountNumber></FundsTransferFromAccountNumber>

<FundsTransferToAccountNumber></FundsTransferToAccountNumber>

<FundsTransferDollarAmount></FundsTransferDollarAmount>

<TransactionId></TransactionId>

<SRNumber></SRNumber>

</FundsTransferSR>

</BubbaFundsTransferSr>

</SiebelMessage>

When using the template to update a Siebel eBusiness database, the Avaya IR application will populate the elements with data.

Queries and updates


Queries and updates Avaya IR communicates with Siebel eBusiness using a plug-in that is part of the Vonetix middleware by Gold Systems. An application on Avaya IR can make function calls to Vonetix that

• Prepare and send outgoing XML documents.

• Receive and process incoming XML documents.

What Siebel eBusiness actually receives from Avaya IR is a set of "form data" that includes the original XML document on Avaya IR along with special information that tells Siebel eBusiness what to do.

The Vonetix interface

Information flow between an application and Siebel eBusiness is facilitated by specialized Vonetix functionality.

The Vonetix interface consists of the following parts:

• Java Gateway DIP.

Applications communicate directly with this data interface process, which uses TCP/IP to pass information to the Vonetix Gateway.

• Vonetix Gateway.

This gateway sends requests to the Mini-Browser based upon information received from the DIP.

• Mini-Browser.

The Mini-Browser is where XML documents are interrogated and modified, and HTTP requests are sent to the Base Servlet.

• Base Servlet.

The Base Servlet receives HTTP requests from the Mini-Browser via the Web Server and Tomcat Servlet, then relays them to the Document Plug-In, tracking them by unique session names and cookies.

• Document Plug-In.

The Document Plug-In relays HTTP requests and XML documents between the Base Servlet and Siebel eBusiness.



Vonetix provides TAS functions to support the Document Plug-In, the "Generic TAS Functions" and "Utilities TAS Functions" (see the latest Vonetix Technical Training Guide or Data Channel Guide for a detailed listing with descriptions and code examples).

Performing queries and updates

There are basic steps performed by a Avaya IR application for queries and updates.

Note that the Vonetix functions discussed in the steps below, unless otherwise mentioned, will return a 0 if successful, or a negative number if unsuccessful. See the Vonetix Return Code Table in the applicable Vonetix Technical Training Guide or Data Channel Guide.

1. Prepare the original XML document.

a) Load the XML template.

Use the Vonetix vntxLoadDoc(SESSIONNAME, FILENAME) function, where the argument FILENAME includes the path to the template from the root directory.

b) Add content to one or more elements in the document.

This involves using the Vonetix vntxSetTag (SESSIONNAME, TAGNAME, TAGNUMBER, TAGVALUE) function for each element identified by the arguments TAGNAME and TAGNUMBER. The content of the element is substituted for TAGVALUE .

2. Prepare form data for the HTTP request.

HTTP request form data is used to log on to Siebel eBusiness, identify the XML document, and tell Siebel eBusiness what to do.

This form data consists of one or more fields that are logically tied together by a session name, and are each created using the Vonetix vntxSetFD(SESSIONNAME, FIELDNAME, FIELDVALUE) function, where the argument FIELDNAME is the field's name, and the argument FIELDVALUE is the field's value.

Each of the following fields needs to be defined:

― SWEExtSource

The workflow name (Business Service Source), found in the Siebel eBusiness config file.

― SWEExtCmd

The command to be executed by Siebel eBusiness. The most commonly used command is likely to be Execute .

Queries and updates


― UserName

The login name.

― Password

The login password.

3. Convert the original XML document into an encoded form data value.

The XML document must itself be turned into form data before being sent by Vonetix. The Vonetix VntxSetDocFD ( SESSIONNAME, name ) function does this, where name is "SWEExtData".

4. Send the form data.

The form data sent to Siebel eBusiness consists of the XML document created from the XML template, coupled with the HTTP request form data that was created in Prepare form data for the HTTP request.

Use the Vonetix vntxPostDoc(SESSIONNAME, URL) function, where the argument URL is the URL of the Website with the Siebel eBusiness data.

An error code will be returned by Vonetix if Siebel eBusiness has not responded within 20 seconds of the HTTP request.

5. Save the incoming XML document. (This step is optional, usually for debugging purposes.)

Siebel eBusiness will respond to the POST command by sending a document to Avaya IR. The received document can be saved regardless of whether the Avaya IR application is doing a query or an update.

Use the Vonetix vntxStoreDoc(SESSIONNAME, FILENAME) function, where the argument FILENAME refers to the path and name you choose for the file that will be stored.

6. Process the received XML document.

Extract the content of each element of interest. This will certainly be done during a query, but may also be done after an update.

Use the Vonetix vntxGetTag(SESSIONNAME, TAGNAME, TAGNUMBER, TAGTEXT) function. TAGTEXT is the name of the variable that will store the content.

7. Clear form data.

After performing a query or update, the form data encoded XML document and/or HTTP request form data may need to be cleared. This action will not remove data saved in variables and stored XML documents.

― Use the vntxClearSes(SESSIONNAME) function to clear both the XML document and HTTP request form data.



― Use the vntxClearDoc(SESSIONNAME) function to clear just the form data encoded XML document.

― Use the vntxClearFD(SESSIONNAME) function to clear just the HTTP request form data.


Index

A A single touchtone and speech recognition application • 36 About this document • 5 Announcements • 19 Application errors • 31 Application examples • 34 Application usability • 14 ASAI application types • 128 ASAI versus the converse vector step • 132 Avaya Interactive Response system application design •

133

B Background information • 85 Barge-in • 69, 71 Barge-in and NLSR • 77 Bilingual applications • 41 Bilingual capabilities • 64 Bilingual, multilingual, and non-US English applications •

41

C Call flow examples • 143, 146, 148, 153 Call-flow design • 142 Comparison of recognition types • 82 Confirming digit entries with callers • 26 Connected-digit recognition types • 66 Creating the template • 207 ctiCallInfo • 170 ctiCallState • 172 ctiConfer • 174 ctiDial • 175 ctiDiscon • 176 ctiHold • 177 ctiNotify • 178 ctiPrivData • 180 ctiRetrieve • 182 ctiTransfer • 183 Current issues with the Avaya VoiceXML feature • 194 Custom DIPs • 72 Custom grammars • 67, 71 Custom vocabulary • 72

D Data on Avaya Interactive Response • 199 Data on Siebel eBusiness • 199 Designing applications that use ASAI • 127 Designing applications that use Computer Telephony

Integration (CTI) • 169

Designing applications that use Converse Vector Step (CVS) routing • 132, 185

Designing applications that use Siebel eBusiness Integration • 197

Designing applications that use speech • 47 Designing voice response applications • 11 Designing VoiceXML applications • 187 Determining the transaction • 54 Developing speech • 54 Dial through and barge-in • 39 Digit input • 23 Document Type Definitions • 202 Dual Tone Multifrequency (DTMF) support • 69, 71

E EBS formats • 49, 57, 61, 89 Editing speech • 59, 62 Enhanced Basic Speech formats • 84 Entering digit sequences • 23

G Getting the most out of Text-to-Speech • 81

H Host application planning and design • 150 How to get the most out of Text-to-Speech • 44 How to test Text-to-Speech applications • 45 How WholeWord speech recognition works • 63

I Identifying data to be transferred • 199 Integration objects • 201 Interpreting DTDs • 205 Introduction to Siebel eBusiness Integration • 198

K Keyword recognition types • 65

L Languages available • 84

M Menus • 21 Modify a touch-tone-only application to include spoken

input • 38 Multilingual applications • 42

O Object element interface • 188 Overview of designing voice response applications • 13

P Pace the application • 30 Performing queries and updates • 210

Index


Phrase screening • 68 Planning the voice script • 55, 59 Prompts • 17 Putting it together • 81

Q Queries and updates • 209

R Recognition confirmation • 69 Recognition DIPs • 68 Recognizer differences between touch-tone input and

spoken input • 33 Recognizing WholeWord speech input • 63

S Selecting a speech development method • 58 Separate touchtone and speech recognition applications •

35 Setting up Siebel • 200 Speech development tools and features • 51 Spoken input for yes/no questions • 28 Standard WholeWord speech recognition types • 64

T Text-to-Speech in applications • 43 The speech filesystem • 48 The Vonetix interface • 209 Touch-tone and speech recognition • 33 Touch-tone input for yes/no questions • 27 Touchtone input used with spoken input • 35

U Use both Text-to-Speech and prerecorded speech

prompts and announcements • 43 Use Text-to-Speech for prompts and announcements • 43 Use touch-tone input when speech recognition fails • 37 Using ASAI in a call center • 139 Using NLSR external functions in an IVR Designer

application • 78 Using NLSR in voice applications • 75, 77 Using NLSR with other features • 81 Using Text-to-Speech and prerecorded speech together •

81 Using WholeWord and Natural Language Speech

Recognition together • 82

V Validate a digit sequence entry • 25 VoiceXML audio file formats • 193 VoiceXML file locations • 192

W WholeWord speech recognition accuracy • 72 Word spotting • 68

Workflows • 201 Writing the voice script • 56, 59

X XML templates • 205

Y Yes/no question without barge-in • 28 Yes/no questions • 27 Yes/no questions with barge-in (WholeWord speech

recognition) • 28

avaya™ interactive response · 2002-11-12 · intervention hotline at +1 800 643 2353 for the...

Documents