Call-flow design

Avaya IR system-to-agent transfers

Avaya IR system-to-agent transfers are accomplished by using the A_Tran external function within a voice application that is servicing a caller. The use of A_Tran invokes ASAI Third Party Call Control operations to transfer a call away from the telephony channel to which the caller is connected. The caller is transferred to the destination that is identified in the Destination Number field of the A_Tran external function.

The transferred call can be monitored by a monitoring application so that data screen delivery applications can be supported for Avaya IR system-to-agent transfers. The transferred call can be monitored in two different ways:

• The call can be transferred to a VDN or ACD split domain that is monitored by the Avaya IR system with a monitoring application. Call events for the transferred call are passed to the application that is monitoring the domain to which the call is transferred.
• The call can be monitored using a CTL type monitoring application. In this case, the call can be transferred to nonmonitored domains and individual stations. Here, only call events for calls that are transferred from the Avaya IR system to agents are passed to monitoring applications. Other direct calls to an ACD split, for example, are not monitored. Therefore, no call events for the direct calls are passed to monitoring applications.

You can use a combination of the above two monitoring mechanisms on the same Avaya IR system.

In addition to monitoring the transferred call, the application developer can save data that is collected in the voice application for subsequent use in the data screen delivery application. To do this, use the Avaya IR system Data field of A_Tran. Any data saved that is in this field when the transfer is initiated from the voice application is presented in call events that are passed to the monitoring application that monitors the transferred call. The Avaya IR system Data field provides storage for 20 characters. Note that multiple data items can be stored in this field. A social security number and PIN number, for example, can be collected in the voice application, concatenated, and then saved in the Avaya IR system Data field. The monitoring application that receives this data in call events can then unbundle the information for use in data screen delivery when the transferred call is delivered to an agent.

Typical call flow for Avaya IR system-to-agent transfers

The following is a typical call flow for a Avaya IR system-to-agent transfer:

1. A call arrives at a telephony channel on the Avaya IR system. The caller is prompted through a voice response application.
2. The caller decides to speak to a live agent after entering an account number. The voice application transfers the call to a live agent group using the A_Tran external function. The account number that the caller input is saved by using the Avaya IR system Data field of A_Tran. The voice application terminates after the transfer is complete and the telephony channel is free to handle another call.
3. The transferred call is queued for an available agent. When the call is eventually delivered to an agent, a monitoring application on the Avaya IR system receives a CONNECT event for the call. The Avaya IR system Data field of this CONNECT event contains the account number that was previously saved by the voice application. The monitoring application passes the account number along with the connected agent information from the CONNECT event to the host.
4. The host application uses the account number to format a data screen concerning the caller and presents this data screen to the agent who receives the call. The host application does not need to associate multiple calls since all the necessary information for the transferred call is provided in a single CONNECT event.

One CONNECT event is generated for the entire scenario. This is the CONNECT event for the transferred call as it is delivered to the live agent. This CONNECT event contains the Avaya IR system Data information in addition to ASAI information that is related to the original call to the Avaya IR system. The ANI and DNIS for the original call prior to the transfer, for example, are reported in this CONNECT event. Also, the Other Call ID field contains the call ID of the call that was originally delivered to the Avaya IR system's telephony channel. Call events for calls to telephony channels on the Avaya IR system are not passed to monitoring applications. Also, one END event is generated when the call eventually terminates. As with the CONNECT event, the END event contains data that is pertinent to the original call. See Call flow examples for a detailed call flow example.

Considerations for Avaya IR
system-to-agent transfers

Additional considerations for Avaya IR system-to-agent transfers are as follows:

• In some cases, you might want to collect more data in a voice application than can be stored in the Avaya IR system Data field. The recommended method for handling this is to save the data collected by the voice application in the host application. Use A_Callinfo to retrieve the call ID of the call that is delivered to the telephony channel. Pass the call ID along with the data to the host from the voice application itself. The host application must buffer the data until the CONNECT event for the transferred call is received. The call ID in the Other Call ID field of the CONNECT event can be used to correlate the two calls.
• The call can be transferred again after having been serviced by the live agent. In this case, an END event is not reported until all transferring is complete and the call terminates normally. As in the case of a single transfer, the END event contains information pertinent to the original call. Rules for how subsequent call events are reported are discussed in Agent-to-Agent Transfers.
• The discussions on blind and consult transfers do not apply to Avaya IR system-to-agent transfers completed using the A_Tran external function. Also, the delay needed for agent-to-agent transfers discussed later does not apply to Avaya IR system-to-agent transfers completed using the A_Tran external function.
• Transfers away from the Avaya IR system can still be accomplished by using standard flash transfer mechanisms. This type of transfer, however, precludes the ability to use the Avaya IR system Data field of the A_Tran screen to save voice application data for later use in data screen delivery applications. Also, the host application must view this type of transfer as an agent-to-agent transfer. Hence, the discussions on blind transfer versus consult transfer and the need to introduce delay for blind transfers from the Avaya IR system apply.

