AT&T 585, 350, 812 User Manual

Table of Contents

585-350-812
Issue 1
October, 1993

Conversant VIS

Adjunct Switch Application

Interface

Graphics ©

Blank Page

Contents

Table of Contents i

1 ASAI Overview 1-1

■ Overview of the Adjunct/Switch

Application In terface Feature 1-1

ASAI Voice Response Applications 1-2
Routing Applications 1-4
Data Screen Delivery Applications 1-5
Advantages Using the VIS ASA I Feature 1-8

2 ASAI Applicatio n Planni ng and Design 2-1

■ AS AI Ap plication Planning and Design Overview 2-1

■ AS AI Application Planning and Design 2-1

■ VI S Script Design 2-2

ASAI Voice Script Design 2-3
Routing Script Design 2-5
Monitoring Script Design 2-7

■ VIS-to-Agent Transf e r s 2-9

■ Agent-to-Agent Transfe r s 2-11

Blin d Transfer 2-13
Consult Transfer 2-15

■ Host Application Planning and Design 2-18

ASA I Voice Response Applicat ion Considerations 2-19
Routing Application Considerations 2-19
Data Screen Delivery Application Considerations 2-20

■ Communications System Planning 2-22

■ Call Center Operations Planning 2-23

3 ASAI Installation 3-1

■ Installatio n O verview 3-1

Issue 1 Octob er 1993 iii

Contents

■ Prerequisites for ASAI Installat ion 3-2

■ ASAI Hardware Architecture 3-3

■ Installin g ASAI Hardware 3-4

■ Installing A SAI Software 3-6

■ Removing the ASAI S oftware 3-8

4 ASAI Administration 4-1

■ ASAI Administration Overview 4-1

■ Channel Administration 4-5

Ad d Channel Entry 4-8
Change Channel Ent r y 4-9
Remove Channel Entry 4-10
Virtual Channel Administrat ion 4-10

■ Diagnose IPCI Board 4-13

■ Domain A d m inistration 4-14

Ad d Domain Entry 4-18
Change Domain Entry 4-19
Remove Domain Entry 4-19

■ Initialize IPCI Board 4-20

■ Paramet er A dmi nistration 4-21

■ Show ASAI Software Version 4-24

■ Show Status A SAI Link 4-25

■ Take IPCI Board Off-line 4-27

5 Admi ni st e ri ng ASAI 5-1

■ ASAI Administration Overview 5-1

■ Ad m inist ering t he Lines 5-2

■ Administering the VIS ACD Split Domain 5-2

■ Ad m inist ering t he VIS A g ent Lines 5-4

iv Issue 1 October 1993

Contents

6 ASAI Script Builder Actions 6-1

■ ASAI Script Builder Actions Overview 6-1

Defining A_Callinfo 6-2
Defining A_Event 6-4
Defining A_RouteSel 6-11
Defining A_Tran 6-14

A Sample Scripts A-1

■ Sample Scripts Overview A-1

Sample ASAI Voice Script A-2
Sa mple Rout ing Script A-4
Sample Monitoring Script A- 6

B Sample Scripts C-1

■ ASAI Perf ormance Performance Overview C-1

Voice Respons e Integration C-2
Data Screen Delivery C-2
Routing Applications C-2

Issue 1 October 1993 v

Contents

vi Issue 1 O ctober 1993

ASAI Overview

Overview of the Adjunct/Switch Application Inte rface Feature

The AT&T Adjunct/Switch Application Interface (ASAI) is an optional package that
may be installed on top of the standard CONVERSANT Voice Information System
software. Instructions for installing the Ad junct/ Swit ch Appl icati on Interfa ce are
provided in Chapter 3, "ASAI Installation".

The AT&T Adjunct/S wit ch Applicati on Int erface provides an Integ rated S ervices
Digital Network (ISDN)-based interface betwee n AT&T PBX’s and adjunct proces­sors.The VIS ASAI feature supports this application interface for communicat ion s
with the AT&T DEFINITY Communications System, Generic 3i (hereafter referred
to as DEFINITY Generic 3i).This digital signaling inte rface allows the VIS to moni­tor and route calls on the DEFINITY Generic 3i switch. When used in conjunction
with standard Tip/Ring (T/R) or Line Side T1 (LST1) interfaces, the ASAI interface
allows the VIS to monitor and control cal ls delivered to a T/R or LST1 channel on
the VIS.

1

Access to ASAI capabilities is provided through the Script Builder application gen­eration language. Access to ASAI capabilit ies at the Script Bu ilder level m ini­mizes the effort required to implement ASA I-based applicat ions. For example,
there is no need to receive, parse, and process individual, lower-level ASAI mes­sages. Additional Script Builder actions give the script designer high-level access
to ASAI capabilities. These ASAI capabilities can be used to design the following
types of applications.

These types of applications are discussed later in this chapter.

■ ASAI Voice Response Applications

■ Routing Applications

■ Data Screen Delivery Applications

1-1

ASAI Overview

These types of applications can run simul taneously o n a VIS. This implies tha t a
VIS ASAI system provides co-resident voice response and PBX-to-host gateway
capabilities. A single call, for instance, may first be routed by the VIS, handled
with a voice response application on the same VIS, and then be monitored by the
same VIS as the call is ultimately delivered to a live agent.Furthermore, integra­tion of the voice response and monitoring capabilities allows screens delivered by
the host to agents receiving calls to be based on data collected in a voice
response script.

ASAI Voice Response Applications

In ASAI voice response applications, incoming calls are routed to the VIS over T/
R or LST1 channels which are configured as an Automatic Call Distribution (ACD)
split on the DEFINITY Generic 3i switch as depicted in Figure 1-1.

Channel

0
1
2
3
4
5

System Monitor - Voice Channels

Calls
Today

1
1
3
1
0
10

Voice
Service

appl2
appl4
appl7
appl3

Service
Status

Talking
Collect

Transfer
DB

*MANOOS

Talking

Caller
Input

8509

7328

Dialed
Digits

5312

