AT&T Conversant VIS User Manual

Download

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 processors.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 monitor 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.

Access to ASAI capabilities is provided through the Script Builder application generation language. Access to ASAI capabilit ies at the Script Bu ilder level m inimizes 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 messages. 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, integration 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

Figure 1-1. ASAI Voice Response App lications

1-2

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 channel 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 reliable. In addition, the DEFINIT Y Generic 3i ASA I direct agent calling fe ature 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 statistics. 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.

Figure 1-2. ASAI Routing Application route.pic

1-4

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 normally 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 department 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 translates 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 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 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 transferred 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 collected 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 handle 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 delivered 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 rmation 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 applications. 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 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 anoth er interf ace from the monitoring device over which call events are received). Also, the host appl ication 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 environment. 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 measurements. These capabilities help to insure that calls are quickly and reliably directed to the call center resource best suited to handle them . This minimizes 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 discuss 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 simplifying 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 provide 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, certain 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

Access to ASAI capabilities is provided through the high-level Script Builder application 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 routing 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 ring” 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 planning 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 elsewhere 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 routing 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 Chapter 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 stem. 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 status 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 administrative 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 channels to be shared across many applications. Prior to this capabilit y, channels 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 individual, 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 specific 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 specified 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 transfer 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 switchhook 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 extension 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 specific 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 mechanism.

■ 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 simplified.For instance, a CONNECT event (described later) made available to the monitoring 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 scenarios, 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 destination) 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 statistics (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 applications. 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 application 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 monitoring 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 particular 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 following 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. Examples 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 create 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 scenario 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 collected 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 collected 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

ASAI Application Planning and Design

screening agent and the n use this data as the basis for data screens delivered to other, specialized agents which may receive the call. The agent-toagent 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 information 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 ability 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 number. 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 complete 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 concerning 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 handling this is to save the data collected by the voice script in the host application. 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-toagent 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, precludes 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 application must view this type of transfer as an agent-to-agent transfer as discussed 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 completing 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 system.

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

also be monitored by the VIS. Once monitored, theref ore, a call 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 monitoring 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 scenarios. The DEFINITY Generic 3i 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 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. 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 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 merged call is delivered to 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 mechanism allows the host application to use call ID’s to associate the transferred ca ll with the original call.

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 monitored 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 terminates. 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 following:

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 rmine 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 system 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 monitoring script. The agent must initiate and comple te the transfer by pressing the Transfer button a second time in order for the CONNECT event to be passed to the script. The CONNECT event therefore 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 delivered to Agent 2. Also, the Connected Party Number field of the first CONNECT 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

ASAI Application Planning and Design

■ The call may again be transferred after having been 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 single transfer case, the END event contains information pertinent to the original call. Rules for how subsequent CONNECT events are reported are as described in this chapter and depend on whether the call is transferred to a monitored domain or to a station and whether consult or blind transf er operatio n 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 VIS and 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 that 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 inform ati on 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 transf er.

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 sc reen. Th e extension for Agen t 1 is reported in the Calling Party Number field of the CONNECT even t for the second call.

Two CONNECT events are pa ssed to monitoring scripts 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 termina tes.

Refer to Appendix B, “Call Flow Example s” for detailed call flow exampl es which include complete descriptions of call flows and call event contents.

2-15

ASAI Application Planning and Design

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

■ With a consult transfer, Agent 1 and Agent 2 generally both view the call

data in a private consultati on while th e caller is on soft hold.

■ Calls can be transferred either to a monitored dom ain 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 CON-

NECT event is made available to a monitoring script. Since Agent 1 stays on the line until Agent 2 answers, the two calls have not yet have been merged. This implies that the CONNECT event for the second call does not contain information 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 Numb er 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 VIS cannot assume that the two calls will eventually be merged since, in some cases, they may not be merged. Hence, the two calls cannot be correlated by using call ID’s from CONNECT events.

— In this case, the Calling Party Number fiel d of the second CON-

NECT 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 could then retrieve the appropriate data from Agent 1’s data-t ermi nal screen and deliver it to A gent 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 script when the t ransfe r 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

script only after the transfer is completed when the Transfer butt on is pressed the second time by Agent 1. This means that when Agent 1 and Agent 2 are talking privately, the host application 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 VIS, therefore, does not receive events for the second call until the two calls are merged. The host application can be pro gramm ed to allow the receiving station to query for the data. After the transfer is complete, a CONNECT event is passed to a monitoring script. This CONNECT event contains information pertinent to the first call. The Other Call ID field of this CONNECT event, for example, con-

2-16

ASAI Application Planning and Design

tains the call ID of the original call delivered to Agent 1. Also, for example, the Calling Party Numbe r field of this CONNECT event contains the ANI of the original caller.

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

pected operation can result. When the call to Agent 2 from Agent 1 is not initially monitored, the V IS assumes that a transf er to a station is taking place. Hence, the Conn e cted Party Num ber fiel d of the CONNE CT event generated when the transfer is completed by Agent 1 would identify the ACD split or VDN extension dialed by Agent 1.This is as opposed to identifying 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. This is true even though the second CONNECT event for consult transfers to monitored domains does not contain information pert inent 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 VIS). Also, an END event is reported for a call only when the call ultimately terminates (tha t 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 Generic 3i entirely.

■ The call may again be transferred after having been serviced by Agent 2. In

2-17

ASAI Application Planning and Design

Host Application Planning and Design

In certain call center environments, the VIS ASAI system is integrated with a host computer. As discussed previously, you must provide or obtain the host software application that works with the VIS ASAI system. This host software application is not part of the VIS ASAI product. The host application can u se the informatio n it receives from the VIS ASAI system to do certain functions such as display call informatio n on agent screens or route calls. The host app licat ion ma y also be called upon to provide the basis for an automated voice response applicat ion.

In some cases, particularly for voice response applications, the VIS ASAI system integrates well with an embedded application and hence no changes are required. For routing and data screen delivery applications, however, an existing application will most likely need to be modifie d to acco mmodat e new fun ct ion alit y.

You may have several options for providing this host application. For example, you can develop your own application or modify an existing applicat ion to work with the VIS ASAI system. This is typically done by the company’s data-processing or information-systems depart men t. Alternatively, you can purchase a thirdparty software vendor application that is designed and developed to work with the VIS ASAI system.

Application developm ent m ay require signif icant planning and coordinati on between different organization s within your compa ny. The t elecom m unications, call-center operations, and data-processing organizations are all typically involved in the planning process. Schedules for application developme nt or customizat ion must be coordinated closely with plans to implem ent the VIS ASAI system , In tegrated Services Digital Network (ISDN) services, and any additional communications system ACD features.

The voice response, routing, and data screen delivery applications enabled by a VIS 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 differ-

ent phone numbers. The sam e pe rson, for example, might s om etimes call from home and sometimes call from the office. The same database record should be used in both cases. Calls generated from a private branch exchange (PBX) will likely have more than one ANI assignment , based on the different trunk groups used to generate the call and the fact that individual trunk circuits sometime s carry different ANI identi ties.

■ You should allow for situations when ANI information is not delivered for a

call. In voice response applications, the voice script should provide some sort of default call handling for cases where no ANI is available. In routing applications, the caller could be routed to a VIS T/R or LST1 spli t so that additional information can be collected. In data screen delivery applications, an agent can ask the caller for this informa tion .

2-18

ASAI Application Planning and Design

■ You may want to write an ANI learning module to automatically a ssoci ate

new ANI information with existing customer records. Agents and voice response scripts can verify ANI information passed by the DEFINIT Y Generic 3i to the VIS.

■ You should allow for situations where a single ANI is associated with multi-

ple calling customers. More than one customer, for example, can call from the same PBX. 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 meth ods for bringing up customer data.

ASAI Voice Respons e A ppl icati on 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 script. In this case, your database must maintain t he ACD split extensions that agents are logged into as well as the extensions for the agents themselves.

■ If your voice response applications involves transfers to live agents, refer to

the information on plann ing for V IS-to -Age nt Transfers in this chapte r for additional design considerations.

Routing Application Consideratio ns

■ Unlike data screen delivery applications, routing applicat ions make use of

the host application in an “inquiry/response” fashion. This implies that the addition of a VIS ASAI routing application to your call center may have little or no impact on the high-level operation of the applicati on. The most significant change to the host application will likely be the inform ati on 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 VIS database to store routing information.

■ Routing applications can make use of direct agent ca lling. 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 the mselves.

2-19

ASAI Application Planning and Design

Data Screen Deliv ery Ap plic at ion Considerations

■ Prior to the use of data screen delivery applications, a host application typ-

ically waits for input from agents before performing an operation. Thus, the agent’s input generally controls the appl icati on. Wi th data screen delivery applications, a new input to the application is pro vided. While t his input enables agents to work more quickly, it means that the host application must be modified. In particular, the call events provided by a monitoring script on the VIS must be used by the host to drive the screens on agent’s terminals. The interface to the VIS 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 has 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 phones to make themselves unavaila ble for calls until they have 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. Th e application could look for information from the VIS only at this point. The agent’s phone will alert the agent to the new call, and the agent can quickly finish work on the previous call. You may wish to provide a quick way for the agent to move to this place in the interactions with the application.

■ In data screen delivery applications, phone extensions are used to identify

agents receiving calls. The host application must therefore be able to associate extensions with particular data t ermi nals.T hree possible ways of doing this are:

— The agent can be queried for the phone extension when the applica-

tion is started. This is the most flexible arrangement and handles the situation where data terminals and terminal ID’s are not permanently associated with the same phone. Agents do make mistakes in providing the phone extension to the system. You should plan for these occasional mistakes and make sure agents understand what m ust be done to properly use the system. Discuss this issue with the person responsible for the company’s agent operation s.

— If an agent is always assigned to the same work position and hence

extension, the extension info rmation could be adde d to an agent profile.

2-20

ASAI Application Planning and Design

— If the relationship between data termi nals, terminal ID’ s, and tel e -

phones is relatively stable, administration of the host application can maintain a fixed mapping betwee n phones and term inal s.

■ The agent screen application should be able to operate even if the VIS is

not delivering call events. If call information is not being deli ve red, the appropriate person or the application itself should notify agents that there is a problem and that they should operate in manual m ode. The DEFINITY Generic 3i continues to deliver calls to agents even if the ASAI link to the VIS is down.

■ If your call center application involves data screen delivery for VIS-to-agent

transfers, refer to the information on planning for VIS-to-Agent Transfers in this chapter for additional design consideration s.

■ If your call center application involve s data screen delivery f or agent-to-

agent transfers, refer to the information on planning for Agent-t o-Age nt Transfers in this ch apter for additional design consid erations.

■ Your application should be able to accommodate cases where there are

multiple CONNECT events received for the same call. This can occur, for example, in cases where direct agent calling is used. A call may first ring at the initial agent’s phone and then at the phone 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 script when CONNECT events are triggered on an ASAI alerting event report.

■ Your application should be able to accommodate cases where the con-

nected party identified in call events is not a known ACD agent. Depending on switch administrat ion 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 ident ify an AUDIX channel extension as the connected party.

2-21

ASAI Application Planning and Design

Communications System Planning

Communication system planning involves defi ning what changes must be made to your company’s communications system software conf igurat ion and ACD environment to support the planned a pp licat ions. The following is a list of items that should be considered when planning for the changes to the communications system.

■ A DEFINITY Generic 3i system with ASAI softw are is required to imple-

ment VIS ASAI applicat ions.

■ Call vectoring is strongly recommende d for use in implementin g all VIS

ASAI applications. This is especially true for data screen delivery applications which involve agent-to-agent transfers or DNIS service and voice response applications which make use of DNIS se rvice.

■ Call vectoring is mandatory for routing appli cation s. Call vectoring is also

mandatory for data screen delivery applications which m ake use of call prompting informat ion. Note that the call prompt ing capabi lity of vectoring is an additional, optional feature over and above the optional call vectoring feature.

■ If feasible, you may wish to aggregate agents currently in multiple splits

into a single split. This minimizes the number of domains that are monitored by the VIS and allows agents to be used more efficiently. Since DNIS is available in call events, you can have a single split of agents handle several applications. The host application can use DNIS to provide information screens that tell agents how to answer and handle calls.

■ You must plan your call flows carefully if multiple ASA I adjuncts will be

used with the same DEFINITY Generic 3i system. Once a call becomes monitored by a particular VIS, the call cannot be redirected or transferred to a domain monitored by another VIS or ASAI adjunct. This is a consideration primarily for data screen delivery appl icati ons. For examp le, if you have agent-to-agent transfers for data screen delivery applications, agents must restrict transfers to domains monitored by the same VIS that monitors calls delivered to them. Also, for example, you may have VIS-to-agent transfers to support data scree n delivery based on VIS collected dat a. In this case, multiple VIS systems should be configured to “front end” mutually exclusive sets of live agents. These considerations do not apply if only one VIS ASAI system is used and it is the only ASAI adjunct.

■ If ANI is needed for an application, you must provision an ISDN Primary

Rate Interface (PRI) in order to receive ANI from the network. Make sure ISDN service is available in your area when needed.

2-22

ASAI Application Planning and Design

Call Center Operations Planning

The persons responsible for call center or customer service operations should plan for the changes that occur in those operations when the VIS ASAI system is added to the call center. In particular, the use of automated voice response applications reduces the volume of calls handled by live agent s. In addition, the use of routing and data screen delivery applications can make the call center even more efficient by reducing the amount of time required to service those calls that are handled by live agents. This should reduce the amount of time that customer calls are in queue thereby increasing the productivity of agents and reducing the use of trunk facilities. You can take advantage of these benefits in one of two ways:

■ You can improve customer service by keeping the same number of agents

and reducing the average speed of answer (AS A). ASA is the average time, computed by Call Management System (CMS) or Basic Call Management System (BCM S), that ca llers wait in qu e ue before connect ing t o an agent.

■ You can save money by reducing the number of agents and keeping

approximately the sam e ASA.

Efficient agent operati on is the key to realizing the improvement s the VIS ASA I system can provide. Specific agent tasks may change when a VIS ASAI application such as data screen delivery is added 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 imp lement ing a data screen delivery application with the enti re agent pop ulat ion, conduct a trial to compare old call center operations with the new call center operati ons using a data screen delivery application. B enef its of the application sho uld be explained so that agents can take advantage of them.

If data screen delivery is performed for agent-to-agent transfers, carefully read the information on planning for Agent-to-Agent Transfers in this chapter. 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 hitting 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 ton e on the new, active call appearance.

3. Immediately press the Transfer button again after dialing the desired extension to complete the tra nsfer.

consult

transfer scenarios, the agent may wait to talk to the second agent

before completing the transfer. In consult transfer scenarios, however, the agent

2-23

ASAI Application Planning and Design

must make sure that the original call is on “transfe r” hold before comp leting the transfer. A call is said to be on transfer hold when the call was placed on hold by hitting the Transfer button. This is as opposed to “regular” hold where the call is placed on hold by hitting the Hold button.

For example, the agent may decide to return to the original caller before com plet ing the transfer (for example to say, “please wait while I transfer you to Bill who can handle your question”). When the agent returns to the original caller, the original caller is no longer on transfer hold. The agent must be sure to place the original call on transfer hold (not regular hold) before comple ting the transfer.

The following procedure should be followed for consult transfer situa tions where the screening agent wants to go back and talk to the original caller before completing the transfer. In this proce dure, Agent 1 is the screening agent who receives the original call from the calling cu stom er. Agent 2 is the specialize d 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 were the screening agent wants to announce the transf er to the original caller after having talked to the specialized agent. This procedure also insures that the VIS 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 call to Agent 2 on regular hold by hitting the Hold button while the call to Agent 2 is still the active call.

2. Agent 1 returns to the original caller by pressing the call appearance for the original call. This makes the origina l call active once again. Agent 1 may now talk to the original caller.

3. 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 - go to the next step and ignore the dial tone).

