introduced-transfer-threshold
Section: gim-transformation
Default Value: 0
Valid Values: Any nonnegative integer
Changes Take Effect: At the next run of Job_TransformGIM
Dependencies: None
Introduced: 8.5.001
Specifies a time threshold, in seconds, for Genesys Info Mart to treat a conference as an introduced transfer. If the conference initiator's participation is less than the threshold, while the receiving agent continues on the call, Genesys Info Mart treats this call flow as a special case of transfer. The option applies only to voice calls.
Framework-Only Call Flows: Inbound
This page illustrates inbound call flows that Genesys Info Mart supports in deployments with a basic, Framework-only solution.
Based on the dialed number, voice interactions that arrive at the switch are queued to an ACD queue that represents a requested skill, service type, or customer segment. Agents who are logged into the ACD queues handle the interactions.
The following inbound call flows are supported:
- Inbound to agent via ACD queue
- Inbound to agent directly
- Mute transfer to ACD queue
- Mute transfer to agent
- Consult to agent via ACD queue, and then retrieve
- Consult to agent, and then retrieve
- Consult to agent via ACD queue, and then transfer
- Consult to agent directly, and then transfer
- Consult to agent via ACD queue, and then conference
- Consult to agent directly, and then conference
- Consult and transfer of a conference — Customer present throughout
- Consult and transfer of a conference — Customer leaves
- Consult and conference of a conference — Customer present throughout
- Consult and conference of a conference — Customer leaves
- Introduced transfer
For other supported call flows, see Validated Voice Call Flows.
Inbound to agent via ACD queue
| In this call topology, an inbound call is delivered to an agent via an ACD queue. The interaction arrives at the ACD queue, and the ACD queue diverts it to an agent.This diagram and all other diagrams that include ACD queues also illustrate how Genesys Info Mart represents the call flow when the mediation resource is a SIP Server hunt group, instead of a regular ACD queue. In the case of a hunt group with parallel call distribution, Genesys Info Mart creates an IRF for the hunt group member that answers the call; the hunt group members that do not answer the call are not represented in the interaction. For more information about how Genesys Info Mart represents hunt group activity, see Hunt groups.
Technical Descriptors illustrated:
|
 |
Inbound to agent directly
| In this call topology, an inbound call is answered directly by an agent.
Technical Descriptors illustrated:
|
 |
Mute transfer to ACD queue
In this call topology, an inbound call arrives at the ACD queue and is diverted to an agent. The agent then mute-transfers the call to another ACD queue.
There are three possible outcomes of a call that is mute-transferred to an ACD queue:
- The call is abandoned while it is in the second ACD queue.
- The call is abandoned while it is ringing at the second agent.
- The call is successfully transferred to the second agent.
Mute transfer to ACD queue — Abandoned in queue
| For this outcome, the call is abandoned while it is in the second ACD queue.
Technical Descriptors illustrated:
|
 |
Mute transfer to ACD queue — Abandoned while ringing
| For this outcome, the call is diverted to the second agent, but it is abandoned while ringing. If ACD Queue 2 is a parallel hunt group, the resulting IRF (identified in the diagram as the IRF for Agent 2) is for the hunt group. Technical Descriptors illustrated:
|
 |
Mute transfer to ACD queue — Completed
| For this outcome, the call is successfully diverted to another agent.
Technical Descriptors illustrated:
|
 |
Mute transfer to agent
| This call topology shows the outcome of a call that arrives at an agent, who answers the call and then mute transfers it to another agent.
Technical Descriptors illustrated:
|
 |
Consult to agent via ACD queue, and then retrieve
In this call topology, an inbound call arrives at the ACD queue and is diverted to an agent. The agent consults to another ACD queue, and the call is diverted to another agent. The consultation ends when the first agent retrieves the call.
There are three possible outcomes of a call that is retrieved after a consultation has been initiated:
- The call is retrieved while it is in the second queue.
- The call is retrieved while it is ringing at the second agent.
- The call is retrieved after the consultation is completed.
Consult to ACD queue — Abandoned in queue
| For this outcome, the call is retrieved while it is in the second ACD queue. Note that from the IRF perspective, the call is abandoned from the queue because no new handling resource receives the call from the queue.
Technical Descriptors illustrated:
|
 |