CHG-KEYS HELP PREV-PAGENEXTPAGE PREV-FRM NEXT-FRM CANCEL CMD-MENU

1-2

Figure 1-1. ASAI Voice Response App lications

ASAI Overview

As a call is delivered to the VIS, the VIS receives ASAI information relat ed to the
call. The ASAI feature allows the VIS to recognize the dialed (called) number of
an incoming call to a line. This feature is sometimes referred to as Dialed Number
Information Service (DNIS). In addition, the ASAI feature allows a service the
ability to retrieve the calling party’s number. This feature is sometimes referred to
as Automatic Number Ide ntificat ion (ANI). This information is used to control
which voice application is used for the call. The ASAI information relat ed to the
call is also made available to the specific voice application which interacts with the
caller. In addition, the call control capabilities of ASAI can be used to transfer the
call away from the VIS if the caller needs to speak to a live agent. The following
capabilities are therefore provided for ASAI voice response applicati ons:

■ DNIS Service (T/R or LST1 Channel Sharing) —- The DNIS information

associated with the incoming call is used to select a particular Script
Builder script to service the call. This allows a T/R or LST1 channel to be
shared across many applications. Prior to this capability, T/R or LST1
channels were dedicated to specific Script Builder Applications. With chan­nel sharing, the same number of cha nnels can handle more cal ls while
maintaining the same grade of service. Alternatively, the same number of
calls can be handled at a higher grade of service.

■ Call Information — Once the call is answered by the VIS, the ASAI informa-

tion related to the call such as ANI and DNIS can be retrieved for use in the
voice script handling the call.

■ Enhanced Transfer — The use of ASAI call control capabilities allow s the

transfer to be faster, quieter (from the caller’s perspe ctive), and more reli­able. In addition, the DEFINIT Y Generic 3i ASA I direct agent calling fe a­ture can be used to transfer the call to a direct agent. This allows the call to
be delivered to a specific agent while maintaining accurate ACD split statis­tics. Calls placed to specific agents without the direct agent calling feature
do not count as ACD calls in calculating and report ing AC D split statist i cs.
Finally, data captured in the voice script can be saved and associated with
the transferred call. This enables a host application to deliver to agents
data screens which are based on data collected by the voice script which
previously serviced the caller.

The availability of ANI within the voice script permit s the design of unique voice
response applications. Example s include:

■ Locator Service — A local or host database could be used to determine the

closest car dealers, Automatic Transact ion M achines, stores, etc.

■ Weather Reports — Provide a weather report for the callers area.

■ Pay-Per-View — A cable company could use ANI to automate custom er

selection of pay-per-view programs.

1-3

ASAI Overview

■ Caller Dependent Transfers — The full ten-digit ANI could be used to iden-

tify callers and determine where they should be transferred if they need to
speak to a live agent. This would be 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

could be used to determine where callers should be transferred if they
need to speak to a live agent. This would be desirable if, for instance,
agents handle calls from specific geographic regions.

Routing Applicatio n s

In routing applications, the VI S is used as a routing server to support the routing
capabilities of ASAI and the call vectoring feature on the DEFINITY Generic 3i.
However, on receiving a routing request, as depicted in Figure 1-2, a routing
application on the VIS receive s and responds to call rout ing requ ests sen t by the
DEFINITY Generic 3i.

Note that you are not always required to have the T/R or LST1 lines on the VIS for
routing application s. However, T/R or LST1 lines are required to route the call to
the VIS agents.

1-4

Figure 1-2. ASAI Routing Application route.pic

ASAI Overview

These call routing requests are generated by the DEFINI TY Generic 3i when a
call is processed by specific call vecto rs on the DEFINITY Generic 3i.

Information as to where calls should be routed may reside on the VIS in a local
database or may be provided by a host to which the VIS is connected. Call routing
would typically be based on ANI or call prompting data collected by the DEFINITY
Generic 3i.

The use of routing capabilities can significantly improve the efficiency of a call
center environment. Examples of routi ng u ses incl ude:

■ Priority Service — Important or “priorit y” callers such as large clients can

be given priority treatment. A priority caller can be routed to a common
agent group but queued at a higher priority so that they are serviced faster.
Alternatively, the priority ca ller can be routed t o a specific agent which nor­mally handles their transactions.

■ Call Redirection — Callers dialing into a particular call center applicat ion

can be redirected to other call center applications. For example, callers
who have delinquent accounts can be redirected to a collections depart­ment when they call a sales department.

■ Call Screening - Fraudulent callers can be disconnected without being con-

nected to an agent so that no network costs are incurred.

■ Geographically Based Service - In cases where service is provided on are

regional basis, callers can be routed to the agent group responsible for
their region.

Data Screen Delivery Applicat ion s

In data screen delivery applications, a host application delivers a data screen that
is specific to a caller or dialed number to an agent at the same time a voice call is
delivered to the agent’s telephone. This reduces both the agent time and network
time required to service the caller. The reduction in per-call service time trans­lates directly into cost savings. Data screen delivery applicati ons are also known
as “coordinated voice/data screen delivery” or “screen pop” applications. A data
screen delivery application is depict ed in Figure 1-3.

1-5

ASAI Overview

Figure 1-3. D ata Screen Delivery Applications gateway.pic

Note that the delivery of data scree ns is not a function of the VIS itself. A special
host application is developed by yo ur company or a third party to perform this
function. The VIS acts as a communicati ons gatew ay between the DEFINIT Y
Generic 3i and the host computer. A monitoring appl icati on on the VIS provides
the ability to track the st atus of calls on the DEFINITY Generic 3i. This monitoring
application receives information about calls delivered to live agents and forwa rds
this information to the host application. The host application in turn uses this infor­mation to deliver a data screen to the agent receiving the call.

The information made available to the host includes which agent receives a partic­ular call and the ASAI information associated with the call such as ANI, DNIS, and
any DEFINITY Generic 3i call prompt ing inform ation collecte d from the caller. In
addition, the call may have been serviced by a VIS voice script and then trans­ferred to a live agent. In this case, information collected in the voice script can be
saved and then passed to the host at the time the call is delivered to the agent.
Monitoring appli catio ns on the VIS can therefore be used to support data screen
delivery for three different call flow scenarios as described below:

■ VIS-to-Agent Transfers — In this call flow scenario, calls are initially deliv-

ered to the VIS and then transferred from the VIS to a live agent. Data
screens delivered to agents in this scenario can be based on information
collected in a voice script in addition to ASAI information such as ANI,
DNIS, and call prompting informat ion collect ed by the DE FINIT Y Ge neric
3i.

1-6

ASAI Overview

■ Incoming Call Delivered Directly to Agent by ACD — In this call flow sce-

nario, incoming trunk calls are delivered directly to live agents. Here, data
screens delivered to agents would be based primarily on ANI, DNIS, and/or
call prompting informat ion. Data scree ns would not be based on data col­lected in a voice script since a VIS voice script is not used to collect data
from the caller.

■ Agent-to-Agent Transfe rs - In this call flow scenario, calls are transferred

between live agents. Here, for example, “screening” agent s may be used
to collect information from the caller and handl e simple transactions. The
call may subsequently be transferred to “specialized” agents who can han­dle more complex or detailed transaction s. In these scenarios data
screens can be based on information keyed in to the host applicati on by
live agents. The host application can save data collected and entered by a
screening agent and the n use this data as the basis for data screens deliv­ered to more specialized agents who may receive the call. Note that the
information available for the other two call flow scenarios (that is, ANI,
DNIS, call prompting information, and voice script data) is available in this
scenario as well. This information may be used in conjunct ion wit h data
entered by a live agent to provide the basis for data screens.

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

This ability to save voice script data may be used for many reasons. A voice script
can be used to collect a variety of information such as account numb er, social
security number, personal identificati on numb er, desired service, etc. In many
cases, this type of information is more meaningf ul and useful than ASAI info rma­tion such as ANI to the host application and the live agents handlin g calls. Also,
the voice response application might be the primary appli ca tion providing, for
example, an automated banking application. Here, live agents are used only as a
backup to answer questions beyond the scope of the voice response application.

The ability to save voice script data with the enhanced transfer capability provides
a very useful bridge between voice response and data screen delivery applica­tions. This capability provides true integrat ion (in addition to co-residency) of the
voice response and PBX-to-host gateway capabilit ies off ered wit h the V IS ASA I
feature. This mechanism for embedding voice script data in call event information
for the transferred call can significantly reduce the complexi ty of the host applica­tion. Without this mechanism , the host application is typically required to associ­ate information from two different physical interfaces (one interface from the voice
response unit to receive data collected from the caller and anoth er interf ace from
the monitoring device over which call events are received). Also, the host appl ica­tion is typically required to track and associate multiple events for multiple calls

1-7

ASAI Overview

(the initial incoming call to the voice response unit and the second, transferred call
which is delivered to an agent). With the VIS ASA I feature, a single me ssag e to
the host over a single interface provides all the informati on needed to deliver a
data screen based on data collected in a voice script.

Advantages Using the VIS ASAI Feature

The VIS ASAI feature can greatly improve the operations in your call center envi­ronment. The capabiliti es that this feature offers pro vide the f ollow ing benefit s to
any company that receives customer calls:

■ Enhanced Custom er Servi c e

Caller-dependent and region-dependent treatment for incoming calls is
possible in routing and voice response applications. In addition, the direct
agent calling feature available with these applications allo w s calls to be
delivered to specific agents while maintaini ng a ccura te split measure­ments. These capabilities help to insure that calls are quickly and reliably
directed to the call center resource best suited to handle them . This mini­mizes the number of transfers a caller experiences and allows callers to be
serviced in a rapid, consistent, and personalized fashion and thereby
improves customer satisfaction.

In data screen delivery applications, information associat ed with a given
call is available to each agent receiving the call. This reduces customer
frustration at having to repeat inf ormati on to each agent . For example, a
caller may be directed initial ly to a VIS T/R or LST1 channel where the
caller is prompted through an automated voice response appli catio n. At
some point the caller may request to be transferred to a live agent to dis­cuss a topic in more detail. With the VIS ASAI feature, the identity of the
caller and additional information collected from the caller by the voice
response application is not lost. Pertinent inform ation from the voice
response application can be saved and presented in a data screen to the
live agent receiving the transferred call, thereby el iminat ing th e need for
the customer to repeat information already collect ed. This reduces call
holding time as well as reduces customer frustration. This benefit holds
true even when calls are transferred multiple times or are transferred
between live agents.

■ Improved Price/Performance

The co-residency of voice response and PBX-to-host gateway applications
greatly improves the price/perform ance of the VIS ASAI feature over prior
and competitive offeri ngs. The VIS ASA I feature eliminat es the need fo r
multiple boxes with multiple interfaces to the host computer, thereby simpli­fying host application developm ent . Access to ASAI capabilities using
Script Builder minimizes the ef fort required to impleme nt the VIS piece of

1-8

ASAI Overview

the overall VIS/host applicat ion. In addition, the use of DNIS in voice
response applications to enable T/R or LST1 channel sharing means that
more calls can be serviced with the same number of VIS channels.

■ Reduced Cost of Doing Business

The use of data screen delivery applications reduces the t ime needed to
service calls. This is because the host screen application is ready to pro­vide or accept information at the same time the agent begins to speak with
the caller. The reduction in per-call service time translate s directly into
reduced network costs and reduced agent costs. 800 network charges are
lower because calls are shorter. The same number of agents can handle
an increase in call volume since per-call service time is reduced. Also, cer­tain calls can be eliminated entirely via the use of routing applications (for
example, call screening for the identi ficat ion of fraudulent calls). In this
case, no network costs are incurred for the call and no agent time is wasted
on the call.

1-9

ASAI Overview

1-10

ASAI Application Planning and Design

ASAI Application Planning and Design Overview