4. Make 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.

5. Agent 1 completes the transfer by hitting the Transfer button again. This is the third time Agent 1 has pressed the Transfer button.

2-24

ASAI Installation

Installation Overview

This chapter contains inform at ion on installat ion and setu p proced ures for the CONVERSAN T Voi ce Informat ion System (VIS ) Adjun ct/Swi tch Ap plicat ion I nterface (ASAI) software package. ASAI-specific installation processes are discussed in this chapter. Refer to Chapter 2, “Installing The Base Syste m Software” in

CONVERSAN T VIS Software Installation

on general voice system installation procedures.

, 585-350-111 for additional information

3-1

ASAI Installation

NOTE

Prerequisites for ASAI Installation

To install the Adjunct/S wit ch Appl icati on Interface fe ature on the CONV E RS AN T Voice Information System (VIS ) Version 3.1, you need the following:

■ One or more Tip/Ring cards (IVP4, IVP6, or a VRS6) with Signal Processor

installed OR one or more T1 cards (AYC11 or AYC3 B) with Signal Pro cessor installed

■ Network Support Utilities (1.2) Version 2.0

■ One ISDN PC Interface (IPCI) card

■ The Adjunct/Switch A pplicat ion Interf ace fea ture package

■ Configurator program output

For information on installing the VIS software and hardwa re , refer to the CONVERSANT Voice Inform ation Syst em Sof tware I nstall ation and Upgrade and t he hardware installation and upgrade book for yo ur platform.

Confirm that Adjunct /Swit ch Appl icati on Interface is install ed and available on the switch you are using. Refer to the DEFINITY Communicat ions Sys tem Generic 1 and Generic 3i Installation and Test Manual , 555-230-104.

3-2

ASAI Installation

ASAI Hardware Architecture

The VIS is designed to operate with the DEFINITY Generic 3i. The IPCI card must be installed on the VIS. The ISDN Line Circuit Pack, TN556, must be installed on the DEFINI TY Gene ric 3i. For information on the TN556 refe r to the DEFINITY Communicat ions System Generic 1 and Generic 3i System Description, 555-230-200 . Refer also to the DEFINITY Generic 1 and Generic 3i Wiring Manual, 555-204-111, Issue 2 .

To support the ASAI capability, t he VIS must be connect ed, via a point-to-point ISDN Basic Rate Interface (BRI), to the DEFINITY Generic 3i. The VIS (T/R or LST1) lines which need to access ASAI capabilities must be configu red as m embers of an Automatic Call Distributio n (ACD) split of the PBX. The IPCI card supports the BRI D-channel interface from the switch. One ASAI link per VIS is supported.

A typical VIS and DEFINITY Generic 3i configurat ion is displayed in Figure 3-1.

Public Network

ASAI Link (BRI (D))

DEFINITY Generic 3i

Live ACD

VIS ACD

VIS Agents (T/R Lines)

Live Agent

Figure 3-1. Typical Hardware Architectu re

Live Agent

CONVERSANT VIS

Host (optional)

3-3

ASAI Installation

Installing ASAI Hardware

Prior to installation, you shoul d run the configurato r program. For informat ion on running the configurator program, refer to Chapter 3, “Allocat ing S ystem Resources” in the hardware installation and upgrade book for your platform . Referring to the output from the show_conf ig comm and and Figu re 3-3, set the Base RAM address selection switch es on the IPCI card. Figure 3-2 shows the location of the Base RAM address location switches. Figure 3-3 shows the various switch settings for the Base RAM selection switches.

Red LED

HEADSET

RAM

Base RAM Address Selection Switches

Figure 3-2. IPCI Card

PHONE LINE

3-4

ASAI Installation

Base Address

0c8000h 0cc000h 0d0000h 0d4000h 0d8000h 0dc000h

Figure 3-3. IPCI Switch Settings

For information on installing the IPCI Card in the system, refer to Chapter 5, “Installing Circuit Cards” in the hardware installation and upgrade book for your platform.

Figure 3-4 shows a typical wiring architecture for the ASAI link. Note that you must connect the AT&T 440A4 8-pin terminating resistor (or equiva-

lent) to the LINE connector of the IPCI Card using the provided DW8 cable. Use the other DW8 cable to connect from the connecting block to the terminat ing resistor.

Set These Switches

1234

ON OFF ON OFF ON OFF

OFF OFF OFF OFF ON ON OFF OFF OFF OFF

ON ON ON ON

ON ON OFF OFF

CAUTION:

Total cable length from the DEFI NIT Y Generic 3i system t o the VIS should not exceed 1900 feet.

3-5

ASAI Installation

CONVERSANT VIS

(Version 3.1)

ISDN PC INTERFACE BOARD

X CONN

BLOCK

TYPICALLY

66 OR 110

TYPE

MAXIMUM 1900 FEET

DEFINITY Generic 3i

TN556

ISDN/BRI

TRANS - 26 TRANS + 1 REC + 27 REC - 2

()

}

CUSTOMER PREMISE EQUIPMENT

Figure 3-4. T yp ical Wiring for AS AI Link wiring.ps

Installing ASAI Software

The VIS ASAI software package is contained on high-densit y 3.5” floppy disks. Use the following procedures to insta ll the software package.

103 TYPE

CONN BLOCK

D8W CABLE

AT&T 440A4 8-PIN TERMINATING RESISTOR

D8W CABLE

HEADSET

PHONE

LINE

8 ( )

AUXILLIARY POWER

}

7 ( ) 6 TRAN5 REC4 REC+ 3 TRAN+ 2 NC 1 NC

6. Log in to the VIS as root.

7. Type installpkg at the UNIX system prompt.

8. Insert the floppy disk labeled “Adjunct/Switch Application Interface Library” into the disk drive and press .

An Install in progress message appears on the screen.

9. The package prompts you for the number of IPCI cards installed on the system. Type 1 and then press . Currently only one (1) link issupported per VIS.

3-6

ENTER

ASAI Installation

10. Next, the package prompts you for the Interrupt Vector Number (IVN) of the

11. You are now prompted to enter the M emo ry Address of the card. Refer to

12. The UNIX system will now be rebuil t. This takes approximatel y 2 minutes

13. When prompted, remove the disk from the drive.

IPCI card. Refer to the output of the configu ra tio n program to de term ine what interrupt number to use. Type in the number you have selected and then press . If you wish to cancel the software installation process at

ENTER

this time, you may type q to abort inst all ation.

the information under “RAMADDR” from the output of the configuration program for this setting for the IPCI card.

to complete.

14. Press to shutdown the system.

15. When prompted, reboot the system. While holding down and

ENTER

CONTROL

ALT DELETE

press and release on the numeric keypad, then release

CONTROL ALT

and .

16. Log in to the system as root.

17. Type installpkg at the UNIX system prompt.

18. Insert the floppy disk labeled “CONVE RS ANT A SAI Package Ve rsion 3.1 ” and press .

ENTER

19. Remove the floppy disk when prompt ed, and load the remaini ng flop pies into the disk drive when directed to do so. P ress .

