AT&T Conversant VIS User manual

585-350-812
Issue 1
October, 1993
Conversant VIS
Adjunct Switch Application
Interface
Graphics ©
Table of Contents

Blank Page

Contents
Issue 1 October 1993 iii
Table of Contents i
1ASAI Overview 1-1
■Overview of the Adjunct/Switch
Application Interface Feature 1-1
ASAI VoiceResponse Applications 1-2
Routing Applications 1-4
Data Screen Delivery Applications 1-5
Advantages Using the VISASAI Feature 1-8
2ASAI Application Planning and Design 2-1
■ASAI Application Planning and Design Overview 2-1
■ASAI Application Planning and Design 2-1
■VISScript Design 2-2
ASAI Voice Script Design 2-3
Routing Script Design 2-5
Monitoring Script Design 2-7
■VIS-to-Agent Transfers 2-9
■Agent-to-Agent Transfers 2-11
Blind Transfer 2-13
Consult Transfer 2-15
■Host Application Planning and Design 2-18
ASAI Voice Response Application 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
3ASAI Installation 3-1
■Installation Overview 3-1

Contents
iv Issue 1 October 1993
■Prerequisites for ASAI Installation 3-2
■ASAI Hardware Architecture 3-3
■Installing ASAI Hardware 3-4
■Installing ASAI Software 3-6
■Removing the ASAI Software 3-8
4ASAI Administration 4-1
■ASAI Administration Overview 4-1
■Channel Administration 4-5
Add Channel Entry 4-8
Change Channel Entry 4-9
Remove ChannelEntry 4-10
Virtual Channel Administration 4-10
■Diagnose IPCI Board 4-13
■Domain Administration 4-14
Add Domain Entry 4-18
Change Domain Entry 4-19
Remove Domain Entry 4-19
■Initialize IPCI Board 4-20
■Parameter Administration 4-21
■Show ASAI Software Version 4-24
■Show Status ASAI Link 4-25
■Take IPCI Board Off-line 4-27
5Administering ASAI 5-1
■ASAI Administration Overview 5-1
■Administering the Lines 5-2
■Administering the VIS ACD Split Domain 5-2
■Administering the VIS Agent Lines 5-4

Contents
Issue 1 October 1993 v
6ASAI 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
ASample Scripts A-1
■SampleScripts Overview A-1
Sample ASAI Voice Script A-2
SampleRoutingScript A-4
Sample Monitoring Script A-6
BSample Scripts C-1
■ASAI Performance Performance Overview C-1
VoiceResponse Integration C-2
Data Screen Delivery C-2
Routing Applications C-2

Contents
vi Issue 1 October 1993

1-1
1
ASAI Overview
Overview of the Adjunct/Switch
Application Interface 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 Adjunct/Switch Application Interface are
provided in Chapter 3, "ASAI Installation".
The AT&T Adjunct/Switch Application Interface provides an Integrated Services
Digital Network (ISDN)-based interface between AT&T PBX’s and adjunct proces-
sors.The VIS ASAI feature supports this application interface for communications
with the AT&T DEFINITY Communications System, Generic 3i (hereafter referred
to as DEFINITY Generic 3i).This digital signaling interface 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 calls delivered to a T/R or LST1 channel on
the VIS.
Access to ASAI capabilities is provided through the Script Builder application gen-
eration language. Access to ASAI capabilities at the Script Builder level mini-
mizes the effort required to implement ASAI-based applications. 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-2
ASAI Overview
These types of applications can run simultaneously on a VIS. This implies that 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.
Figure 1-1. ASAI Voice Response Applications
System Monitor - Voice Channels
Channel
CHG-KEYSHELP PREV-PAGENEXTPAGE PREV-FRM NEXT-FRM CANCEL CMD-MENU
Calls
Today Voice Service Service Status Caller Input Dialed Digits
1
1
3
1
0
10
DB
Collect
Transfer
*MANOOS
Talking
Talking
appl2
appl4
appl7
appl3
8509
7328 5312
0
1
2
3
4
5

1-3
ASAI Overview
As a call is delivered to the VIS, the VIS receives ASAI information related 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 Identification (ANI). This information is used to control
which voice application is used for the call. The ASAI information related 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 applications:
■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 channels 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.
■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 allows the
transfer to be faster, quieter (from the caller’s perspective), and more reli-
able. In addition, the DEFINITY Generic 3i ASAI direct agent calling fea-
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 reporting ACD split statistics.
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 permits the design of unique voice
response applications. Examples include:
■Locator Service — A local or host database could be used to determine the
closest car dealers, Automatic Transaction Machines, stores, etc.
■Weather Reports — Provide a weather report for the callers area.
■Pay-Per-View — A cable company could use ANI to automate customer
selection of pay-per-view programs.

1-4
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 Applications
In routing applications, the VIS 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 receives and responds to call routing requests sent 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 applications. However, T/R or LST1 lines are required to route the call to
the VIS agents.
Figure 1-2. ASAI Routing Application route.pic

1-5
ASAI Overview
These call routing requests are generated by the DEFINITY Generic 3i when a
call is processed by specific call vectors 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 routing uses include:
■Priority Service — Important or “priority” 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 caller can be routed to a specific agent which nor-
mally 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 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 Applications
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 applications are also known
as “coordinated voice/data screen delivery” or “screen pop” applications. A data
screen delivery application is depicted in Figure 1-3.

