Host application planning and design

In certain call center environments, the Avaya IR ASAI system is integrated with a host computer. An application must be provided on the host that works with the Avaya IR ASAI system. This host software application is not part of the Avaya IR ASAI product. The host application can use the information it receives from the Avaya IR ASAI system to do certain functions such as display call information on agent screens or route calls. The host application can also be called upon to provide the basis for an automated voice response application.

In some cases, particularly for voice response applications, the Avaya IR ASAI system integrates well with an embedded application and hence no changes are required. For routing and data screen delivery applications, however, you will probably have to modify an existing application or provide a new one to accommodate new functionality.

You may have several options for providing this host application. For example, you can develop your own application or modify an existing application to work with the Avaya IR ASAI system. This is typically done by the customer's data processing or information systems department. Alternatively, you can purchase a third-party software vendor application that is designed to work with the Avaya IR ASAI system.

Application development may require significant planning and coordination between different organizations within your company. The telecommunications, call center operations, and data processing organizations are all typically involved in the planning process. Schedules for application development or customization must be coordinated closely with plans to implement the Avaya IR ASAI system, ISDN services, and any additional communications system ACD features.

The voice response, routing, and data screen delivery applications enabled by a Avaya IR ASAI system can all potentially make use of ANI information delivered by the network. Keep the following considerations in mind when using ANI:

• You should allow for the possibility that the same caller will call from different telephone numbers. The same person, for example, might sometimes call from home and sometimes call from the office. The same database record should be used in both cases. Calls generated from a switch will probably have more than one ANI assignment. This is based on the different trunk groups used to generate the call and the fact that individual trunk circuits sometimes carry different ANI identities.
• You should allow for situations when ANI information is not delivered for a call.
  • In voice response applications, the voice application should provide some sort of default call handling for cases where no ANI is available.
  • In routing applications, the caller could be routed to an Avaya IR system so that additional information can be collected.
  • In data screen delivery applications, an agent can ask the caller for this information.
• You might want to write an ANI learning module to automatically associate new ANI information with existing customer records. Agents and voice response applications can verify ANI information that is passed by the DEFINITY G3 switch to the Avaya IR system.
• You should allow for situations where a single ANI is associated with multiple calling customers. More than one customer, for example, can call from the same switch. Examples of how to handle such situations include bringing up a menu from which the agent can choose the appropriate customer and switching to traditional methods for bringing up customer data.

ASAI voice response application considerations

Voice response applications can make use of direct agent calling. Calls can be transferred to specific agents within ACD splits after being serviced by a voice response application. In this case, your database must maintain the ACD split extensions that agents are logged into as well as the extensions for the agents themselves.

Routing application considerations

Unlike data screen delivery applications, routing applications make use of the host application in an inquiry and response fashion. This implies that the addition of a Avaya IR ASAI routing application to your call center may have little or no impact on the high-level operation of the application. The most significant change to the host application will probably be the information stored in the database. Information as to how calls should be routed must be added to the database if it is not already present. An example is ANI-to-agent and/or ACD split mappings. If feasible, consider using a local Avaya IR system database to store routing information.

Routing applications can make use of direct-agent calling. Calls can be routed to specific agents within ACD splits. In this case, your database must maintain the ACD split extensions that agents are logged into as well as the extensions for the agents themselves.

Data screen delivery application considerations

Prior to the use of data screen delivery applications, a host application typically waits for input from agents before it performs an operation. Thus, the agent's input generally controls the application. With data screen delivery applications, a new input to the application is provided. While this input enables agents to work more quickly, it means that the host application must be modified. In particular, the host must use the call events provided by a monitoring application on the Avaya IR system to drive the screens on the agents' terminals. The interface to the system serves as a control link while the interface to the agent operates traditionally as an inquiry and response link. The interactions between these two properties of the application must be considered carefully.

Suppose, for example, that a call arrives for an agent before that agent is finished entering data from the previous call. This scenario can be handled in one of the following ways:

• Agents can be trained to use Aux Work or After Call Work feature buttons on their telephones to make themselves unavailable for calls until they are finished entering data from the previous call.
• There is typically a point in the application's sequence of operations (for example, base transaction screen) where the agent is waiting for a new call and begins interaction with the application. The application could look for information from the Avaya IR system only at this point. The agent's telephone will alert the agent to the new call, and the agent can quickly finish work on the previous call. You may want to provide a quick way for the agent to move to this place in the interactions with the application.

In data screen delivery applications, telephone extensions are used to identify agents who are receiving calls. The host application must therefore be able to associate extensions with particular data terminals. The following are possible ways to do this:

• The agent can be queried for the telephone extension when the application is started. This is the most flexible arrangement and handles the situation where data terminals and terminal IDs are not permanently associated with the same telephone. Agents do make mistakes in providing the telephone extension to the system. You should plan for these occasional mistakes and make sure that agents understand how to use the system properly. Discuss this issue with the person responsible for the company's agent operations.
• If an agent is always assigned to the same work position and hence, to the same extension, the extension information could be added to an agent profile.
• If the relationship between data terminals, terminal IDs, and telephones is relatively stable, administration of the host application can maintain a fixed mapping between telephones and terminals.

The agent screen application should be able to operate even if the Avaya IR system is not delivering call events. If call information is not being delivered, the appropriate person or the application itself should notify agents that there is a problem and that they should operate in manual mode. The DEFINITY G3 switch continues to deliver calls to agents even if the ASAI link to the Avaya IR system is down.

Your application should be able to accommodate cases where multiple CONNECT events are received for the same call. This can occur, for example, where direct-agent calling is used. A call might first ring at the initial agent's telephone and then at the telephone of a covering agent if the call is not answered by the initial agent. In this case, two CONNECT events are sent to a monitoring application when CONNECT events are triggered on an ASAI-alerting event report.

Your application should be able to accommodate cases where the connected party identified in call events is not a known ACD agent. Depending on switch administration and the design of call vectors, calls can be redirected to domains (VDNs or ACD splits) other than the domain to which the call is originally offered. If calls cover or are redirected from a live-agent split to an AUDIX split, for example, call events can identify an AUDIX channel extension as the connected party.

© 2006 Avaya Inc. All Rights Reserved.