ENTER

20. If the Voice System is running, the system asks you whether you wish to stop the voice system. Type y and then press to stop the voice

ENTER

system.

21. A message appears stating that the installation of the ASAI package is now complete.

22. A message appears asking you if you wish to restart the voice system.Type y and then press if you wish to start the voice system at t his

ENTER

time.Type n if you do not wish to start the voice system at this time (that is, if you have other software packages to load).

You have now completed loading the ASAI soft ware. Refer to Chapter 4, "ASAI Administration " to begin work with the various ASAI feat ures and capabil ities.

3-7

ASAI Installation

NOTE:

Removing the ASAI Software

To remove the ASAI softwa re, refe r to the following proce dure:

The ASAI feature package software mu st be removed bef ore the ASAI Library package software.

1. Before you remove the ASAI feature packag e softwa re or the ASAI library package software, you will need to stop the voice system. This may be done by using either the System Control screen or, from the UNI X system command line, by using the stop_vs command. Refer to Chapter 5, “Configuration Managem ent ” in

Operations

2. From the system prompt, type removepkg . The numbered list of installed packages is displayed.

3. Select the number associated wit h the AS AI pac kage.

4. When the prompt is returned, the ASAI software package has been removed.

for information on stoppi ng the voice s ystem.

CONVERS A NT Voice Inform at ion S ystem

3-8

ASAI Adminis tration

NOTE

This chapter describes the administrative screens that are provided with the ASAI feature package. For a step-by-step description of a typical voice-response application involving a VIS ACD and VIS agents, refer to Chapter 5, "Administ ering ASAI".

ASAI Administration Overview

The ASAI feature uses a menu-driven user interface. Refer to Chapter 1, “User Interface” of the 350-703, for a general description of the VIS user interface. The ASAI link must be administered on the DEFINITY Generic 3i. Refer to the

Communications System Generic 3i Implementation

additional inf ormat ion .

CONVER SAN T VIS Version 4.0 Operati on s

, 585-

DEFINITY

, 555-230-650, for

4-1

ASAI Administration

After you have logged into the VIS, the CONVER SANT VIS Version 4.0 screen should appear. If the CONVERSANT VIS Version 4.0 screen does not appear, type cvis_mainmenu at the system prompt to display the CONVERSANT VIS Version 4.0 screen. Fro m this screen, use the arrow keys to highlight “Voice Sy stem Administration”, then press . The Voice System Administration screen appears in Figure 4-1.

ENTER

Voice System Administration

Application Package Administration Configuration Management

Feature Packages Reports Script Builder Applications Switch Interfaces System Monitor

Highlight an item and press ENTER.

HELP

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

Figure 4-1. Voice System Administration Screen

4-2

ASAI Administration

ENTER

From the Voice System Administ rati on screen, highl ight “Feature Packages” and

ENTER

press to open the Feature Packages screen (Figure 4-2).

ASAI Administration

Select a feature package and press Enter

Figure 4-2. Feature Packages Screen

Feature Packages

CHG-KEYSHELP PREV-FRM NEXT-FRM CANCEL CMD-MENU

To access ASAI administratio n from the Feature P ac kages screen, highlight “ASAI Administration”, then press to display the ASAI Administration screen (Figure 4-3).

4-3

ASAI Administration

Channel Administration Diagnose IPCI Board Domain Administration Initialize IPCI Board Parameter Administration Show ASAI Software Version Show Status of ASAI Link Take IPCI Board Off-line

Please highlight the item you want and press Enter

HELP CANCEL

CHG-KEYS

Figure 4-3. A SAI Adminis tration Screen

The ASAI Administrat ion sc reen enable s you to access the following admin istrative features associated with ASAI:

■ Channel Administration

■ Diagnose ISDN PC Interface (IPCI) Bo ard

■ Domain Administrat ion

■ Initialize IPCI Board

■ ASAI Parameters

■ Show ASAI Software Version

■ Show Status of A SAI Link

■ Take IPCI Board Off-line

4-4

ASAI Administration

Channel Administration

The Channel Administrat ion screen provides one entry for each T/R or LST1 channel (VIS agent) that is administered as a member of the VIS ACD split. It provides a mapping between the VIS channels and the PBX extension numbers. Refer to Figure 4-1 for a diagram of a typical application.

To open the Channel Administration screen from the ASAI Administ rati on menu , highlight “Channel Adm inist ration” and then press . The Channel Admini stration screen appears. Figure 4-4 shows an example of the Channel Administr ation screen with channel information displayed.

Change A Channel Entry

Channel: _________ Extension: _________

ENTER

Please enter the new PBX extension number

HELP

CHOICES

SAVE

Figure 4-4. Ch ann el Administration Screen

CANCEL

CHG-KEYS

4-5

ASAI Administration

The Channel Administrat ion screen contains the fo llowin g fields:

■ The “CHANNEL” field indicates the T/R or LST1 channel number on the

VIS.

■ The “EXTENSION ” field indicate s the Private Bran ch Ex change (PB X)

extension number assigned for the channel.

■ The “LOGIN” field indicates whether or not the channel is intended to be

logged in to the ACD split. This field can be either YES or NO. If the channel is not logged in, the ACD does not deliver any calls to it.

■ The “STATUS” field indicates the channel status. The status can be either

broken, foos, hwoos, logout, manoos, netoo s, nonex, or LOGIN. LOGI N status indicates that the T/R or LST1 channel is ready to receive calls from the ACD.

The following is a list of the various channel states. Refer to Appendix D, “Troubleshooting ASAI” for additional informat ion on channel states:

■ broken (broken) — Possible malfunction detecte d on line

■ foos (facility out of service) — The line is not functional

■ hwoos (hardware out of service) — Channel cannot be logged in because

ASAI digital link is not operating

■ logout (logged out) — Channel has not been administered to be logged in

■ manoos (manual out of service) — Channel has not been placed into ser-

vice

■ netoos (network out of service) — ASAI link is up, but attempts to log in the

channel are failing

■ nonex (nonexistent) — Channel does not exist

■ LOGIN — Channel is ready to receive calls from the ACD

4-6

ASAI Administration

NOTE

The Channel Administration screen with the standard function keys is displayed in Figure 4-4. Note that you need to use CHG-KEYS to switch the function key display from the standard to the screen-specific set of commands, or vice versa. The screen-specifi c functi on keys in the Channel A dmi nistrat ion screen perform the following functions:

■ ADD — Add a channel entry. Refer to Figure 4-5 and accompanying text

for additional informatio n.

■ CHANGE — Change the PBX extension assigned to the channel. The

channel must be logged out before it may be changed. Refer to Figure 4-6 and accompanying text for additional informat ion .

■ REMOVE — Remove a channel entr y. The channel must be logged out

before it may be removed.

■ LOGIN — Login a channel as an agent of the ACD spl it . You must log in

the channel in order to receive calls from the ACD.

■ LOGOUT — Logout a channel from the ACD split. You may use the

LOGOUT key to prevent the ACD from delivering calls to the channel.

Press CANCEL to return to the ASAI Administ rati on screen (Figure 4-3).

Once the T/R or LST1 channels are administered and logged in, no manual intervention is required to log the channels back in during recovery (for example, switch or VIS reboot) or upon restarting the voice system.

If the ASAI link goes down after a channel is logged in, the channel STATUS displays ‘hwoos’ even though the channel remains in a logged in state. The VIS relies on the messages sent over the ASAI link to login and logout channels. If channels are logged in, and the ASAI link abruptly goes down (for example, the cable becomes disconnected), t he VIS is not able to logout the channels. (The PBX does NOT automatically logout the channels). This means that calls placed to the VIS ACD split are still directed to Tip/Ring lines on the VIS, but because the ASAI link is down, DNI S is not available for the call. In addition, the A_Callinfo and A_Tran actions do not function. To prepare for such a link outage, you should assign a ‘backup’ script to DNIS ‘ANY’ (which does not rely on A_Callinfo or A_ Tran). The standard Transfer Call action may be used instead.

4-7

ASAI Administration

Add Channel Entry

The Add A Channel Entry screen may be used to assign a Tip/Ring channel as a VIS agent.

While the Channel Administrat ion sc reen is active, press A DD to open the Add A Channel Entry screen (Figure 4-5).

Figure 4-5. Add Channel Entry Screen achan nel.p s

The Add A Channel Entry screen contains the following fi elds:

■ The “Channel” field indicates the Tip/Ri ng channel num ber on the VIS tha t

you wish to add. The channel number must be unique.

■ The “Extension” field indicates the extension number as signed to the appli-

cation. The extension number m ust be unique .

Press SAVE to add the new channel entry or press CANCEL to exit the Add A Channel Entry screen and return to the Channel Administration screen.

4-8

ASAI Administration

NOTE:

Change Channel Entry

The Change A Channel Entry screen is used to change the extension of a V I S agent.

The channel must be logged out before it may be changed.

While the Channel Administrat ion sc reen is active, press CHANGE to open the Change A Channel Entry screen (Figure 4-6).

Change A Channel Entry

Channel: _________ Extension: _________

Please enter the new PBX extension number

HELP

CHOICES

SAVE

CANCEL

CHG-KEYS

Figure 4-6. Ch ange Chann e l Entry Screen

The Change A Channel Entry screen contains the following fields:

■ The “Channel” field indicates the T/R or LST1 channel number on the VIS

that you chose to change. The Channel field cannot be changed in this screen.

■ The “Extension” field indicates the PBX extension numbe r assigned to the

channel. The extension number must be unique.

Press SAVE to activate the channel entry changes or press CANCEL to quit and return to the Channel Administration sc reen.

4-9

ASAI Administration

NOTE

Remove Channel Entry

While the Channel Administration screen is active, press REMOV E to unassign a Tip/Ring channel as a VIS agent. You will receive a confirmat ion screen a sking you if you wish to REMOVE the selected item.

Press to continue or CANCEL to abort the removal procedure.

ENTER

The channel must be logged out before it may be removed.

Virtual Channel Administration

From the Voice System Administ rati on screen (Figure 4-1), highl ight “System Monitor”, then press . The Voice Channel Monitor screen appears (Figure 4-7)

Channel

0 1 2 3 4v 5v

ENTER

System Monitor - Voice Channels

Calls Today

1 1 3 1 1 10

Voice Service

appl2 appl4 appl7 appl3 virtual1 virtual2

Service Status

Talking Collect

Transfer DB

Caller Input

8509

7328

Dialed Digits

5312

Figure 4-7. Voice Channel Monitor Scr een

Routing and data screen delivery applications availabl e with t he ASA I applicat ion are data-only applications. Unlike voice response applications, such applications do not require the allocation of network or speech processing resources.For these applications, one or more “virtual channels” a re allocated by the ASA I system , making all regular channels available for use by script applica tion s that need the system resources allocated to them. At a minimum, one virtual channel is required

4-10

CANCEL

CHG-KEYS HELP PREV-PAGENEXTPAGE

ASAI Administration

for each domain running a data-only script. A maxim um of 32 virtual channel s may be administered on the VIS.

4-11

ASAI Administration

NOTE:

The non-voice script that is assigned to a domain is started on the virtual channel when you use the ENABLE key in the Domain Administration screen to place the domain into service (inserv). Note that if the domain ch anges from i nserv to any other state, the non-voi ce response script running on the virtu al channel is aborted.

As traffic increases on any one domain, the ASAI pro cess spawns the assigned data-only script to accommodate the increased load.

