Call transfer and consult call

​When agent 1 has answered a call, he or she may do a consult call and/or a call transfer.

Blind transfer to agent or a phone number

If agent 1 transfers the caller to agent 2 (or a phone number), a new Conversation event is created, and you can see in agent 1’s Conversation event that the call was transferred (call_transfer=1). The Conversation event for the call to agent 2 (or the phone number transferred to) will not contain a queue_key.

​​​Consult + transfer

If agent 1 makes a consult call to an agent or a phone number (caller is on hold while consult is ongoing) and then transfers the call, the Conversation event for agent 2 will (not have a queue_key and) be partly overlapping in time with the Conversation event for agent 1.

Consult only

If agent 1 does a consult call to agent 2 without transferring, the Conversation event for agent 1 will have call_transfer=0, and the conversation event for agent 2 will not have a queue_key. The caller is put on hold while while consult is ongoing.  

Transfer to queue

If agent 1 transfers the caller to a queue, there will be a new Queue event and possibly one or more new Conversation events later.

Consult to queue

If agent 1 makes a consult call to a queue (to consult with any agent on that queue), agent 1 can transfer the caller to agent 2 after agent 2 on the new queue has answered:


If agent 1 makes a consult call to a queue, agent 1 can end the consult (and continue speaking with the caller) after having spoken with the other agent:


If agent 1 makes a consult call to a queue, but no agent answers within a short time, the agent can abort the consult and continue speaking with the caller:


A very special case for abort consult to queue
If agent 1 clicks Consult (to queue 2) and then clicks Abort after agent 2 (from queue 2) is allocated (it's ringing on agent 2's phone), agent 1 will be connected to agent 2 if agent 2 answers. This special situation results in a Raw data queue event with result = c (cancel) even though the following conversation event is answered. 


Caller hangs up while agent1 is consulting with agent2

If a consult call between agent1 and agent2 lasts “too” long, the caller might hang-up while waiting to be reconnected to agent1 or transferred to agent2. If the caller hangs up during a consult call, the consulting agents will hear a notification (“Caller hung up”) and then they will hang up after a while. In this case, you will see that the initiation event ends before the conversation events end, and both conversation events end at the same time.

Transfer to not ready agent / Personal queue

If a Personal queue is configured in the Puzzel solution, an agent can transfer a caller to another agent that is logged on but not ready. If a caller is transferred to a not ready agent, the caller is put in the Personal queue waiting for this agent. When the agent becomes Ready, the call is sent to the agent (unless the caller has hung-up while waiting in the Personal queue).

Put on hold

The agent may put the caller on hold (during the reported Speaktime). This on-hold time is not specified in the Conversation event.

An agent can put the caller on hold one or more times, and an agent can make a consult call (which results in caller being put on hold) one or more times, before the agent possibly transfers the caller to another agent (directly or through a queue), and this new agent might put caller on hold and/or make consult calls.

In statistics reports Details per agent per queue and Details per agent we have lots of columns, including “Put on hold” and “Consults done”. These columns show the number of answered calls in which the agent put the caller on hold / did a consult call, not on hold duration.

It is possible for Puzzel on request (for an extra fee) to configure that we calculate and store the total time each caller is put on hold in a call_variable called e.g. ‘caller_on_hold_total’. Please note that this covers the basic Put on hold cases, and not Consult cases, and that the total on hold duration experienced by one caller might be caused by 1 or 2 (or more) agents clicking Put on hold. 

Such a call_variable will appear in table call_variables, and also be shown in the Archive as other call_variables.


07/08/2020 - 11:03

Last updated

29/08/2022 - 07:29