Agent-to-agent transfers

There are two options for call transfer in an agent-to-agent transfer scenario: blind transfer and consult transfer. These two options differ as to when the screening agent (the agent transferring the call) completes the transfer to the specialized agent (the agent receiving the transferred call) by pressing the Transfer button a second time.

• With a blind transfer, the screening agent presses the Transfer button a second time immediately after dialing. The screening agent does not talk to the specialized agent before completing the transfer. In addition, a delay is built into call handling so that the call is distributed to a specialized agent after the screening agent presses the Transfer button the second time.
• With a consult transfer, the screening agent waits until the specialized agent answers before pressing the Transfer button a second time.This allows the screening agent to talk to the specialized agent before completing the transfer.

Both of these call-transfer options are described in more detail later. To set up either a blind transfer or a consult transfer, it is important to understand two key concepts of how transferred calls are handled on the DEFINITY G3 switch.

Call monitoring in transfer scenarios

The Avaya IR system monitors VDN or ACD split domains by assigning monitoring applications. A call becomes monitored once it enters one of these monitored domains. The Avaya IR system must also monitor all domains to which this call can be directed. Once monitored, therefore, a call remains monitored for the duration of the call even though it can be transferred several times. Once a call becomes monitored, call events are passed to the monitoring application that is assigned to the domain the call entered. A CONNECT event, for example, is passed to a monitoring application when a specific agent is selected to receive the call. The screening agent may transfer calls to other monitored VDN and ACD splits or to individual stations. The original call to the screening agent must be monitored and therefore delivered to the screening agent via a monitored VDN or ACD split.

Call ID management in transfer scenarios

The DEFINITY G3 switch assigns a call ID to each call. The call ID is provided in the Call ID field of call events for the call. In agent-to-agent transfer scenarios, there are multiple calls and, therefore, multiple call IDs as described in the following transfer scenario:

1. The original call is delivered to an agent and is assigned a unique call ID. The agent talks with the caller and decides that the call needs to be transferred to another agent.
2. The first press of a Transfer button places the original call on hold and allows another call to be placed from the transferring telephone.
3. A second call, temporarily independent of the first call, is placed from the transferring telephone. This call is assigned a call ID that is different from that of the original call. If this second call is placed to a monitored domain, the call immediately becomes monitored by the Avaya IR system and call events can be passed to a monitoring application. If this second call is placed to an individual station, the call does not become monitored until the transfer is complete as described in Step 4.
4. The second press of the Transfer button merges the original call which is on hold with the second call and drops the transferring telephone from the resultant call.

The Avaya IR system is informed about the completed transfer immediately after the merge that occurs in Step 4. It is only after this merge, therefore, that the Avaya IR system has the ability to associate the two calls.

With a blind transfer, this merge takes place before the merged call is delivered to the second, specialized agent. Hence, with blind transfer calls, the Avaya IR system can include information in the CONNECT event for the merged call that relates to the original call. In particular, the Avaya IR system retains the call ID of the original call and reports it in the Other Call ID field of the call events for the transferred call. This mechanism allows the host application to use call ID to associate the transferred call with the original call.

With a consult transfer, the merge takes place after the second call is delivered to the second, specialized agent. In this case, the original call is still on hold at the first agent's telephone when the second call is delivered to the second agent. Hence, for consult transfers, the Avaya IR system can only provide information that is related to the second call in the CONNECT event for the second call. In particular, the call ID of the original call is not reported in the Other Call ID field of the CONNECT event for the second call. The host application must use a mechanism other than call ID to associate the original call with the second call. The alternate mechanism is the CPN information as discussed below.

Blind transfer

With a blind transfer, the screening agent does not talk to the specialized agent before completing the transfer. With this type of transfer, the Avaya IR system retains the call ID of the original call and reports it in the Other Call ID field of call events for the transferred call. Also, other ASAI information such as ANI and DNIS that is related to the original call is reported in the call events for the transferred call.