Virtual channels are assigned a range of channel numbers above the maximum number of regular channels allocated on the system and activity on these channels is displayed in the Voice Channel Monitor screen. Following is a discussion of the fields in this screen as they relate to virtual channels used by the ASAI application. Ref er to Chapter 6, “System M onit or” of the

Information System Operati ons

The “Channel” field lists the existing channels on the VIS. “Virtual channels” have the character ‘v’ appended to the channel number in this field. In Figure 4-7 voice.vir.ps] channels 4 and 5 are virtual channels.

CONVERS ANT V oice

for additional information.

The “Calls Today” field provides data on the number of calls made to a particular channel within the system. Calls are monitored for a 24-hour period, on any day beginning at midnight (12 a.m.). Fo r virtual channels, the value in this field is the number of times the channel was used to run a data-only script. In Figure 4-7 channels 4 and 5 are running the virtual1 and virtual2 data-only scripts, respectively.

The “Voice Service” field provides th e name of the service currently running on the corresponding voice channel. In Figure 4-7 channel 4 is running the virtual1 service and channel 5 is running the virtual2 service. For virtual channels, this field is blank when no script is running.

The “Service Status” field list s the various statu s states of each channel in the VIS. The Service Status field is blank for virtual channels except when a script with a Data Interface Process (DIP) is running, in which case this field indicates the name of the DIP.

The “Caller Input” field provides the last set of digits entered by the caller. The Caller Input field is always blank for virtual channels.

The “Dialed Digits” field provides the last set of digits dialed by the VIS during the transfer process. The Dialed Digit s field is always blank for virtual channels.

4-12

ASAI Administration

ENTER

Diagnose IPCI Board

You should use the Diagnose IPCI Board command when you suspect that there is a problem with the ASAI link. Note that the IPCI card must be on-line bef ore it may be diagnosed. Refer to the Initialize IPCI Board procedures later in this chapter for information on initializing the I PCI card .

You may use the Show Status of ASAI Link (Figure 4-15)screen to determine whether the link is on-line (actively using the li nk) or off-line (not using the lin k). You may use the Take IPCI Board Off-line procedure to change the card from an on-line to an off-line state. Likewise, you may use the Initialize IPCI Board procedure to change the card from an off-line to an on-line state.The Take IPCI Board Off-line and Initialize IPCI Board procedures are discussed later in this chapter.

To diagnose the IPCI Board from the ASAI Administ rati on screen, highlight “Diag nose IPCI Board” and then press Figure 4-8 shows the Diagnose IPCI Board screen with IPCI diagnosis information displayed.

Diagnose IPCI Board

The IPCI Board passed all tests.

Press ENTER to continue.

PREVPAGE NEXTPAGE

CHG-KEYSCANCEL

Figure 4-8. Diagnose IPCI Board Screen

In the Diagnose IPCI Board example shown in Figure 4-8, testing was executed on card 1. If for some reason diagnostics had failed on the card, that information would be contained in this screen. The diagnose IPCI card command does not affect the link or traffic on the li nk.

4-13

ASAI Administration

Domain Administration

The Domain Administrati on screen is used to instruct the VIS adjunct on how to handle a call that was offered to a specific domain. For voice-response applications, there may be only one entry of type ACD to which the VIS service is assigned.

Other domain types that may be administered through the Domain Administration screen and assigned only non-voice response (data only) services include the following:

■ ACD — A domain type which processes information from the PBX associ-

ated with calls distributed on an ACD split on the switch.

■ VDN — A domain type which processes information from the PBX associ-

ated with a call processing vector (VDN) on the switch.

■ RTE — A domain type which processes route requests from the switch.

■ CTL — A domain type which processes information from the PBX for calls

transferred from the VIS (using the A_Tran action) to an extension which is not associated with an ACD or VDN domain already monit ored by the V IS.

To open the Domain Administration screen from the ASAI Admini stration s cree n, highlight “Domain Adm inistrat ion” and then press .T he Domai n Admini stra-

ENTER

tion screen appears. Figure 4-9 shows an example of the Domain Administration screen with domain informati on displayed.

Domain Administration

NAME TYPE EXT SERVICE STATUS

ACD001 VDN001 CTL001 RTE001 ACD002

Please highlight the item you want and press a function key.

HELP CANCEL CHG-KEYS

ACD VDN CTL RTE ACD

3982 4002 ANY 4005 7392

VIS vdn-serv ctl-serv rte-serv acd-serv

inserv manoos inserv inserv inserv

Figure 4-9. Domain Administration Screen domain.ps

4-14

ASAI Administration

By default, the VIS update s the Doma in Adm in istrat ion s cre en every 2 seco nds. The Domain Administrati on screen cont ains the following fields:

■ The “NAME” field indicates the domain name. You may choose any name

for the domain nam e.

■ The “TYPE” field indicates the VIS domain type. The domain TYPE can be

one of the following:

— ACD — Domain on the VIS which monitors calls to the correspond-

ing split (d omain) on the PBX.

— VDN — Domain on the VIS which monitors calls to the correspond-

ing VDN (domain) on the PBX.

— CTL — Defines a domain on the VIS which monitors call s trans-

ferred away from the VIS (by a voice script using the A_Tran action) to destinations on the PBX that are not moni tored by an ACD or VDN domain (for example, monitor calls transferred using A_Tran to miscellaneous extensions). CTL domains are defined by only the VIS and do not correspond to any domain on the PBX.

— RTE — Defines a domain on the VIS which accepts Route Requests

from the PBX. RTE domains are defined by only the VIS and do not correspond to any domain on the PBX.

The meaning of the “EXT” field depends on the t yp e of domain. The EXT can be one of the following:

■ ACD type domains — EXT field should contain the corresponding ACD

split PBX extension that is being monitored.

■ VDN type domains — EXT field should contain the corresponding VDN

PBX extension that is bei ng monitored.

■ CTL type domains — EXT field designates an extension (which does not

correspond to an ACD or VDN extension) for which calls are being t ransferred by a VIS channel using the A_Tran action. Calls transferred to the specified extension are processed by the CTL domain. The extension field can also contain “ANY,” in which case, calls transferred to any destination not already monitored by another doma in are processed. Note that if a specific extension is used in this field, it must correspond to an extension used in the Destination field of the A_Tran action used by a script assigned to an ASAI channel.

■ RTE type domains — EXT field limits the processi ng of route requests

based on the extension that was dialed. This field can contain a specific extension or the word “ANY.” If an extension is specified, only route requests for the specified (called) extension are processed. If “ANY” is specified in the field, then all route requests not processed by any other administered domain are processed.

4-15

ASAI Administration

NOTE

The “SERVICE” field indicates how the calls offered to the domain are handled by the VIS. The SERVICE field is used to specify a script which services the domain.

To make sure that the latest version of a script is picked up, the corresponding domain should be disabled and enabled each time the script is verified and installed via Script Builder.

A script can be assigned to any type of domain (ACD, VDN, etc.). I f the application or the ACD directs calls to the VIS T/R or LST1 line, the special service “VIS” must be use d here. The SERVICE can be one of the following:

■ ACD type domains — The SERVICE can be either a monitoring script

(refer to Chapter 2, "ASAI Application Pl annin g and Design", for a description of a monitoring script) or the special word “VIS.” If the agents on the ACD split are Tip/Ring channels on the VIS (that is, channels administered in the Channel Administratio n screen described in Chapter 2, "ASAI Application Planning and Design"), then you should specify “VIS” as the service for the doma in. “VI S” service provides the ability to start voice scripts on the Tip/Ring channels based on the DNIS. It also provides the ability for those voice scripts to use the A_Callinf o actio n.

VIS can be assigned to only one ACD domain. Consequently, all Tip/Ring channels that are administe re d for ASAI must be an agent that belongs to this ACD domain.

For ACD type domains that do not have agents on the VIS, a monitoring script should be assigned in this field.

■ VDN and CTL type domains — The SERVICE must be a monitoring script.

(refer to Chapter 2, "ASAI Applicat ion Plannin g and Desi gn" for a description of a monitoring script).

■ RTE type domains — The SERV ICE mu st be a routing script. (Refer to

Chapter 2, "ASAI Application Planning and Design " for a description of a routing script).

The VIS T/R or LST1 channels (agents) are used to support voice response applications. All T/R or LST1 channels used for ASAI capability must be administered into one ACD split on the PBX. Calls offered to the VIS domain are handled by the Script Builder script associated with the DNIS inf ormatio n. Refer to Chapter 3, “Configuration Managem ent ” in

for information on how to admin ister s cripts to dialed num bers.

tions

CONVERSANT Voice Information System Opera-

4-16

ASAI Administration

The “STATUS” field indicates whether the dom ain is ready to receive call information. The domain STAT US can be one of the following. Refer to Appendix D, “Troubleshooting ASAI ” for additional informat ion.

■ broken (broken) — A virtual channel could not be allocated for the service

assigned to this domain.

■ foos (facility out of service) — The ASAI digital link is not operating.

■ initing (initializing) — The service assigned to the domain is failing initializa-

tion.

■ inserv (in service) — The domain is ready to receive call information from

the switch.

■ manoos (manual out of service) —The domain has not been placed into

service.

■ netoos (network out of service) — The ASAI link is up, but attempts to

receive call information from the switch are failing.

The Domain Administration screen with the standard function keys is displayed in Figure 4-9. Note that you need to use CHG-KEYS to switch the function key display from the standard to the screen-specific set of commands, or vice versa. The screen-specific function keys in the Domain Administration screen perform the following functions:

■ ADD — Add a domain entry. Refer to Figure 4-10 and accompanying text

for additional informatio n.

■ CHANGE — Change a domain entry. The domain must be disabled before

it can be changed. Refer to Figure 4-11 and accompanying text for additional inform ati on.

■ REMOVE — Remove a domain entry. The domain must be disabled

before it can be removed.

■ ENABLE — Place domain into service. When enabled, the domain is mon-

itored and the VIS receives events for the domain. If the enable request is successfu l , the domain status becomes inserv. The domain must be disabled before it can be enabled.

■ DISABL E — Take domain out of service. If the disable request is success-

ful, the domain status becomes manoos.

Press CANCEL to return to the ASAI Administration screen (Figure 4-3). Once the T/R or LST1 channels are administered and logged in, no manual intervention is required to log the channels back in during recovery (for example, switch or VIS reboot) or on restarting the voice system.

4-17

ASAI Administration

Once the domain is administered and made inserv, no m anual int ervent ion is required to bring the domain back into service during recovery (for example, switch or VIS reboot) or upon restarting the voice system.

If a VIS domain with a script assigned to it is in any state but inserv, the default script is invoked. Note that if the domain for the VIS agent (T/R or LST1) line is disabled, the VIS still takes calls on these lines.

Add Domain Entry

While the Domain Administ ra tion screen is active, press ADD to open the Add A Domain Entry screen (Figure 4-10).

Add A Domain Entry

Name: _________ Type: _________ Ext :_________ Service: _________

Please enter the domain name

HELP CHG-KEYS SAVE

CANCEL CHOICES

Figure 4-10. A dd Domain Entry Screen

The Add A Domain Entry screen contains the following fields.Ref er to Figu re 4-9 and accompanying discussion for more information on each of these fiel ds.

■ The “Name” field indicates the name of the domain you wish to add.

■ The “Type” field indicates the domain type.

■ The “Ext” field indicates the extension num ber assigned to the applicat ion .

■ The “Service” field indicates how the calls offered to the domain are han -