Consult to ACD queue — Abandoned while ringing
| For this outcome, the call is retrieved while it is ringing at the second agent. Note that from the IRF perspective, the call is abandoned from the queue because the new handling resource, Agent 2, never receives the call.If ACD Queue 2 is a parallel hunt group, the resulting IRF (identified in the diagram as the IRF for Agent 2) is for the hunt group.
Technical Descriptors illustrated:
|
 |
Consult to ACD queue — Completed
| For this outcome, the call is retrieved after the consultation is completed.
Technical Descriptors illustrated:
|
 |
Consult to agent, and then retrieve
| This call topology shows the outcome of a call that arrives at an agent, who consults to another agent. The consultation ends when the first agent retrieves the call.
Technical Descriptors illustrated:
|
 |
Consult to agent via ACD queue, and then transfer
| This call topology shows the outcome of a call that is transferred after a consultation. The call arrives at the ACD queue and is diverted to an agent. The agent consults to another ACD queue, and the call is diverted to another agent. The consultation ends when the first agent transfers the call.
Technical Descriptors illustrated:
|
 |
Consult to agent directly, and then transfer
| This call topology shows the outcome of a call that is transferred after a consultation. The call arrives at an agent, who consults to another agent, and then transfers the call. The consultation ends when the first agent transfers the call.
Technical Descriptors illustrated:
|
 |
Consult to agent via ACD queue, and then conference
| This call topology shows the outcome of a call that is conferenced after a consultation. The call arrives at the ACD queue and is diverted to an agent. The agent consults to another ACD queue, and the call is diverted to another agent. The consultation ends when the first agent conferences the call.
Technical Descriptors illustrated:
|
 |
Consult to agent directly, and then conference
| This call topology shows the outcome of a call that is conferenced after a consultation. The call arrives at an agent, who consults to another agent. The consultation ends when the first agent conferences the call.
Technical Descriptors illustrated:
|
 |
Consult and transfer of a conference — Customer present throughout
| This call topology shows the outcome of the transfer of a conference. The call arrives at an agent, who consults to another agent and then conferences the call. The second agent then consults to a third agent. The consultation ends when the second agent transfers the conference to the third agent. The customer is present for the entire duration of the call.
Technical Descriptors illustrated:
|
 |
Consult and transfer of a conference — Customer leaves
| This call topology shows the outcome of the transfer of a conference. The call arrives at an agent, who consults to another agent and then conferences the call. The second agent then consults to a third agent. The consultation ends when the second agent transfers the conference to the third agent. The customer leaves the call before the second agent consults the third agent.
Technical Descriptors illustrated:
|
 |
Consult and conference of a conference — Customer present throughout
| This call topology shows the outcome of the conference of a conference. The call arrives at an agent, who consults to another agent and then conferences the call. The second agent then consults to a third agent. The consultation ends when the second agent conferences the third agent. The customer is present for the entire duration of the call.
Technical Descriptors illustrated:
|
 |
Consult and conference of a conference — Customer leaves
| This call topology shows the outcome of the conference of a conference. The call arrives at an agent, who consults to another agent and then conferences the call. The second agent then consults to a third agent. The consultation ends when the second agent conferences the third agent. The customer leaves the call before the second agent consults the third agent.
Technical Descriptors illustrated:
|
 |
Introduced transfer
This call topology shows the reporting results for a short conference that is treated as an introduced transfer, instead of as a regular conference. An introduced transfer occurs when an agent conferences in another agent and then leaves the call before the threshold specified by the introduced-transfer-threshold configuration option is reached. The transfer is achieved through either a two-step or a single-step conference.
Two-step introduced transfer
| Agent 1 transfers the call to Agent 2 via a two-step conference. Agent 1 leaves the conference before the introduced-transfer-threshold is reached, while Agent 2 remains on the call with the customer.
Technical Descriptors illustrated:
|
 |
Single-step introduced transfer
| Agent 1 transfers the call to Agent 2 via a single-step conference. Agent 1 leaves the conference before the introduced-transfer-threshold is reached, while Agent 2 remains on the call with the customer.Support for single-step introduced transfers is limited to deployments in which ICON 8.1.500.04 or higher supports single-step conference (see the Interaction Concentrator 8.1.x Release Note).
Technical Descriptors illustrated:
|
 |