A typical call flow for blind transfers is described below. In this call flow, Agent 1 is a live agent in a screening split who transfers calls to specialized agents. Agent 2 is a specialized agent who can either receive calls via a monitored VDN or ACD split or via a regular extension. Calls to Agent 1 in the screening split must be delivered via a monitored VDN or ACD split.

1. A call arrives for Agent 1.
2. Agent 1 answers the call and enters pertinent information about the caller.
3. Agent 1 transfers the call to Agent 2 by pressing the transfer button, dialing the VDN, ACD split, or individual extension and pressing the transfer button again.
4. Agent 1 is finished with the call.
5. The host application uses call ID information reported in CONNECT events to determine which data to display on Agent 2's data-terminal screen. The call ID from the Call ID field of the CONNECT event for the original call matches the call ID provided in the Other Call ID field of the CONNECT event for the transferred call.

Two CONNECT events are passed to monitoring applications for the entire scenario, that is, one for the original call to the screening agent and one for the transfer to the specialized agent. One END event is generated when the call eventually terminates. See Call flow examples for detailed examples that include complete descriptions of call flows and call-event contents.

The following conditions should be noted for blind transfers:

• The domain that receives the original call and any domains that receive the transferred call must be monitored.
• Calls can be transferred either to a monitored domain or to a station. For a blind transfer to a monitored domain, the following must be considered:
  • The agent must complete the transfer immediately after initiating it by pressing the Transfer button a second time.
  • A delay must be built into the flow of the transfer so that the communications system can recognize the completion of the transfer before the receiving agent is selected for the call. You can create this built-in delay by transferring calls to a VDN. This VDN is associated with a vector that has a wait step in it. The vector directs the call to the desired split with a route to or queue to step.

    For blind transfer to a station, the following must be considered:

  • When an agent in a monitored domain completes a transfer to a station rather than to an ACD split, a CONNECT event is passed to a monitoring application. The agent must initiate and complete the transfer by pressing the Transfer button a second time for the CONNECT event to be passed to the application. The CONNECT event therefore only becomes available to the host application when the agent pushes the Transfer button the second time.
• In call-center operations that use blind transfer, the host application can tag current call data by call ID. The call ID allows the application to determine which data is associated with the call as the call is transferred to a monitored domain or station.
• If for some reason calls are transferred to nonmonitored domains, unexpected operation can result. When the call placed by Agent 1 is not initially monitored, the Avaya IR system assumes that a transfer to a station is taking place. Hence, two CONNECT events for the transferred call are generated. One CONNECT event is generated when the transfer is completed by Agent 1 and another is generated when the call is actually delivered to Agent 2. Also, the Connected Party Number field of the first CONNECT event for the transferred call identifies the ACD split or VDN extension that was dialed by Agent 1, rather than identifying the extension of Agent 2. Note that the Connected Party Number field of the second CONNECT event for the transferred call identifies the extension of Agent 2.
• The END event that is reported for the transferred call contains information pertinent to the original call. For example, the original ANI for the caller is reported in the Calling Party Number field and the call ID for the original call is reported in the Other Call ID field. Also, an END event is reported for a call only when the call ultimately terminates. An END event is not reported when a call is transferred.
• The call can be transferred again after it is serviced by Agent 2. In this case, an END event is not reported until all transferring is completed and the call terminates normally. As in the case of a single transfer, the END event contains information that is pertinent to the original call. Rules for how subsequent CONNECT events are reported are as described in this section and depend on whether the call is transferred to a monitored domain or to a station and whether consult or blind transfer operation is used.

Consult transfer

With a consult transfer, the screening agent talks to the specialized agent before completing the transfer. With this type of transfer, the call ID for the original call is not retained by the Avaya IR system and is not reported in the Other Call ID field of call events for the transferred call.

A typical call flow for consult transfers is described below. In this call flow, Agent 1 is a live agent in a screening split who transfers calls to specialized agents. Agent 2 is a specialized agent who can receive calls via a monitored VDN or ACD split or via an individual station. Calls to Agent 1 in the screening split must be delivered via a monitored VDN or ACD split.