dled by the VIS.

Press SAVE to add the new doma in entry or press CANCEL to exit the Add A Domain Entry screen and return to the Domain Administrat ion s creen.

4-18

ASAI Administration

NOTE

Change Domain Entry

While the Domain Administ ra tion screen is active, press CHANGE to open the Change A Domain Entry screen (Figure 4-11).

The domain must be disabled before it can be changed.

Change A Domain Entry

Name: _________ Type: _________ Ext :_________ Service: _________

Please enter the domain type: ACD, VDN, CTL, or RTE.

HELP

CHOICES

Figure 4-11. Change Domain Entry Screen

The Change A Domain Entry screen contains the following fields:

■ The “Name” field indicates the name of the domai n you wish to change.

■ The “Type” field indicates the domain type.

■ The “Ext” field indicates the extension num ber assigned to the ACD split

which uniquely identifies the dom ain in the switch.

■ The “Service” field indicates how the calls offered to the domain are han-

dled by the VIS.

Press SAVE to activate the dom ain changes or press CANCEL to quit and return to the Domain Administrat ion sc reen.

Remove Domain Entry

While the Domain Administ ra tion screen is active, press RE MO V E. You will receive a confirmation screen asking you if you wish to REMOVE the selecte d item.Press to continue or CANCE L to abort the removal procedure.

ENTER

SAVE

CANCEL

CHG-KEYS

4-19

ASAI Administration

NOTE

The domain must be disabled befo re it can be removed.

Initialize IPCI Board

The IPCI Board must be initiali zed when it is taken off-li ne. The Initial ize IP CI Board procedure downloads the driver softwa re onto the card and puts the card on-line. The IPCI card is now actively using the link.

WARNING:

The “Initialize IPCI Board” command shoul d be used only as an error recovery procedure for the card. You do not need to initialize the IPCI card each time that you diagnose the card.

If the IPCI card is already initialized and on-line, the card must first be taken off-line before it can be re-initialized.

The Initialize IPCI Board screen contains informat ion on what occurred during initialization of the IPCI card. The Initialize IPCI Board screen displays inform at ion as to whether the initializati on was a success or failure and the reason for the failure. Figure 4-12 displays an example of the Initialize IPCI Board screen with IPCI card initialization information displayed.

To initialize the IPCI card from the ASAI Administration screen, highlight “Initialize IPCI Board”, then press .

ENTER

Initialize IPCI Board

IPCI Board Initialization completed successfully.

Press ENTER to continue.

CHG-KEYSCANCELPREVPAGE NEXTPAGE

Figure 4-12. In itialize IPCI Board Screen

4-20

ASAI Administration

Parameter Administration

The ASAI Parameters screen is provided to allow adjustment of ASAI system parameters. These paramet er s affect the behavior of the ASAI feature.

To open the ASAI Parameters screen from the ASAI Administrat ion screen, highlight “Parameter Administrat ion” and then pre ss . The ASAI Parame ters screen appears (Figure 4-13).

ASAI Parameters

CONNECT Event: CONNECTED Trace Detail: Low

ENTER

Enter when the CONNECT Event should be reported to A_Event

HELP CHOICES SAVE CANCEL

CHG-KEYS

Figure 4-13. ASA I Param e ters Screen param. ps

The ASAI Parameters screen cont ains the followi ng fie lds: The “CONNECT Event” field is used to specify when the CONNECT event is

reported to the A_Event action in a script as signed to an ACD, VDN, or CTL type domain. Valid entries for this field are ‘CONNECTED’ or ‘ALERTING’. The default for this field is CONNECT ED.

4-21

ASAI Administration

NOTE

If you select CONNECTED in the CONNECT E vent field, the CONNECT event is reported when the ASAI CONNECTE D messag e is received from the PBX.T ypically, this corresponds to when the call is answered. If you select CONNECTED, VIS Data is transferred to subsequent CONNECT event reports when a call is transferred from one live agent to another (provi ded the transfer is a blind transfer). Refer to the discussion of the V IS Data field in the A_Tran and A_Event actions in Chapter 6, "ASAI Script Builder Actions" for additional information. Note that VIS Data is always transferred when the A_Tran action transfers the call from a Tip/Ring line on the VIS to another number, regardless of whether CONNECTED or ALERTI NG is ch osen for thi s field.

If you select ALERTING in the CONNECT Event field, the CONNECT event is reported when the call starts to ring at the destination number. This corresponds to the receipt of the ASAI ALERTING message from the PBX. In cases where a CONNECTED message is received from the PBX (the call is answered) and an ALERTING message was not received previously, the CONNECT event is reported to A_Event upon receipt of the CONNECTED message. This can happen when the call is routed to an ISDN trunk. An advantage of choosing ALE RTING is that if your application performs data screen delivery to agents, the screen can be displayed before the agent answers the call. This gives the host computer and agent more time to process the data before conversing with the customer.

Typically, neither a CONNECTE D nor ALE RT ING message is received from the PBX when calls are placed to non-ISDN trunks, thus a CONNECT event is not reported to A_Event for the call. However, an END event is reported when the call ends.

The CONNECT event paramet er is a system paramet er and, thus, affects all scripts using the A_Event action .

The “Trace Level” field controls the amount of detail that is displayed when you use the trace dip7 command to monitor messages and events being processed by the ASAI system. The trace feature facilitat es the debugging of new appl ications and is an optional feature that is not required for norma l system operat ion .

Valid entries for thi s field are ‘Low’, ‘Normal’, and ‘High’ .The Trace Level def ault setting is Low. This default setting displa ys only ASAI error and warning conditions and should be used when there is live traffic to minimize processing overhead from the trace feature. Refer to Table 4-1 for inf ormat ion on Trace detail display.

4-22

ASAI Administration

The Normal setting can be used for simple debugging of application scripts which use the A_Callinfo, A_E vent, A_Ro uteS el , and A_Tran act ions. Norm al det ail causes trace to display Low detail information as well as information perta ining to the processing of the A_Callinfo, A_Event, and A_Ro uteS el , and A_Tran script actions. This information may be usefu l when debuggi ng a new applicat ion script.The format is specific to each ASAI action being processed.

The High setting gives additional information on ASAI messages tha t are sent and received between the VIS and the DEFINITY Generic 3i system. High detail causes trace to display Low and Normal detail as well as ASAI messages (call events) and routing messages. A SAI messages received from the PBX which contain information about a call on a domain.This information may be useful when debugging an application script which is monitoring t he progress of calls on the PBX. S to Appendix D, “Troubleshooting ASAI” for additional informa tio n.

Table 4-1. Trace Detail Display

Trace Detail Trace Display

Low

Normal

High

— ASAI error and warning con-

dition

— Information displayed by Low

setting

— ASAI script action (that is,

A_Callinfo, A_Tran, A_Event, and A_Rout eSel) processing information

— Information displayed by Low

and Normal Settings

— ASAI messages (call

events) received from the PBX which contains information about a call on a domai n

4-23

ASAI Administration

Show ASAI Software Version

The Show ASAI Software Version screen is a text screen which contains informa tion on the software versions loaded onto the VIS. To show the ASAI Softwa re Version from the ASAI Administrat ion screen, highlight “Show ASAI Software Ve rsion”, then press . Figure 4-14 displays an example of the Show ASAI Software Version screen with software version information displa yed.

Figure 4-14. Show ASAI Software Version Screen version .ps

ENTER

4-24

ASAI Administration

Show Status ASAI Link

The Show Status of ASAI Link screen provides information on the current status of the ASAI link to the VIS. To show the status of the ASAI link from the ASAI Administration screen, highligh t “Show Status of ASAI Link”, then press to display link status information. Figure 4-15 displays the Show Status of ASAI Link screen for an IPCI card and ASAI link which are functioning normally.

The IPCI Board is on-line. Physical Layer (L1) is UP, Link Layer (L2) is UP.

ENTER

Show Status of ASAI Link

Press ENTER to continue.

CHG-KEYSPREVPAGENEXTPAGE CANCEL

Figure 4-15. Show Status ASAI Link Screen

The Show Status of ASAI Link screen displays one of the messages listed in Table 4-2 if the link is experiencing problems. For each of the displays in the Show Status of ASAI Link screen listed below, a meaning is provided which corresponds to the first column of Table D-3. Refer to Appendix D, “Troubleshooting ASAI” for possible remedies for each problem .

4-25

ASAI Administration

Table 4-2. Show Status ASAI Lin k Disp lays

Show Status of ASAI Link Meaning

The IPCI Board is on-line. Physical layer (L1) is DOWN, Link Layer (L2) is DOWN

The IPCI Board is on-line. Physical layer (L1) is UP, Link Layer (L2) is DOWN

The IPCI Board may be f aulty or non-existent. Make sure the card and the ASAI Library package have been installed with the correct options.

The IPCI Board is currently OFFLINE. The Board must be initialized before ser vice can begin.

The IPCI Board is currently being initialized. PUMPING The IPCI Board is currently being taken OFFLINE AWAITING

L1 DOWN, L2 DOWN

L1 UP, L2 DOW

FAULTY HARDWARE or UNKNOWN or UNDETERMINED

OFFLINE

GOING OFFLINE

4-26

ASAI Administration

Take IPCI Board Off-line

The Take IPCI Board Off-Line procedure takes the IPCI card off-li ne and effec tively disables the link between the IP CI card and the driver software. If you suspect that there might be problems wit h the ASAI comm unicat ions and you would like to reinitialize the IPCI card, you must take the card off-line by executing the following command before you may execute the Initialize the IPCI card command.

WARNING:

Do not take the card off-line while the ASAI applicat ion is running. This command should not be used in normal operation situations. It should be used in conjunction with the “Initialize IPCI Board” comman d as an error recovery procedure for the card.

From the ASAI Administrat ion s cree n, highlight “Take IPCI Board Off-l ine”, then

ENTER

press to execute the IPCI card off-line procedure. Figure 4-16 shows an example of the Take IPCI Board Off-Line screen when the card is successfully taken off-line.

Take IPCI Board Off-line

IPCI Board has been taken off-Line.

Press ENTER to continue.

PREVPAGE NEXTPAGE

CHG-KEYSCANCEL

Figure 4-16. T ake IPCI Board Off -line Screen

The Take IPCI Board Off-line screen contains info rmat ion on whet her the IPCI card has been successfully taken off-line.

4-27

ASAI Administration

4-28

Administering ASAI

NOTE

ASAI Administration Overview

Administration of the ASAI feature is a three-step procedure perform ed through the VIS menu system. The following adm inistratio n proce dures assume you are installing a voice response application with a configuration in which calls placed to an Automatic Call Distributor (ACD) on t he P rivate Branch Exchange (PBX ) are directed to (agent) lines on the VIS. The VIS is to select a service for the incoming call based on the dialed number (DNIS). The service requests the dialed number and calling number (ANI) from the ASAI and uses this information as part of the service being provided to the caller. The steps to be performed on the switch and the adjunct are as follows:

5. Administer the T/R or LST1 telephon e lines.

6. Administer the VIS ACD domain

7. Administer the lines as agents on the ACD split and log in the lines.

Once these steps have been completed, you can assign services to called numbers. Refer to Chapter 3, “Configuratio n Manageme nt” of the

Voice Information System Operations

dure.

The following assumes that you have completed the necessary administra tion on the PBX. Please refer to the

Generic 3i Imp lementation

for information on performin g this proce-

DEFINITY Comm unicat ions Syst em