1-6
ASAI Overview
Figure 1-3. Data Screen Delivery Applications gateway.pic
Note that the delivery of data screens is not a function of the VIS itself. A special
host application is developed by your company or a third party to perform this
function. The VIS acts as a communications gateway between the DEFINITY
Generic 3i and the host computer. A monitoring application on the VIS provides
the ability to track the status of calls on the DEFINITY Generic 3i. This monitoring
application receives information about calls delivered to live agents and forwards
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 prompting information collected 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 applications 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 information collected by the DEFINITY Generic
3i.

1-7
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 information. Data screens 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 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 who can han-
dle 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 application can save data collected and entered by a
screening agent and then 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 conjunction with 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 number, social
security number, personal identification number, desired service, etc. In many
cases, this type of information is more meaningful and useful than ASAI informa-
tion such as ANI to the host application and the live agents handling calls. Also,
the voice response application might be the primary application 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 integration (in addition to co-residency) of the
voice response and PBX-to-host gateway capabilities offered with the VIS ASAI
feature. This mechanism for embedding voice script data in call event information
for the transferred call can significantly reduce the complexity 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 another interface from
the monitoring device over which call events are received). Also, the host applica-
tion is typically required to track and associate multiple events for multiple calls

1-8
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 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 script.
Advantages Using the VIS ASAI Feature
The VIS ASAI feature can greatly improve the operations in your call center envi-
ronment. The capabilities that this feature offers provide the following benefits to
any company that receives customer calls:
■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 available with these applications allows calls to be
delivered to specific agents while maintaining accurate 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 associated with a given
call is available to each agent receiving the call. This reduces customer
frustration at having to repeat information to each agent. For example, a
caller may be directed initially to a VIS T/R or LST1 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 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 information from the voice
response application can be saved and presented in a data screen to the
live agent receiving the transferred call, thereby eliminating the need for
the customer to repeat information already collected. 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/performance of the VIS ASAI feature over prior
and competitive offerings. The VIS ASAI feature eliminates the need for
multiple boxes with multiple interfaces to the host computer, thereby simpli-
fying host application development. Access to ASAI capabilities using
Script Builder minimizes the effort required to implement the VIS piece of

1-9
ASAI Overview
the overall VIS/host application. 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 time 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 translates 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 identification of fraudulent calls). In this
case, no network costs are incurred for the call and no agent time is wasted
on the call.

1-10
ASAI Overview

2-1
2
ASAI Application Planning and
Design
ASAI Application Planning and
Design Overview
This chapter contains information on planning and designing an application that
will be used with the AT&T Adjunct/Switch Application Interface (ASAI) feature on
the CONVERSANT Voice Information System (VIS).
ASAI Application Planning and
Design
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 integrated into Script Builder for use
in ASAI applications. The 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 ASAI
feature to log T/R or LST1 channels in and out of an Automatic Call Distribution
(ACD) split on the DEFINITY Generic 3i.
The ASAI capabilities supported by the ASAI feature are used to support three
classes of applications as follows:
■ASAI Voice Response Applications - The Notification 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 related to calls is also available to the
specific voice scripts which service calls. Refer to Chapter 6, "ASAI Script
Builder Actions", for additional information on the A_Callinfo action.The
Third Party Call Control capability of ASAI is used when calls need to be
transferred away from the VIS.

2-2
ASAI Application Planning and Design
■Routing Applications - The Routing capability of ASAI and DEFINITY
Generic 3i call vectoring 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 “monitor-
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 information on the A_Event action.
These three classes of applications can run simultaneously on a VIS. The plan-
ning and design considerations for these applications are provided later in this
chapter.
The routing and data screen delivery applications are collectively referred to else-
where in this book as “data” or “data-only” applications. This is to differentiate
these types of applications from voice response applications. Similarly, the rout-
ing and monitoring scripts used to support these applications are collectively
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 summary 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 Notification capability of ASAI for
calls delivered to the VIS.
■A_Event — Used within routing scripts to receive information about call
routing requests sent by the DEFINITY Generic 3i system. This action is
also used in monitoring scripts to receive information about calls delivered
to an ACD agent. This action therefore serves a dual role by providing
access to both the Routing and Notification capabilities of ASAI for 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 ASAI and allows the
VIS to send ASAI call routing information to the switch.

2-3
ASAI Application Planning and Design
■A_Tran — Used within a voice response script to transfer a call away from
a T/R or LST1 channel on the VIS. This action makes use of the Third
Party Call Control capability of ASAI to effect the transfer.
ASAI Voice Script Design
ASAI voice response applications are designed using the A_Callinfo and
A_Transactions within voice response 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 actions 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 scripts 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 configured as an ACD split on the DEFINITY Generic 3i sys-
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 number can be provided
for each unique voice response application. Each dialed number would
typically be represented by a unique Vector Directory 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 with 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 LST1 chan-
nels to be shared across many applications. Prior to this capability, chan-
nels had to be dedicated to specific Script Builder Applications.
■Call Information - Once the call is answered by the VIS, the ASAI informa-
tion related to the call can be retrieved for use in the voice script handling
the call. In particular, the A_Callinfo action can be used to 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 script need not be concerned with processing the individ-
ual, lower-level ASAI event reports for incoming calls to the VIS. Rather, special
software is provided as part of the ASAI feature. This software processes the
event reports and stores the information contained in these event reports on a

2-4
ASAI Application Planning and Design
per-call basis. The DNIS information associated with a call is used to start a spe-
cific voice script on the channel receiving the call. The A_Callinfo 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 action 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 operations. 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 enhancements 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 Destination Number field in A_Tran to the desired agent exten-
sion 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 spe-
cific agent while maintaining accurate ACD split measurements. The
DEFINITY Generic 3i direct agent calling 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 application 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.