1. A call arrives for Agent 1.
2. Agent 1 answers the call and enters pertinent information about the caller.
3. Agent 1 presses the Transfer button.
4. Agent 1 dials the extension of the monitored domain or station to which the call will be transferred.
5. Agent 1 waits for Agent 2 to answer.
6. Agent 1 and Agent 2 consult privately about the caller.
7. Agent 1 presses the Transfer button again to complete the transfer.
8. Agent 1 is finished with the call.
9. The host application uses calling party information to determine which data to display on Agent 2's data terminal screen. The extension for Agent 1 is reported in the Calling Party Number field of the CONNECT event for the second call.

Two CONNECT events are passed to monitoring applications for the entire scenario, one for the original call to the screening agent and one for the call to the specialized agent. One END event is generated when the call eventually terminates.

See Call flow examples for detailed examples that include complete descriptions of call flows and call-event contents.

The following conditions should be noted for consult transfers:

• With a consult transfer, Agent 1 and Agent 2 generally both view the call data in a private consultation while the caller is on soft hold.
• Calls can be transferred either to a monitored domain or to an individual station. For a consult transfer to a monitored domain, the following must be considered:
  • When Agent 2 is selected to receive the call from Agent 1, a CONNECT event is made available to a monitoring application. Since Agent 1 stays on the line until Agent 2 answers, the two calls have not yet been merged. This implies that the CONNECT event for the second call does not contain information that is pertinent to the first call. The Other Call ID field for the second CONNECT event, for example, is NULL and does not contain the call ID of the first call. Also, for example, the Calling Party Number field contains the extension for Agent 1 and not the ANI for the caller. This is because the second call is viewed as a new, direct call to Agent 2 from Agent 1. The Avaya IR system cannot assume that the two calls will eventually be merged since in some cases, they will not be. Hence, the two calls cannot be correlated by using call ID from CONNECT events.
  • In this case, the Calling Party Number field of the second CONNECT event should be used to correlate the two calls. This field contains the extension for Agent 1. The host application can assume that Agent 1 is performing a consult transfer. The host application can then retrieve the appropriate data from Agent 1's data-terminal screen and deliver it to Agent 2's data-terminal screen. After the two agents consult, Agent 1 can complete the transfer by pressing the Transfer button a second time. No additional CONNECT event is passed to a monitoring application when the transfer is completed.

    For consult transfer to a station, the following must be considered:

  • A CONNECT event for the second call is passed to a monitoring application only after the transfer is completed when Agent 1 presses the Transfer button the second time. This means that when Agent 1 and Agent 2 are talking privately, the host application will not have been notified about the second call to Agent 2. This is because the second call is placed to a station and not to a monitored domain. The Avaya IR system, therefore, does not receive events for the second call until the two calls are merged. The host application can be programmed to allow the receiving station to query for the data. After the transfer is complete, a CONNECT event is passed to a monitoring application. This CONNECT event contains information that is pertinent to the first call. The Other Call ID field of this CONNECT event, for example, contains the call ID of the original call that was delivered to Agent 1. Also, for example, the Calling Party Number field of this CONNECT event contains the ANI of the original caller.
• If calls are transferred to nonmonitored domains, an unexpected operation can result. When the call to Agent 2 from Agent 1 is not initially monitored, the Avaya IR system assumes that a transfer to a station is taking place. Hence, the Connected Party Number field of the CONNECT event generated when the transfer is completed by Agent 1 identifies the ACD split or VDN extension dialed by Agent 1, rather than the extension of Agent 2.
• The END event reported for the transferred call contains information that is pertinent to the original call. For example, the original ANI for the caller is reported in the Calling Party Number field and the call ID for the original call is reported in the Other Call ID field. This is true even though the second CONNECT event for consult transfers to monitored domains does not contain information that is pertinent to the original call. This is because the END event is reported after consult transfers to monitored domains are completed; that is, after the two calls are merged and can be associated by the internal software on the Avaya IR system. Also, an END event is reported for a call only when the call ultimately terminates (that is, an END event is not reported when a call is transferred). These properties for END events allow the host application to consistently use the Other Call ID field of END events to identify when and which calls have left the DEFINITY G3 switch entirely.
• The call can be transferred again after it is serviced by Agent 2. In this case, an END event is not reported until all transferring is completed and the call terminates normally. As in the case of a single transfer, the END event contains information that is pertinent to the original call. Rules for how subsequent CONNECT events are reported are as described in this section and depend on whether the call is transferred to a monitored domain or to a station and whether consult or blind transfer operation is used.

© 2006 Avaya Inc. All Rights Reserved.