, 555-230-650 for additional information .

CONVERSANT

5-1

Administeri ng ASA I

Administering the Lines

The lines (T/R or LST1) are administered as described in Chapter 5, “Switch Interface Administration” of To be certain that you select options that are compat ible wit h the DEFINI TY Generic 3i (only certain versions) system, select “AT&T System 75” item in the PBX Defaults screen. AT&T System 75 is the default setting. Consequently, if you are administering a new system, the lines are configured correctly by default.

Place all the lines into service. To do so, refer to the information on changing maintenance state in the operation s book, Chapt er 3, “Configurati on Management”. Do not proceed until the lines have been placed in the inserv state. These lines or channels are referred to in the following text as

CONVERSANT VIS Version 4.0 Operations

Administering the VIS ACD Split Domain

In order for the VIS to receive information on calls placed to its agent lines, the ASAI feature must be administered to monitor the ACD hunt group Extension. In other words, you must administer the A S AI feature on the VIS so that it requests call events (information) from a ACD hunt group or split, which is composed of the VIS agent lines. This domain is referred to as the domain on the system. Therefore, all VIS agent lines must be part of a single ACD split. Refer to Figure 3-1 for a diagram showing this conf iguration . The following steps outline the admin istrat ion of this Domain.

VIS ACD domain

domain

. You may administer only one VIS ACD split

, 585-350-703.

VIS Agent lines

on the PBX. In this case, the domain is the

1. From the Voice System Administ rati on me nu (Figure 4-1), high light “Feature Packages” and then press . A menu of installed feature pa ckages should be displayed in the Feature Packag es screen as shown in Figure 4-2.

2. From the Feature Packages menu, highlight “ASAI Admi nistration ” and then press to display the ASAI Administration screen (Figure 4-3).

3. From the ASAI Administration menu, highlight “Domain Administration” and then press to display the Domain Administrati on screen . This screen is similar to that shown in Figure 4-9 except that there no domain entries.

4. Press CHG-KE YS to display the alternate set of function ke ys and then press ADD to create a new domain. The Add A Domain Entry form is displayed (Figure 4-10).

ENTER

5-2

Administeri ng ASA I

5. Select any name you choose and enter it into the “Name” fie ld. A lthough it

6. Enter ACD in the “Type” field.

7. Enter the group extension of the VIS ACD split in the “Ext” field.

8. Enter VIS in the “Service” field. By choosing VIS as the service, you have

9. Press S AVE to save the domain and its parameters. The Domain Adminis-

10. Press the cursor keys until the domain is highlight ed. Press ENABLE to

is not necessary, you may want to choose the same name given to the split on the PBX. To display the PBX name for the split, type list hunt at the DEFINITY Generic 3i system console. Find the hunt group with the group extension corresponding to your VIS ACD extension. Use the name (if any) shown for that group.

designated this ACD split dom ain as the VIS ACD split domain. This instructs the ASAI to send call informat ion it receives from this doma in to the voice response service(s) that service the VIS Agent lines.

tration screen should be redisplaye d, similar to that shown in Figure 4-9, but now showing the domain that you have just entered.

bring the domain into service. Once you have pressed ENABLE, the VIS automatical ly enables the domain shou ld the voice s ystem be restarted after a system shutdown or power loss. You do not need to use the ENABLE key again to enable the domain unless you have disabled the domain by pressing the DIS A BLE key. The STATUS field should change to inserv.

11. If the STATUS field shows inserv, proceed to the information Administering the VIS Agent Lines in this chapter. If the STATUS field does not show inserv, refer to Appendix D, “Troubleshooting ASAI” for information on troubleshooting a domain.

5-3

Administeri ng ASA I

Administering the VIS Agent Lines

After creating and bringing the VIS ACD split domain into service, you must next administer and log in the lines as VIS agent lines. This is required if your service is going to use DNIS or the A_Callinfo or the A_Tran actions described in Chapter 6, "ASAI Script Builder Actions". If an agent line is not logged in, the PBX ACD does not route any calls to it. (Note that you can still dial the agent line directly, but no call information is available to the service that answers the call. In other words, the A_Callinfo action does not return any information for a call that is not routed to the VIS by the ACD.) The following steps outline the procedure to administ er and log in lines as VIS agent lines.

1. From the ASAI Administration m enu (Figure 4-3), highlight “Channel Administration” and then press to display the Channel Administration screen. The Channel Administration s c reen should be displayed as shown in Figure 4-4, but without any entries.

2. Press CHG-KE YS to display another set of function keys.Press ADD to display the Add a Channel Entry form (Figure 4-5).

3. Enter the channel number of one of the agent lines in the “Channel” field.

4. Enter the corresponding PBX extension numb er of the agen t line in the “Extension” field.

ENTER

5. Press S AVE to save the parameters.The Channel Administrati on screen should be redisplayed with the parameters you ha ve just entered. The LOGIN field should show NO and the STATUS field should show logout .

6. Repeat the previous steps for ea ch of the VIS Ag ent li nes.

7. In the Channel Administration screen (Figure 4-4), press CHG-KE YS to display the other set of function keys. Press the cursor keys to highlight the first channel. Press LOGIN to log in the VIS agent line. Once you have pressed the LOGIN key, the VIS remembers this and aut oma tical ly logs in the channel should the voice system be restarted after a system shutdown or power loss. You do not need to use the LOGIN key again to log in the channel unless you have logged out the channel by pressing the LOGOUT key. The LOGIN field should change from NO to YES, and the STATUS field should change from logout to LOGIN.

8. If the LOGIN field shows YES and the STATUS field shows LOGI N, the channel is ready to receive calls from the ACD. If the LOGIN field still shows NO, try pressing the LOGIN k ey again. If the LOGIN field shows YES but the STATUS field does not show LOGIN, refer to Appendix D, “Troubleshooting ASAI” for information on troubleshooting a VIS agent line.

9. Repeat the previou s procedures to log in the remaining channels.

5-4

Administeri ng ASA I

Once all the channels have been logged in, you are ready to run applications. If you have not done so already, you may now assign DNIS service to channels using the Assign Service To Voice Channels screen and Assign Services to Called Numbers screen as described in

, 585-350-703, Chapter 3, “Configuration Manageme nt.”

tions

CONVERSANT VIS Version 4.0 Opera-

5-5

Administeri ng ASA I

5-6

ASAI Script Builder Actions

For more informat ion on def ining a transaction and other Script Builder acti ons, refer to Chapter 4, “Defining the Transa ction” in the

Builder

“Using Advanced Feat ures” of the Script Build er book.

, 585-350-704. For additional informat ion on actions, refer to Chapt er 10,

CONVERSA NT V IS Script

ASAI Script Builder Actions Overview

This chapter contains information on the actions used to access the AT&T Adjunct/Switch App licat ion Interf ace (ASAI) capabilities from the Script Builder environment.

The following actions are listed in alpha beti cal order:

■ A_Callinfo — Used to access call information obtained from ASAI for a call

on a VIS Agent line.

■ A_Event — Retrieves information relat ed to a call being monitored by an

ASAI domain.

■ A_RouteSel — Used to send an ASAI route select mes sage to the Private

Branch Exchange (PBX).

■ A_Tran — Used by voice scripts running on VIS Agent (T/R or LST1) lines

to transfer a call to a live ACD, live agent, or other station on the PBX.

6-1

ASAI Script Builder Actions

Defining A_Cal linf o

The A_Callinfo action is used to access call information obtained from ASAI for a call on a VIS Agent line. The A_Callinfo acti on returns the Cal ling Party Num ber and Called Party Number associated with an incoming call to the transactio n script environment. The A_Ca llinf o action also returns a Call ID which identifies the call. In addition, if touch-tone digits entered by the caller have been collected by the switch, A_Callinfo returns these digit s. If the call was delivere d to a switch through a trunk and Automatic Number Ident ificat ion (ANI) information for the call is not available, the Trunk Group Id is returned instead of the Calling Party Number.

To add A_Callinfo to a transaction while defini ng an applicat ion in Sc ript Build er, press ADD. The Action Choices screen opens. In the Action Choices screen, highlight “A_C allinfo”, then press . Press CANCEL to exit from the Action Choices screen. You must now define the A_Ca llinf o step f urther. In the Define Transaction screen, hig hlight “External A ction : A_Callinfo,” then press DEFI NE . The Define A_Callinfo screen opens.

ENTER

Figure 6-1. Define A_Callinfo Form Screen def_acall.ps

Each of the fields in the Define A_Callinfo screen must contain a field name which returns the following information. Refer to Table 6-1 for a summary of the information in each of these fields.

CAUTION:

You should specify only ‘num’ field types for those fields in the Define A_Callinfo screen that return numbers, tha t is, specif y ‘num’ fields or constants for those fields that are of type ‘num.’

The “Calling Party Number” field sto res the calling party numbe r. The value returned in the Calling Party Number field can be up to 20 characters in length. I f the A_Callinfo action is successful , this field contains the calling party number. If the calling party number is not known or the call was routed from a non-ISDN trunk, a string of length 0 (null value) is returned.

6-2

ASAI Script Builder Actions

The “Switch Data” field stores up to 16 characters. If the switch prompts the caller for touch-tone digits, the digits are re turne d in the Switch Dat a field. If no digits are collected by the switch, a string of length 0 (null value) is returned.

The “Trunk Group Id” field indicates whether the incoming call was routed fro m a non-ISDN trunk on the switch. If the call was not placed through a trunk, the value returned is 0.

The “Call Id” field stores the Call Id (assigned by the switch) that identifies the incoming call. If the Call Id is not known, the value returned is 0.

The “Cause Value” field returns an error cause if the request for call information is not successful . Note that the error cause is returned if the Return Field contains a value of -3. Refer to VIS value column in Table D-6 in Appendix D, “Troubleshooting ASAI” for a complete listing of cause values.

The “Return Field” holds the retu rn status of the A_Callin fo acti on. If the A_Callinfo action is successful, it returns a number greater than or equal to zero. If A_Callinfo is unsuccessful, it returns one of the following negative values:

■ -3 — ASAI could not process the request for information. Check the Cause

Value field for inform ati on on wh y the request failed.

■ -1 — A_Callinfo could not send the request for call information. Check the

Message Log Report for system errors. Refer to Chapter 4, “Reports Administration” in the

for additional information.

tions

■ -2 — A_Callinfo did not receive a response from the ASAI for the request

CONVERSA NT Voice Informat ion System Opera-

for informati on. Check to see if the ASAI syst em is running .

■ -4 — ASAI link is down and call information cannot be received from the

switch. Refer to Appendix D, “Troubleshooting ASA I” for inform ation on troubleshooting the ASA I digita l link.

■ -5 — Illegal request. The call is not being monitored so no call informat ion

is available. Make certain that A_Callinf o is only being used in a script assigned to a VIS agent line and that the domain with which the call is associated is being monitored by the VIS. Refer to Chapter 4, "ASAI Administration " for inform ation on Channel Adm inist ration and Dom ain Administration , including how to monit or a channel.

■ -6 — Switch did not respond with the call information .

After the user-defined entries for the Def ine A _Call inf o screen are complete d, press CLOSE to update the “External Action: A_Callinfo ” action step in the Define Transaction list .

6-3

ASAI Script Builder Actions

Table 6-1. A_Callinfo Fields

Field Input/Output Required? Field Type Field Size

Calling Party Number ouput required char 20 Called Party Number output required char 20 Switch Data output required char 16 Trunk Group ID output required num – Call Id output required num – Cause Value output required num – Return Value output optional num –