This chapter contains inform ation on planni ng and designi ng an applicat ion that
will be used with the AT&T Adjunct/Switch Applica tion Interface (ASAI) feature on
the CONVERSA NT Voice Inf orm ation Syst em (V IS).

ASAI Application Planning and Design

2

Access to ASAI capabilities is provided through the high-level Script Builder appli­cation generation language. Subsets of the Notification , Third Party Call Control,
and Routing capabilities of ASAI have been integ rated int o Script Builde r for use
in ASAI applications. The ASAI feature does not provide access to the Set Value,
Value Query, Request Featu re , and Third Party Domain Cont rol capabil ities of
ASAI. The Request Feature capability, however, is use d interna lly by the ASAI
feature to log T/R or LST1 channels in and out of an Automatic Call Distribution
(A CD) split on the DEFINITY Generic 3i.

The ASAI capabilities suppo rted by the ASAI feature are u sed to support three
classes of applications as follows:

■ ASAI Voice Response Applications - The Notificati on capability of ASAI is

used to monitor calls delivered to a VIS T/R or LST1 channel. The ASAI
information related to these calls is used to control which voice script is
used for the call. ASAI information relate d to calls is also available to the
specific voice scripts which service calls. Refer to Chapter 6, "ASAI Script
Builder Actions", for additiona l info rmat ion on the A_Cal linfo actio n.T he
Third Party Call Control capability of ASAI is used when calls need to be
transferred away from the VIS.

2-1

ASAI Application Planning and Design

■ Routing Applications - The Routing capabil it y of ASAI and DEFINIT Y

Generic 3i call vectorin g is used to allow the VIS to act as a routing server.
A “routing” script on the VIS receives, processes, and responds to call rout­ing requests sent by the DEFINITY Generic 3i system. Refer to Chapter 6,
"ASAI Script Builder Actions" for additional information on the A_Event and
A_RouteSel actions.

■ Data Screen Delivery Applications - The Notification capability of ASAI is

used to allow the VIS to monitor calls delivered to ACD agents. A “monito r­ing” script on the VIS receives information concerning the status of non-T/R
or LST1 calls and passes this information to a host for use in presenting
data screens to agents receiving calls. Refer to Chapter 6, "ASAI Script
Builder Actions" for additional inform atio n on the A_Even t action.

These three classes of applications can run simult aneously on a VIS. The plan­ning and design considerations for these appl ications are provided late r in this
chapter.

The routing and data screen delivery applications are collecti vely referred to else­where in this book as “data” or “data-only” applicat ions. This is to differe nti ate
these types of applica tion s fro m voice response applications. Similarly, the rout­ing and monitoring sc ripts used to support these applications are collectivel y
referred to as “data” or “data-only” scripts.

VIS Script Design

Four additional Script Builder actions are provided with the ASAI feature and are
used to access ASAI capabilities. These actions are discussed in detail in Chap­ter 6, "ASAI Script Builder Actions". A brief summa ry of these actions is provided
below for the discussions here.

■ A_Callinfo — Used within a voice response script to retrieve ASAI informa-

tion about a call delivered to a T/R or LST1 channel (for example, calling
party number (ANI) and called party number (DNIS) for the call). This
action therefore provides access to the Noti fication capab ility of ASAI for
calls delivered to the VIS.

■ A_Event — Used within routing scripts to receive information about call

routing requests sent by the DEFINI TY Generic 3i system . This action is
also used in monitoring scripts to receive information abo ut calls delivere d
to an ACD agent. This action therefore serves a dual role by providing
access to both th e Routing and Notification capabilities of ASAI fo r non-T/R
or LST1 calls.

■ A_RouteSel — Used within routing scripts to respond to call routing

requests previously received via the use of the A_Event action. This action
therefore provides access to the Routing capability of ASA I and allows the
VIS to send ASAI call routing information to the switch.

2-2

ASAI Application Planning and Design

■ A_Tran — Used within a voice response script to t ransfe r a call away from

a T/R or LST1 channel on the VIS. This action makes use of the Third
Party Call Control capabil ity of ASAI to effect the tran sfer.

ASAI Voice Script Desig n

ASAI voice response applications are designed using the A_Callinfo and
A_Transactions within voice respo nse scripts. Other standard Script Builder
actions are also used in the voice script to answer the call, greet the caller, collect
data, etc. an example of a voice script making use of the A_Callinfo and A_Tran
events is included in Appendix A, “Sample Scripts.”

The A_Callinfo and A_Tran actio ns are used only in voice scripts which handle
calls delivered to a VIS T/R or LST1 channel. These two actions are not used in
routing and monitoring scrip ts where, in contrast to voice scripts, a call is not
present at a VIS T/R or LST1 channel.

For ASAI voice response applications, incoming calls are routed to the VIS over T/
R or LST1 channels configure d as an A CD split on th e DEF INI TY Generi c 3i sy s­tem. The Notification capability of ASAI is used by the VIS to monitor this split. As
a call is offered to this split, the VIS receives ASAI event reports indicating the sta­tus of the call (for example call offered, queued, alerting, and connected event
reports). The VIS uses the information contained in these event reports to provide
the following capabilities:

■ DNIS Service - The Dialed Number Information Service (DNIS) information

associated with the incoming call is used to select a particular Script
Builder script to service the call. A unique dialed numb er can be provided
for each unique voice response application. Each dialed number would
typically be represented by a unique Vector Directo ry Number (VDN) on
the DEFINITY Generic 3i switch. Calls to these different VDN’s can be
routed to the same VIS split. The DNIS information associated wit h an
incoming call is then used to select a particular application. An administra­tive screen on the VIS allows the different dialed numbers to be associated
with a specific voice response application. This allows T/R or LST 1 chan­nels to be shared across many applications. Prior to this capabilit y, chan­nels had to be dedicated to specific Scri pt Builder Appli ca tio ns.

■ Call Information - Once the call is answered by the VIS, the ASAI inform a-

tion related to the call can be retrieved for use in the voice script handling
the call. In particular, the A_Call info action can be used to ANI, DNIS,
switch collected user data (call prompting digi ts), call I D, and incoming
trunk group ID if ANI is not available.

A user designing a voice script need not be concerned with processing the individ­ual, lower-level ASAI event reports for incoming calls to the VIS. Rathe r, special
software is provided as part of the ASAI feature. This software processes the
event reports and stores the information contain ed in these event reports on a

2-3

ASAI Application Planning and Design

per-call basis. The DNIS information associated wit h a call is used to start a spe­cific voice script on the channel receiving the call. The A_Callinf o action can then
be used within the script to retrieve this information and use it in subsequent
Script Builder actions.

A subset of the Third Party Call Control capability of ASAI is also supported for
ASAI voice response applications. In particular, the A_Tran acti on uses Third
Party Call Control to transfer a call away from the T/R or LST1 channel.

The use of the A_Tran action within a voice response script 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 T/R or LST1 call to the destination spec­ified with the Destination Number field in A_Tran. Hence, the script designer is not
required to program many individual ASAI operation s. The use of a single action
effects the transfer.

Standard flash transfers are still possible when the ASAI feature is used. The use
of A_Tran, however, provides three significant enhancement s over existing trans­fer mechanisms:

■ Transfers are faster, quieter (from the caller’s perspective), and more reli-

able 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 Destinatio n Numbe r field in A_Tran to the desired agent exten­sion and by setting the Split Extension f ield t o the ACD split logged into by
the agent. Direct agent calling allows the transfer to be completed to a spe­cific agent while maintaining accurate ACD sp lit measurement s. The
DEFINITY Generic 3i direct agent ca lling feature can only be invoked via
ASAI and is therefore not possible via the standard flash transfer mecha­nism.

■ Information captured in the voice script can be saved for subsequent use in

a data screen delivery application. Information assigned to the VIS Data
field of A_Tran is saved by the VIS even after the voice script terminates.
The VIS associates this data with the transferred call and makes this data
available in call events passed to the monitoring script which monitors the
transferred call.

The third benefit mentioned previously is very useful for data screen delivery
applications where the screens delivered to agents are based on data collected by
the VIS. Since data collected in a voice script can be saved and is included in call
events made available to the monitoring script, the host appli cati on is simpli­fied.For instance, a CONNECT event (described later) made available to the mon­itoring script contains both the extension of the agent receiving the transferred call
and the VIS data saved from the voice script which previously serviced the caller.

2-4

ASAI Application Planning and Design

This single event is then passed to the host, thereby providing all information
needed by the host application in a single message.

Routing Script Design

Routing applications make use o f the routing capabilit y supported by ASAI and
the call vectoring feature on the DEF INITY Gene ric 3i system. In routing scenar­ios, calls are not physically delivered to T/R or LST1 channels on the VIS. Instead,
incoming calls to the DEFINIT Y Generic 3i are directed to a vector containing an
“adjunct route” step. The adjunct route step causes a “route request” message to
be sent to the VIS. The route request message contains information pertaining to
the call (for example, ANI). This informat ion is used by the VIS to determ ine
where to route the call.

After the VIS determines where to route the call, a “route select” message is sent
back to the DEFINITY Generic 3i s ystem. The route select message contains a
destination address provided by the VIS which the DE FINIT Y Generic 3i uses to
further direct the call. In routing scenarios, the VIS may be viewed as a routing
server which the DEFINITY Generic 3i calls upon to route calls processed with a
routing vector.

Note that, as a result of routing, the call may be directed to a VIS T/R or LST1 split
to collect more information from the caller. This would be the case, for example, if
the information conta ined in the route request was not sufficient to identify the
caller (for example, ANI not recognized).

Routing applications on the VIS are supported through the use of routing script s
which are designed using the A_Event and A_RouteS el actions. The A _Eve nt
action is used to bring information contained in a route request messag e sent by
the DEFINITY Generic 3i system up to the script level. The A_Event action returns
a ROUTE REQUEST event when the DEFINITY Generic 3i system has sent such
a message. If no route request messages have been sent, the A_Event action
waits until one is received. When a ROUTE REQUEST event is made available to
the script, it reflects information in an ASAI route request m e ssage sent by the
DEFINITY Generic 3 i system. Note that the A_E vent act ion is also used withi n
monitoring scripts to retrieve other types of events as discussed later.

Once a ROUTE REQUEST event is received in a script and the script determines
where the call should be routed, the A_Rout eS el action is used to cause a route
select message to be passed back to the DEFINITY Generic 3i system. This in
turn causes the call to be routed to the desired destination. Unlike voice response
scripts, routing scripts are not associated with a particular call. A single rout ing
script handles route requests for many calls. A routing script is designed to
receive and process ROUTE REQUEST events which can arrive at any point in
time as controlled by vector processing on the DEFINITY Generic 3i system.
Hence, the primary difference bet ween routi ng scripts and voice response scripts

2-5

ASAI Application Planning and Design

is that, once activated, routing scripts run continuously. Routing scripts, therefore,
have the following general structure:

1. An A_Event action to wait for and retrieve a ROUTE REQUEST event from
lower-level ASAI software on the VIS. Once the A_Event action retrieves a
ROUTE REQUEST event, subsequent actions below are execu ted.

2. Other standard Script Builder actions which ma ke use of the data made
available in the ROUTE REQ UE ST event to determ ine where th e call
should be routed. Examples include read ta ble and get /send host screen
actions to retrieve routing inform ation from a local or host database.

3. An A_RouteSel action to pass the routing informati on (that is, desired des­tination) from the script to lower-level ASAI softwa re on the VIS . This
causes an ASAI route select message containing the routing information to
be sent to the DEFINITY Generic 3i system.

Steps 1 through 3 above are repeated by using additional Script Builder steps to
create an infini te loop (that is, script labels and Got o actio ns ). A sample routing
script is provided in Appendix A, “Sample Scripts.”

A routing script may not contain any Script Builder actions which pertain to voice
response capabilities (A nn ounce, Prompt and Collect, etc.). A routing script is
assigned by using the “RTE” type designation as described in Chapter 4, "ASAI
Administration ".

A routing script may use any of the information returned in the ROUTE REQUEST
event as detailed in Chapter 6, "ASAI Script Builder Act ions" to route the call.
Examples include the called party num ber (for exampl e DNIS ), calling party num ­ber (for example ANI), and switch data (that is, call prompt ing inf orma tio n). Any
one or combination of the data items returned in a ROUTE REQUE ST event can
be used as the basis for a routing decision.

The call is routed to the destination suppl ied in the Destinat ion 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 numb er ). Also, the call
may be routed to a specific agent within an ACD split (direct agent routing). This is
done by setting the Destination Number fi eld in A_ Rout eS el to the desired agent
extension and by setting the Split Extension fi eld to the split logged int o by the
agent. Direct agent routing is the preferred way to route calls to specific ACD
agents since direct agen t calls are included in the calculations for ACD split statis­tics (for example, average speed of answer).

2-6

ASAI Application Planning and Design

Monitoring Script Design

Monitoring scripts on the VIS are used to support data screen delivery applica­tions. The Notification capability of ASAI is used to track the progress of calls that
are delivered to agents. A monitoring script on the VIS receives information about
these calls and forwards this information to a host application. The host applica­tion in turn uses the information to format a data screen presented to agents
receiving calls. Note, therefore, that the delivery of data screens is not a function
of the VIS itself.

In data screen delivery applications, calls are not physica lly delivered to a T/R or
LST1 channel on the VIS. Rather, calls are delivered to ACD agents on the
DEFINITY Generic 3i system. Note, however, that a call may have previously
been delivered to a VIS T/R or LST1 channel to collect information from the caller.

A monitoring script is designed using the A_Event action. When used in monitor­ing scripts, the A_Even t action returns the following types of call events:

■ CONNECT Event - indicates that a monitored call is being delivered to an

agent.

■ ABANDON Event - indicates that a monitored call has been abandoned .

■ ABANDON events are passed to a script whenever a caller hangs up

before being connected to an agent.

■ END Event - indicates that a monitored call has ended normally (that is, not

abandoned).

Detailed information about the data made available in these events is discussed in
Chapter 6, "ASAI Script Builder Action s". The three call event types passed to a
monitoring script reflect informa tio n contained in ASA I event reports for the call.

Unlike voice response scripts, monitoring scripts are not associated with a particu­lar call. A single monitoring s cript handles call events for all the calls delivered to
a particular domain. A monitoring script is designed to receive and process call
events which can arrive at any point in time as determined by how and when calls
progress on the DEFINITY Generic 3i system. Hence, the primary differen ce
between monitoring s cripts and voice response scripts is that, once activated,
monitoring scripts run continu ously. Monit oring s cripts, therefore, have the follow­ing general structure:

1. An A_Event action to wait for and retrieve a call event from lower-level
ASAI software on the VIS . Once the A_Event action ret rieves a call event,
subsequent actions below are executed.

2. Other Script Builder actions used to pass data in the event to a host. Exam­ples include get/send host screen actions to send the data to an IBM host
via the standard 3270 interface and a custom external fun ction to pass the
data to a custom DIP supporting an asynchronous interface.

2-7

ASAI Application Planning and Design

Steps 1 and 2 above are repeated by using additional Script Builder steps to cre­ate an infinite loop (that is, script labels and Goto acti ons). A sample m onit oring
script is provided in Appendix A, “Sample Scripts.”

A monitoring script may not contain any Script Builder actions which pertain to
voice response capabilities (Announce, Promp t and Collect, etc.). A monito ring
script is assigned by using the “VDN”, “ACD”, or “CTL” type designation as
described in Chapter 4, "ASAI Administratio n".

A monitoring script may pass any combinat ion of the three call event types to a
host. In addition, any combination of the data elem ents returne d in a specific call
event may be passed to a host. Examples include the called party number (DNIS
for example), calling party number (ANI for example), and switch data (call
prompting information).

Monitoring scripts on the VIS can be used to support data screen delivery for
three different call flow scenarios as described below:

■ VIS-to-Agent Transfers — In this call flow scenario, calls are initially deliv-

ered to the VIS and then transferred from the VIS to a live agent. The
transferred call can be monitored with a VDN or ACD type monitoring script
if the call is transferred to a monitored VDN or ACD split domain. The
transferred call can also be monitored with a CTL type monit oring sc ript
allowing the call to be transferred to a non-monitored domain or individual
station. If the VIS Data field of A_Tran was used to save voice script data,
then this data is made available in the VIS Dat a field of call events sent to
the monitoring script. Hence, data screens delivered to agent s in this sce­nario can be based on information collected in a voice script in addition to
ASAI information such as ANI, DNIS, and call prompt ing inform ation col­lected by the DEFINITY Generic 3i system. Refer to the information on
planning for VIS-to-Age nt Transfers in this chapt er for additional design
considerations.

2-8

■ Incoming Call Directly to Agent — In this call flow scenario, incoming trunk

calls are delivered directly to live agents via monitored VDN’s or ACD
splits. Here, call events are passed to a VDN or ACD type monitoring
script and contain only ASAI related information such as ANI, DNIS, and/or
call prompting informat ion. Data scree ns would not be based on data col­lected in a voice script since a VIS voice script is not used to collect data
from the caller. Since the VIS does not service calls in this scenario, no
data is present in the VIS Data field of call events.

■ Agent-to-Agent Transfers — In this call flow scenario, calls are transferred

between live agents. Here, for example, “screening” agents may be used
to collect information from the caller and handle simple transactions. The
call may subsequently be transferred to “specialized” agents which can
handle more complex or detailed transactions. In these scenarios data
screens can be based on information keyed in to the host applicati on by
live agents. The host application can save data collected and entered by a

ASAI Application Planning and Design

screening agent and the n use this data as the basis for data screens deliv­ered to other, specialized agents which may receive the call. The agent-to­agent transfer can be placed to a monitored domain or to an individual sta ­tion and is monitored with a VDN or ACD type monitoring script . Note that
the call may first have been delivered to the VIS and then transferred to an
agent prior to the live agent to live agent transfer. Hence, call events
passed to the monitoring script in this scenario can contain the same infor­mation available for the other two call flow scenarios. ASAI related inf or ­mation such as ANI, DNIS, and call prompting info rmation and V IS Data
can be present in call events. This information may be used in conjunction
with live agent entered data to provide the basis for data screens. Ref er to
the information on planning for Agent-to-Agent Transfers in this chapter for
additional design considerations.

VIS-to-Agent Transfers

VIS-to-agent transfers are accomplished by using the A_Tran acti on with in a
voice script servicing a caller. The use of A_Tran invokes ASAI Third Party Call
Control operations to transfer a call away from the T/R or LST1 channel to which
the caller is connected. The caller is transferred to the destination identified in the
Destination Num ber field of the A _Tran action.

The transferred call can be monitored by a monitoring scrip t so that data screen
delivery applications can be supported for VIS-to-agent transfers. The transferred
call can be monitored in two different ways as follows:

■ The call may be transferred to a VDN or ACD split domain monitored by the

VIS with a monitoring script. Call events for the transferred call are passed
to the script monitoring the dom ain to which the call is transferred.

■ The call may be monitored using a CTL type monitoring script as described

Chapter 4, "ASAI Administrati on". In this case, the call can be transferred
to non-monitored domains and individual stations. Here, only call events for
calls transferred from the VIS to agents are passed to monitoring scripts.
Other direct calls to an ACD split, for example, are not monitored therefore
no call events for the direct calls are passed to monitoring scripts.

A combination of the above two monitoring mechani sms may be used on the
same VIS. Rules for which monitoring script receives call events when these two
mechanisms are combined is discussed in Chapter 4, "ASAI Administrat ion".

In addition to monitoring the transferred call, the application designer has the abil­ity to save data collected in the voice script for subsequent use in the data screen
delivery application. This is done by using the VIS Data field of A_Tran. Any data
saved in this field when the transfer is initiated from the voice script is presented in
call events passed to the monitoring script which monitors the transferred call.
The VIS Data field provides twenty characters worth of storage. Note that multiple
data items could be stored in this field. A social security number and PIN number,

2-9

ASAI Application Planning and Design

for example, could be collected in the voice script, concatenat ed togeth er, and
then saved in the VIS Data field. The monitoring script which receives this data in
call events could then unbundle the informat ion for use in data screen delive ry
when the transferred call is delivered to an agent.

The following is a typical call flow for a VIS-to-agent transfer:

1. A call arrives at a T/R or LST1 channel on the VIS. The caller is prompted
through a voice response script.

2. The caller decides to speak to a live agent after entering an account num­ber. The voice script transfers the call to a live agent group using the
A_Tran action. The account number the caller input is saved by using the
VIS Data of A_Tran. The voice script terminates after the transfer is com­plete and the T/R or LST1 channel is free to handle anot her ca ll.

3. The transferred call is queued for an available agent. When the call is
eventually delivered to an agent, a monito ring script on the V IS receives a
CONNECT event for the call. The VIS Data field of this CONNECT event
contains the account number previously saved by the voice script. The
monitoring script passes the account number along with the connected
agent information fro m the CONNECT event to the host.

4. The host application uses the account number to format a data screen con­cerning the caller and presents thi s data scree n to the agent receiving the
call.The host application does not need to associate multiple call s since all
the necessary information is provided in a single CONNECT event for the
transferred call.

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 VIS Data information in addition to ASAI information related to
the

original

call to the VIS. The ANI and DNIS for the original call prior to the
transfer, for example, is reported in this CONNECT event. Also, the Other Call ID
field contains the call ID of the call originally deli ve red to the VIS T/ R or LST1
channel. Call events for calls to T/R or LST1 channels on the VIS are not passed
to monitoring scripts. Also, one END event is generated when the call eventually
terminates. As with the CONNECT event, the END event contains data pertine nt
to the original call. Refer to Appendix B, “Call Flow Examples” for a detailed call
flow example.

Additional considerations for VIS-to-agent transfers are as follows:

■ In some cases, you may want to collect more data in a voice script than

can be stored in the VIS Data field. The recommend ed method f or han­dling this is to save the data collected by the voice script in the host appli­cation. Use A_Callinfo to retrieve the call ID of the call that is delivered to
the T/R or LST1 channel. Pass the call ID along with the data to the host
from the voice script itself. The host applicati on must buffer the dat a until

2-10

ASAI Application Planning and Design

the CONNECT event for the transferred call is receive d.The ca ll ID in the
Other Call ID field of the CONNECT event can be used to correlate the two
calls.

■ The call may again be transferred after having been serviced by the live

agent. In this case, an END event is not reported until all transferring is
completed and the call terminates normally. As in the single transfer case,
the END event contains informa tio n pertin ent to the original ca ll. Rules for
how subsequent call events are reported is discussed under planning for
Agent-to-Agent Transfers in this chapter.

■ The discussions on blind and consult transfers, discussed next under plan-

ning for Agent-to-Age nt Transfers, do not apply to VIS-to-ag ent t ransfers
completed using the A_Tran action. Also, the delay needed for agent-to­agent transfers discussed later does not apply to VIS-to-agent transfers
completed using the A_Tran action.

■ Transfers away from the VIS may still be accomplished by using standard

flash transfer mechanisms. The use of this type of transfer, however, pre­cludes the ability to use the VIS Data field of A_Tran to save voice script
data for later use in data screen delivery applications. Also, the host appli­cation must view this type of transfer as an agent-to-agent transfer as dis­cussed next. Hence, the discussions on blind versus consult transfer and
the need to introduce delay for blind transfe rs from the VIS will 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 th e call) complet es the tra nsfer to the speci alized
agent (the agent receiving the transferred call) by pressing the Transfer but ton a
second time.

■ With 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

agent answers before pressing the Transfer button a second time.This
allows the screening agent to talk to the specialized agent before complet­ing the transfer.

Both of these call-transfer options are de scribed in more det ail lat er. 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 Generic 3i sys­tem.

blind transfer

consult transfer

, the screening agent presses the Transfer button a

, the screening agent waits until the specialized

2-11

ASAI Application Planning and Design

The first concept to understand is call monitoring in transfer scenarios. VDN or
ACD split domains are monitored by the VIS by assigning m onit oring scripts as
described in Chapter 4, "ASAI Administration". A call becomes monitored once it
enters one of these monitored domains. All domains to which this call may be

must

directed
remains monitored for the duration of the call even though it may be transferred
several times. Once a call becomes monitored, call events are passed to the mon­itoring script assigned to the domain the call has entered. A CONNECT event, for
example, is passed to a monitoring script when a specific agent is selected to
receive the call. The screening agent may transfer calls to other monitored VDN’s
and ACD splits or to individual stations. The origin al call to the screening agent
must be monitored and therefore delivered to the screening agent via a monitored
VDN or ACD split.

The second concept to understand is how call ID’s are managed in transfer sce­narios. The DEFINITY Generic 3i assigns a call ID to each call. The call ID is pro­vided 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 ID’s as described in
the following transfer scenario:

1. The original call is delivered to an agent and is assigned a unique call ID.

also be monitored by the VIS. Once monitored, theref ore, a call

The agent talks with the caller and decides that the call needs to be trans­ferred 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 phone.

3. A second call, temporarily independent of the first call, is placed from the
transferring phone. This call is assigned a call ID which is different than
that of the original call. If this second call is placed to a monitored domain,
the call immediately becomes monitored by the VIS and call events may be
passed to a monitoring script. If this second call is p laced to an individual
station, the call doe s not become monit ored unt il the transfer is compl ete d
as described in Step 4 below.

4. The second press of the Transfer button “merges” the original call which is
on hold with the second call and drops the transferring phone from the
resultant call.

The VIS is informed about the complet ed tra n sfer immed iately a fter the merg e
which occurs in Step 4. It is only after this merge, therefore, that the VIS has the
ability to associate the two calls.

before

With a blind transfer, this merge takes place
the second, specialized agent. Hence, with blind transfer calls, the VIS can
include information in the CONNE CT event for the merged ca ll which relates to
the original call. In particular, the call ID of the original call is retained by the VIS
and reported in the Other Call ID of call events for the transferred call. This mech­anism allows the host application to use call ID’s to associate the transferred ca ll
with the original call.

the merged call is delivered to

2-12

ASAI Application Planning and Design

With a consult transfer, the merge takes place
the second, specialized agent. In this case, the original call is still on hold at the
first agent’s phone when the second call is delivered to the second agent. Hence,
for consult transfers, the VIS can only provide informat ion related to the second
call in the CONNECT event for the second call. In particular, the call ID of the
original call is
second call. The host application must use a mechanism other than call ID ’s to
associate the original call with the second call. The alternate mechanism is the
Calling Party Number information as discussed later.

Blind Transfer

With a
before completing the transfer. With this type of transfer, the VIS 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 i n for mat io n such as ANI and DNI S 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 that can receive calls via a monitored VDN or ACD split or can be a regular
extension. Calls to Agent 1 in the screening split must be delivered via a moni­tored VDN or ACD split.

not

reported in the Other Call ID field of the CONNECT event for the

blind transfer

1. A call arrives for Agent 1.

, the screening agent does not talk to the specialized agent

after

the second call is delivered to

2. Agent 1 answers the call and enters pertinent information about the calling
customer.

3. Agent 1 transfers the call to Agent 2. This is done by pressing the transfer
button, dialing the VDN, 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-termin al 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 pa ssed to monitoring scripts for the entire scenario,
that is, one for the original call to the screening agent and one for the tran sfer to
the specialized agent. One END event is generated when the call eventually ter­minates. Refer to Appendix B, “Call Flow Exam ples” for det ailed call flow exam ­ples which include complete descriptions of call flows and call event contents.

The persons responsible for administration and applicat ion develo pme nt must
thoroughly understand the call flow described previously. In addition, note the fol­lowing:

2-13

ASAI Application Planning and Design

■ The domain receiving the original call and any domains receiving the trans-

ferred call must be monitored.

■ In call-center operations that use blind tra nsfer, the host applicat ion ma y

tag current call data by call ID. The call ID allows the applicati on to dete r­mine which data is associated with the call as the call is transferred to a
monitored domain or station.

■ Calls can be transferred either to a monitored domain or to a station. For a

blind transfer to a monitored domain, the followi ng must be considered:

— The agent must compl ete the transfer imm edi atel y afte r initiatin g it

by pressing the Transfer button a second time.

— A delay must be built into the flow of the transfer so that the comple-

tion of the transfer can be recognized by the communications sys­tem 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 which has a “wait” step in it. T he ve ctor
would then direct 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 sta-

tion rather than to a split, a CONNECT event is passed to a monitor­ing script. The agent must initiate and comple te the transfer by
pressing the Transfer button a second time in order for the CON­NECT event to be passed to the script. The CONNECT event there­fore only becomes available to the host application when the
Transfer button is pushed the second time.

■ If for some reason calls are transferred to non-monitored domains, unex-

pected operation can result. When the call placed by Agent 1 is not initially
monitored, the VIS assumes that a transfer to a station is taking place.
Hence, two CONNECT events for the tran sferred call would be generat ed.
One CONNECT event would be generated when the transfer is completed
by Agent 1 and another would be generated when the call is actually deliv­ered to Agent 2. Also, the Connected Party Number field of the first CON­NECT event for the transferred call would identi fy the ACD split or VDN
extension dialed by Agent 1. This is as opposed to identifying the extension
of Agent 2. Note that the Connected Party Number field of the second
CONNECT event for the transferred call would ident ify the extension of
Agent 2.

■ The END event that is reported for the transferred call contains information

pertinent to the original call. For examp le, 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.

2-14