Jump to: navigation, search

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:

For other supported call flows, see Validated Voice Call Flows.

Important
Flows that start in a diagram under one of the other solutions can resume in another diagram under this solution (for example, if a voice interaction in Universal Routing is routed to an agent, and the agent performs a two-step transfer to another agent).

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:

  • DivertedTo/Completed
FWK 001.png


Inbound to agent directly

In this call topology, an inbound call is answered directly by an agent.

Technical Descriptors illustrated:

  • Received/Completed
FWK 002.png


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:

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:

  • DivertedTo/Transferred
  • ReceivedTransfer/CustomerAbandoned [AbandonedWhileQueued]
FWK 006a.png

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:

  • DivertedTo/Transferred
  • InitiatedConsult/Transferred
  • ReceivedTransfer/CustomerAbandoned [AbandonedWhileRinging]
FWK 006b.png

Mute transfer to ACD queue — Completed

For this outcome, the call is successfully diverted to another agent.

Technical Descriptors illustrated:

  • DivertedTo/Transferred
  • InitiatedConsult/Transferred
  • ReceivedTransfer/Completed
FWK 006c.png


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:

  • Received/Transferred
  • InitiatedConsult/Transferred
  • ReceivedTransfer/Completed
FWK 007.png


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:

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:

  • DivertedTo/Completed
  • InitiatedConsult/Abandoned
  • ReceivedConsult/Abandoned
FWK 008a.png

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:

  • DivertedTo/Completed
  • InitiatedConsult/Abandoned
  • ReceivedConsult/Abandoned
FWK 008b.png

Consult to ACD queue — Completed

For this outcome, the call is retrieved after the consultation is completed.

Technical Descriptors illustrated:

  • DivertedTo/Completed
  • InitiatedConsult/Completed
  • ReceivedConsult/Completed
FWK 008c.png

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:

  • Received/Completed
  • InitiatedConsult/Completed
  • ReceivedConsult/Completed
FWK 009.png


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:

  • DivertedTo/Transferred
  • InitiatedConsult/Transferred
  • ReceivedTransfer/Completed
FWK 010.png


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:

  • Received/Transferred
  • InitiatedConsult/Transferred
  • ReceivedTransfer/Completed
FWK 011.png


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:

  • DivertedTo/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Completed
FWK 012.png


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:

  • Received/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Completed
FWK 013.png


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:

  • Received/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Transferred
  • InitiatedConsult/Transferred
  • ReceivedTransfer/Completed
FWK 014.png


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:

  • Received/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Transferred
  • InitiatedConsult/Transferred
  • ReceivedTransfer/Completed
FWK 015.png


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:

  • Received/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Completed
FWK 016.png


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:

  • Received/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Conferenced
  • InitiatedConsult/Conferenced
  • InConference/Completed
FWK 017.png


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:

  • Received/Transferred [IntroducedTransfer]
  • InitiatedConsult/Transferred [IntroducedTransfer]
  • ReceivedTransfer [IntroducedTransfer]/Completed
GIM FWK IntrodTransfer 2Step.png

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:

  • Received/Transferred [IntroducedTransfer]
  • ReceivedTransfer [IntroducedTransfer]/Completed
GIM FWK IntrodTransfer 1Step.png
This page was last edited on August 3, 2017, at 15:33.
Comments or questions about this documentation? Contact us for support!