Defining A_Even t

The A_Event action retrie ve s inform ati on relat ed to a call being monit ored by an ASAI domain. This action m ust be used with all scripts assigned to a domain. (Refer to Chapter 4, "ASAI Ad ministration" for information on a dmi nistering a domain). The A_Event action can return t he following t yp es of events:

■ Abandon Events — a monitored call is dropped or caller hung up

■ Connect Events — a monitored call is being delivered to an agent

■ End Events — a monitored call has ended normally (that is, not aban-

doned)

■ Route Request Events — a switch has requested routing for a particul ar

call

■ Abnormal Route End Events — the switch is reporting that the routing

failed due to some reason specified in the Cause Value field.

CAUTION:

The A_Event action should not be used in a script assi gned to a voice channel.

To add A_Event to a transaction while def ining an applicat ion in Script Bu ilder, press ADD. The Action Choices screen opens. Highli ght “A _E ve nt,” then press

ENTER

. Press CANCEL to exit from the Action Choices screen.

6-4

ASAI Script Builder Actions

You must now define the A_Event step further. In the Define Transaction screen, highlight “Extern al Action: A_Event, ” then press DEFINE. The Define A_Event screen opens.

Define A_Event

Connected Party Number: ____________________

Phone number: _________

Calling Party Number: ____________________ Called Party Number: ____________________ Switch Data: ____________________ Trunk Group Id: ____________________ Call Id: ____________________ Other Call Id: ____________________ LAI Display Info: ____________________ VIS Data: ____________________ Cause Value: ____________________ Cause Value: ____________________ Return Field: ____________________

Enter a field name to store the connected party number.

HELP CHOICES CLOSE REDRAW CANCEL

Figure 6-2. D efine A_Event From Screen

Each of the fields in the Define A_Event screen mu st contai n a field name which returns the following information. Refer to Table 6-4 for a summary of the information in each of these fields.

CAUTION:

You should specify only ‘num’ field types for those fields in the Define A_Event screen that return numbers, that is, specify ‘num’ fields or constants for those fields that are of type ‘num.’

The “Connected Party Number” field returns a number or extension, depending on the event being reported. For the ‘C’ (Connect) event, the field returns the alerted extension (answering extension) if the ‘C’ event is triggered on the alerting or connect message from the switch. If A_Event indicates the call has ended (the Return Field returns a value of ‘E’), the Connected Party Number field contai ns the number of the last connected or alerted party. If A_Event indicates the call is abandoned (the Return Field returns a value of ‘A’), the Connected Party Number field returns an alerted agent extension or a string of length 0 (null value) depending on when the call was abandoned. If the call was abandoned before agent selection, the Connected Party Numb er field ret urns a string of length 0 (null value). If the call was abandoned after agent selection, the Connected Party Number field returns the extension of the agent that was alerted for the call prior to the abandon. If the connected party number is not known, a string of length 0

6-5

ASAI Script Builder Actions

(null string) is returned. If A_Event is reporting a route request (the Return Field returns a value of ‘R’), a string of length 0 (null value) is returned. The value returned can be up to 20 characters in length.

The “Calling Party Number” field stores up to 20 characters. If the A_Event action is successful, this field contains the calling party number. If the calling party number is not known or the call was routed from a non-ISDN trunk, a string of length 0 (null value) is returned. If the value returned from the Other Call Id field is not 0, then the Calling Party Numbe r returns the number of the original call ing party.

The “Called Party Numbe r” field stores the called party num ber. The value returned in the Called Party Number field can be up to 20 characters in length. If the Called Party Number is not known, a string of length 0 (null value) is returned. If the value returned from the Other Call Id field is not 0, then the Called Part y Number returns the number that was original ly dialed.

The “Trunk Group Id” field indicates whether the incoming call was routed from a non-ISDN trunk on the switch. If the call was not pla ced through a trun k the value returned is 0.

The “Call Id” field stores the Call Id (assigned by the switch) tha t identifies the incoming call. If the Call Id is not known, the value returned is 0. The “Other Call Id” field returns a number (assig ned by the switch) th at identifies the original call that was transferred. The script developer may use this field to associate subsequent events that occur from a previous call. If the field is 0, then A_Event cannot relate this event with any other call. If the call is a new incoming call to a monitored domain, then the field is always 0. If it is a transfer call, the field value depends on the type of transfer that was completed. A consult transfer returns a non-zero value only when the transfer call is directed to a non-monitored domain. A blind transfer always returns a non-zero value. Refer to the information on agent-to-agent transfers in Chapter 2, "ASAI Application Planning and Design" for additional inf ormat ion .

The “LAI Display Info” field returns the Look Ahead Interflow (LAI) display information for the call. The value returned in this field depends on the call flow and whether or not the LAI feature (a PBX feature) is used. When the LAI feature is used to connect calls from one call center to another, this information can be used to determine which call center applicat ion was handli ng the caller on the originat ing switch. The originating switch can be administered such that the LAI Disp lay Info field will contain the originally dialed number the caller used at the originating switch. If the LAI feature is not used to connect calls from one switch to another, then a string of length 0 (null value) is returned.

6-6

ASAI Script Builder Actions

The “VIS Data” field returns a value previously saved in the VIS Data field of the A_Tran action in a voice script. If the call was not previously transferred using A_Tran, then a string of length 0 (null value) is returned. For example, a voice script which responds to an incoming call to the VIS (on a channel administered for ASAI) collects informa tio n from the caller and sa ves inform ati on in the V IS Data field of the A_Tran action and then uses A_Tran to transfer the call to a domain administered on the VIS. When A_Event reports the A bando n, Connect, or End events (Return Field con tai ns ‘A’, ‘C’, or ‘E’) for that call, this field retu rn s the saved inf ormation.

The “Routing ID” field contains a unique number that identifies the route request if A_Event is indicating a route request (that is, the Return Fie ld contai ns an ‘R’). This number is needed if the A_RouteSel action is used to respond to the route request. If the Routing ID is not known, the value returned is 0.

The “Cause Value” field returns an error cause from the switch if the request to route the call is not successful. Note that the error cause is returned if the Return Field contains a value of “r” or 114 (indicating an ABNOR MAL ROUT E END event). Possible error causes include the following:

■ “0” — The Destination Number provided in the A_RouteSel action is invalid

and does not exist on the switch.

■ “1” — The switch is unable to route the call to the Destination Number

because the destination is busy (that is, the destination current ly has an active call).

■ “8” — The call dropped while waiting for a routing response. The caller

probably hung up before the call has been routed.

■ “12” — The vector processing on the switch encountered steps other than

wait, announcement, goto

■ “13” — Upon routing to the Destination Number (for direct agent call), the

, or

stop

after the adjunct routing comma nd .

Destination Number is not logged in to the specified Sp lit Extension.

■ “14” — The Destination Number (for direct agent call) is not a member of

the specified Split Extension in the A_RouteSe l action.

The “Return Field” contains a return code indi catin g what type of event (if any) is being reported. If the A_Event action is successful, it returns a numb er greater than or equal to zero. Refer to Table 6-4 for additional information . If A_Event is unsuccessful, it returns one of the following values.

■ -1 — A_Event could not send the request for call information. Check the

Message Log Report for system errors. Refer to Chapter 4, “Reports Administration” in the

for additional information.

tions

■ -2 — A_Event did not receive a response from the ASAI for the request for

CONVERSA NT Voice Informat ion System Opera-

information. Check to see if the ASAI system is running.

6-7

ASAI Script Builder Actions

■ -4 — ASAI link is down and call information cannot be received from the

switch. Refer to Appendix D, “Troubleshooting ASA I” for inform ation on troubleshooting the AS AI digita l link.

■ -5 — Illegal request. The channel requesting the information is not a chan-

nel assigned by an ASAI domain to receive event messages. Make certain that you are using A_Event only in a non-voice script. Refer to Chapter 4, "ASAI Administ rati on" for inform at ion.

When developing a program using Script Builder, A_Event returns an integer value in the Return Field to indicate the type of event (ABANDON, END, CONNECT, ROUTE REQ UE ST, or ABNO RMA L ROUTE END) that is being reported. The possible values 65, 67, 69 , 82, or 114 correspond to the ASCII representation of the first letter for each type of message.

For example, if an ABANDON is being reported, you may use the following evaluate statement:

Evaluate:

if ReturnCode = “‘A’” is the same as if ReturnCode = 65

65 = “‘A’” — ABANDON 67 = “‘C’” — CONNECT 69 = “‘E’” — END 82 = “‘R’” — ROUTE REQUEST 114 = “‘r’” — ABNORMAL ROUTE END

6-8

ASAI Script Builder Actions

Table 6-2. A _Even t Return Field Value Meaning

Return Value Meaning Explanation

65 ABANDON The caller aban doned the call before the agent

67 CONNECT If CONNECT is sent on alerting message,then

69 END The call ended. The caller has been discon-

answered it.

this indicates that the a g ent s p ecified i n the Connected Number field has been alerted. If CONNECT is sent on connect message, the n this indicates that the a g ent s p ecified i n the Connected Number field has answered the call.

nected or has hung up after the call was answered by an agent.

82 ROUTE

REQUEST

114 ABNORMAL

ROUTE END

The switch is requesting that the call be routed by the VIS. The number to be routed is in the Called Number field. The Routing ID field contains an identifier which must be used in the corresponding Routing ID field of the A_RouteSel action.

The switch indicates that the routing was unsuccessful. Either the Destination Number or the Split Extension specified in the A_RouteSel action is invalid or the call was abandoned bef ore a route selection was made or vector processing was administered incorrectly. Check the Cause Value field for the specific reason.

Each ABANDON, CONNECT, END, ROUTE REQUEST, and ABNORMAL ROUTE END event returns informat ion pertaining to the event. Table 6-3 indicates what fields the A_Event actio n returns for each event.

6-9

ASAI Script Builder Actions

Table 6-3. Fields Returned by A_E vent for Each Event

Event

A_Event Field

Connected Party Number X Calling Party Number X X X Called Party Number X X X Switch Data X X X Trunk Group Number X X X Call Id X X X Other Call Id X X LAI Display X X VIS Data X Routing ID †

† The Routing ID field returns t he ASAI cluster Id of the domain which reported these events.

CONNECT

ABANDON

END

ROUTE

REQUEST

ABNORMAL ROUTE END

6-10

ASAI Script Builder Actions

Table 6-4. A_Event Fields

Field Input/Output Required? Field Type Field Size

Connected Number output required char 20 Calling Party Number output r equired char 20 Called Party Number output required char 20 Switch Data output required char 16 Trunk Group Id output required num – Call Id output r e quired num – Other Call Id output required num – LAI Display Info ouput required char 15 VIS Data output required char 20 Routing Id output reuired num – Cause Value output re quired num – Return Field ouput optional num –

Defining A_Ro uteS e l

The A_RouteSel action is used to send an ASAI route message to the PBX. The A_RouteSel action is used in conjunction wit h the A_E vent act ion and ma y be used to construct scripts assigned to RTE type domains. Note that the A_RouteSel action should not be used in scripts assigned to Control (CTL), Automatic Call Distribution (ACD), and Vector Directory Number (VDN) type domains and may not be used in voice scripts.

To add A_RouteSel to a transaction while defining an application in Script Builder, press ADD. The Action Choices screen opens. Highli ght “A _Rout eS el, ” then

ENTER

press . Press CANCEL to exit from the Action Choices screen. You must now define the A_Rout eSe l step furt her. In the Define Transaction

screen, highlight “External Action: A_RouteSel,” then press DEFINE. The Define A_RouteSel screen opens.

6-11

ASAI Script Builder Actions

NOTE

Figure 6-3. D efine A_RouteS el Form Screen def_route.ps

Each of the fields in the Define A_RouteS el s c reen must contain a field name or constant which returns the following information. Refer to Table 6-5 for a summary of the information in each of these fields.

CAUTION:

You should specify only ‘num’ field types for those fields in the Define A_RouteSel screen that return numbers, that is, specify ‘num ’ fie lds or constants for those fields that are of type ‘num.’

The “Destination Number” fiel d contain s either a numb er or the name of a field which contains a number indicating where the call is to be routed. The Destin ation Number must be a valid extensi on num ber (for exampl e, ACD hunt group extension, VDN, or station) or external address (for example, Direct Distance Dialing Number). The Destination Number may be up to 20 digits in length. If calls are routed to a number that is not on the switch, the Destination Number may contain a Trunk Access Code or Automatic Alternate Routing/Aut oma tic Rout e Sel ectio n prefix digit.

A route request may be rejected by setting the field identified by the “Destination Number” fiel d to the null string. In this case, the call will not be adjunct routed. Subsequent treatment for the call depends on what type of default vector processing has been administered on the switch.

6-12

ASAI Script Builder Actions

The “Split Extension” fi eld is used only for direct agent calls. This fi eld contains either a number or the name of a field which contains a number identifying a valid ACD split. The Split Extension may be up to 5 digits in length. If the Split Extension field is used, the call is treated as a direct agent call and routed to the agent identified in the Destinatio n Numbe r field via the split iden tified in the Split Exten sion field. If the Split Extension field contains no digits (null value), then the call is treated as a normal call rather than a direct agent call. An empty split extension is entered by leaving the field blank as opposed to enterin g “ “.

The “Priority Call” field indicates whether the call is to be delivered as a regular or priority call. This field must contain either “Yes” or “No” or a field name which may contain either of these two values. Enter “Yes” if you want the call delivered as a priority call. Enter “No” if you want the call delivered as a regular call. If “Yes” is not specified in this field, the call is delivered as a regular call.

The “Routing ID” field contains a unique num ber which iden tifies the call being routed. The Routing ID must match the Routi ng ID previously retrieve d in the A_Event action.

The “Cause Value” field returns an error cause if the route select is not successful. Note that the error cause is returned if the Return Field contains a value of -3. Refer to VIS column in Table D-6 in Appendix D, “Troubleshooting A SAI” for a complete listing of values.

The “Return Field” contains a return code indi catin g whether the action was successful. If the A_RouteSel action is successful, it returns a number greater than or equal to zero. If A_RouteSel is unsuccessful, it returns one of the following values:

■ -1 — A_RouteSel could not send the request to route the call to ASA I.

Check the Message Log Report for system er rors. Refer to Chapter 4, “Reports Administration” in the

Operations

■ -2 — A_RouteSel did not receive a response from the ASAI for th e request

for informat ion.

CONVERSANT Voice Information System

to route the call. Check to see if the ASAI system is running.

■ -4 — ASAI Link is down and route select information cannot be received

from the switch. Refer to Appendix D, “Troubl e shoot ing ASAI ” for inform ation on troubleshooting the ASAI digit al link.

■ -5 — Illegal request. The channel using A_RouteSel is not for a RTE

domain. A_RouteSel is being used in a script that has not been assigned to an RTE domain. Refer to Chapter 4, "ASAI Administ rati on" for info rmation on assigning A_RouteS el to a domain.

■ -6 — Switch did not respond after receiving the route sel ect inform ati on.

■ “53” — Bad Routing ID. The Routing ID specified in A_RouteSel is invalid.

Check to make sure that the same Routing ID received from ROUTE REQUEST Event is used in the A_RouteSel action.

6-13

ASAI Script Builder Actions

NOTE

■ -3 — The ASAI system could not route the call. Check the Cause Value

field for informati on on wh y the call could not be routed.

■ -11 — Destination Number exceed s 20 characte rs.

■ -13 — Split Extension exceeds 5 characters.

■ -15 — Routing Id is 0 or less.

Table 6-5. A_RouteSel F ields

Field Input/Output Required? Field Type Field Size

Destination Number input required char 20 Split Extension input opti onal char 5 Priority Call? input required char 3 Routing ID input required num – Cause Value output required num – Return Field output optional num –

Defining A_Tran

The A_Tran action is used by voice scripts running on VIS agent (T/R or LST1) lines to transfer a call to a live ACD, live agent, or other station on the PBX. To do so, the A_Tran action takes control of the incoming call, puts the call on hold, places a call to the Destination Number and, if the call is not busy or denied, merges the original call with the call to the Destination Number. If the call is busy or denied, A_Tran drops the call to the Destination Numb er, reconnect s to the original caller, and relinquishes control of the original incomin g call.

This note is important when using A_ Tran to transfer to VDNs/vectors. A_Tran merges the original incoming call wit h the second call only after determining that the second call has been placed successfully. The second call is considered to have been placed successfully if it becomes queued or alerts at an agent’s telephone. Before the two calls are merged to complete the transfer, the original ca ller rema ins on hold. In some cases, you may wish to expose the caller to additional vector processing after the call is transferred (for example, play announcement s or perform call prompting operations).

6-14

ASAI Script Builder Actions

To insure that the original caller is exposed to such operations, you must construct your vectors so that the transfer is forced to complete before such operations are performed. Example s include queuing the call to the agent split before playing announcements and queuing the call to a dummy split before performing ca ll promptin g operati ons. No ports or stations need be dedicated to establi sh a dummy split. To insure that a “queue to” step will cause calls to be queued to a dummy split, however, the dum m y split should be made vector controlled and queue slots should be assigned to it.

To add A_Tran to a transaction while defining an applicat ion in Script Builde r, press ADD. The Action Choices scree n opens. Highli ght “A _Tran, ” then press

ENTER

. Press CANCEL to exit from the Act ion Choices s creen. You must now define the A_Tran step further. In the Define Transaction screen, highlight “External Action: A_Tran,” then press DEFINE. The Define A_Tran form screen opens (Figure 6-4).

Figure 6-4. Deind A_Tran Form Screen def_tran. ps

6-15

ASAI Script Builder Actions

Each of the fields in the Define A_Tra n screen mu st conta in a field name or con stant which returns the following information. Refer to Table 6-6 for a summary of the information in each of these fields.

CAUTION:

You should specify only ‘num’ field types for those fields in the Define A_Tran screen that return numbers, that is, specify ‘num’ fields or constants for those fields that are of type ‘num.’

The “Destination Number” fiel d contain s either a numb er or the name of a field which contains a number indicating where the call is to be transferred. The Destination Number must be a valid extension number (for examp le, ACD hunt group extension, VDN, or station) or external address (for example, Direct Distance Dialing Number). The Destination Num ber may be up to 20 digit s in length. If calls will be transferred to a number that is not on the switch, the Destination Numbe r may contain a Trunk Access Code or Automatic Altern ate Rout ing /Automa tic Route Selection.

The “Split Extension” field is use d only for direct agent calls. This field cont ains either a number or the name of a field which contains a number identifying a valid ACD split. The Split Extension may be up to 5 digits in length. If the Split Extension field is used, the call is treated as a direct agent call and transferred to the agent identified in the Destinat ion Num ber field via the split ident ified in th e Spli t Extension field. If the Split Extension field contains no digits (null value), then the call is treated as a normal call rather than a direct agent call. An empty split extension is entered by leaving the field blank as opposed to ent ering “ “.

The “VIS Data” field contains up to 20 characters of any type of information that is saved and later used by the A_Event action. The data provided in this field is sent in the VIS Data field that appears in all messages received by the A_Event action for the transferred call, provided that the call is reported on either a CTL, VDN, or ACD type domain for the non- voice applicat ion.

6-16

ASAI Script Builder Actions

NOTE

The “Call State” field stores the status of the call. If a call transfer was attemp ted, the Call State field will have one of the following values:

■ 0 — Call State information not available.

■ 1 — Destination Number is ringing (alerting).

■ 4 — Transfer was denied. Check the Cause Value field for additional infor-

mation.

■ 5 — Call to Destination Number is queued until a line becomes availab le.

■ 7 — Destination Number is busy.

■ 8 — The destination address seized a non-ISDN trunk (trunk seizure).

■ 9 — The destination address is interworking with a non-ISDN trunk (cut-

through).

The Call State field contains the statu s of the call when A_Tran returns 0, -53, -60, -61, and -62 in “Return Field”.

The “Cause Value” field returns an error cause if the transfer is not success ful . Note that the “Cause Value” field contains the reason for the failure if A_Tran returns -16, -17, -18, -19, or -20 in the Return Field. Otherwise, if A_Tran is successful , the Cause Value is set to -1. Refer to the VIS Value column in Table D-6 in Appendix D, “Troubleshoot ing ASAI” for a compl ete list ing of Cause Valu es.

The “Return Field” returns a code indicating whether A_Tran was successful. A_Tran attempts to complete (merge) the transfer if the call is not busy or denied. If the A_Tran action is successful, it returns a number greater than or equal to zero. Otherwise A_Tran reconnects back to the original caller if necessary and returns one of the following negative values:

■ -4 — ASAI link is down and transfer information cannot be performed.

Refer to Appendix D, “Troubleshooting A SAI” for info rmation on trou bleshooting the ASAI digital link.

■ -5 — Illegal request. The call is not being monitored so no transfer informa-

tion is available. Refer to Chapter 4, "ASAI Administ rati o n" for informat ion on Channel Administration and Dom ain A dmi nistrat ion .

■ -6 — Switch did not respond with the transfer inform ation.

■ -16 — A_Tran received an error from the ASAI system when trying to take

control of the original call. Check the Cause Value field for information on why the request failed.

■ -1 — A_Tran could not send the request to take control of the original call.

Check the Message Log Report for system er rors. Refer to Chapter 4, “Reports Administration” in the

Operations

for informat ion.

CONVERSANT Voice Information System

6-17

ASAI Script Builder Actions

■ -2 — A_Tran did not receive a response from the ASAI for the request to

take control of the original call. Check to see if the ASAI system is running.

■ -17 — A_Tran received an error from the ASAI system when trying to put

the original call on hold. Check the Cause Value fiel d for informat ion on why the request failed.

■ -18 — A_Tran received an error from the ASAI system when trying to place

the call to the Destination Number. Check the Cause Value field for inf ormation on why the request failed.

■ -20 — A_Tran dialed out to the destination number but the call was busy or

denied. Check the Call State and Cause Value fields for the reason why the request failed.

■ -19 — A_Tran received an error from the ASAI system when trying to com-

plete (merge) the transfer. Check the Cause Value field for information on why the request failed.

■ -11 — Destination Number exceed s 20 characte rs.

■ -12 — Destination Number cannot be empty (0 characters in length).

■ -13 — Split Extension exceeds 5 characters.

■ -14 — VIS Data exceeds 20 characters.

Table 6-6. A_Tran Fields

Field Input/Output Required? Field Type Field Size

Destination Number input required char 20 Split Extension input optional char 5 Priority Call? input required char 4 VIS Data input required char 20 Call State output required num – Cause Value output required num – Return Field output option num –

6-18

AT&T Conversant VIS User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual