# Queued callbacks in real-time metrics in Amazon Connect
About queued callbacks

This topic explains how queued callbacks appear in your real-time metrics reports and the contact record.

**Tip**  
To see only the number of customers who are waiting for a call back, you need to create a queue that only takes callback contacts. To learn how to do this, see [Set up routing in Amazon Connect](connect-queues.md). Currently there isn't a way to see the phone numbers of the contacts waiting for callbacks.

1. Callbacks are initiated when the [Transfer to queue](transfer-to-queue.md) block is triggered to create the callback in a callback queue. The following image of a flow shows the **Transfer to queue** block at the end of the flow.  
![\[A flow with the Transfer to queue block at the end.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/queued-callback-flow-callback-initiation.png)

1. After any initial delay is applied, the callback is put into the queue. It remains there until an agent is available and can be offered the contact. The following image shows the contact in the **In queue** column on the **Real-time metrics** page.  
![\[A contact listed in the In queue column on the real-metrics page.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/rtm-callback-in-queue.png)

1. When the callback is connected to the agent, a new contact record is created for the contact. The following diagram shows three contact records. The third record is for the callback, connected to Agent 3.  
![\[Three blocks, one for each contact record.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/ctr-diagram.png)

1. The **Initiation Timestamp** in the callback contact record corresponds to when the callback is initiated in the flow, shown in step 1. The following image shows the **Initiation Timestamp** field on the **Contact Record** page.  
![\[The contact record page, the Initiation Timestamp field.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/ctr-callback-initiation-timestamp.png)

## How properties in the Transfer to Queue block affect this flow


The [Transfer to queue](transfer-to-queue.md) block has the following properties, which affect how Amazon Connect handles the callback:
+ **Initial delay**: This property affects when a callback is put in queue. Specify how much time has to pass between a callback contact being initiated in the flow, and the customer being put in queue for the next available agent. For more information, see [How Initial delay affects Scheduled and In queue metrics in Amazon Connect](scheduled-vs-inqueue.md). 
+ **Maximum number of retries**: If this is set to 2, then Amazon Connect tries to call the customer at most three times: the initial callback, and two retries. 
+ **Minimum time between attempts**: If the customer doesn't answer the phone, this is how long to wait before trying again. 

## Callback metrics


Use the following metrics to monitor the number of callbacks in your business:
+ [Callback contacts](metrics-definitions.md#callback-contacts): This metric represents the count of contacts that were initiated from a queued callback. That is, how many customers opted for queued callback.
+ [Callback contacts handled](metrics-definitions.md#callback-contacts-handled): This metric counts the contacts that were initiated from a queued callback and handled by an agent. That is, how many of the callbacks were answered.
+ [Callback attempts](metrics-definitions.md#callback-attempts): This metric represents the number of contacts where a callback was attempted, but the customer did not pick up.

# How Initial delay affects Scheduled and In queue metrics in Amazon Connect
Scheduled vs In queue

In the [Transfer to queue](transfer-to-queue.md) block, the **Initial delay** property affects when a callback is put in queue. For example, assume **Initial delay** is set to 30 seconds. Here's what appears in your real-time metrics report:

1. After 20 seconds, the callback has already been created, but it is not yet in queue because of the **Initial delay** setting. In the following image of the **Real-time metrics** page, **In queue** = 0 and **Scheduled** = 1.  
![\[A contact that is scheduled but is not in queue.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/rtm-callback-scheduled.png)

1. After 35 seconds, the callback contact has been placed in queue. In the following image, the callback is now **In queue**. It is no longer scheduled.  
![\[The In queue column has a 1, the Scheduled column has a 0.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/rtm-callback-in-queue2.png)

1. Assume that after 40 seconds, an agent accepts the callback. The **In queue** column = 0, the **Scheduled** column = 0.  
![\[The In queue column has a 1, the Scheduled column has a 0.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/rtm-callback-accepted-by-agent.png)

# Failed callback attempts in Amazon Connect
Failed callback attempts

If an agent doesn't accept an offered callback, it doesn't count as an failed callback attempt. Rather, the routing engine offers the callback to the next available agent, until an agent accepts. 

A failed callback attempt would be along the lines of: an agent accepts a callback but then something goes wrong between then and the agent being joined to the customer.

The contact is considered to be in the callback queue until an agent accepts the offered callback contact.

Amazon Connect removes the callback from the queue when it's connected to the agent. At that time, Amazon Connect starts dialing the customer. 

The following image shows what this looks like in a contact record: 
+ Dequeued At: The timestamp of when the callback was connected to the agent. It's also when Amazon Connect starts dialing the customer.

![\[A contact record that contains a dequeued at time.\]](http://docs.aws.amazon.com/connect/latest/adminguide/images/ctr-enqueue-and-dequeue.png)


The enqueued time on the contact record for a particular callback leg corresponds to the amount of time that the contact was in queue before that particular callback attempt was made. This is not the total enqueued time across all contact records. 

For example, an inbound call could be in queue for 5 minutes before a callback is scheduled. Then, after an initial delay of 10 seconds, the callback contact could be in a callback queue for 10 seconds before an agent accepts it. In this case, you would see two contact records:

1. The first contact record, with InitiationMethod=INBOUND, would have an enqueued time of 5 minutes.

1. The second contact record, with InitiationMethod=CALLBACK, would have an enqueued time of 10 seconds.

# Amazon Connect real-time metrics example for a queued callback flow
Example: Metrics for a queued callback

This topic shows an example queued callback flow and reviews how the contact records and times are set for it. 

Assume we have set up the following flows:
+ **Inbound flow** -- Runs when the customer calls the customer service number.
+ **Customer queue flow** – Runs when the customer is waiting in queue. In this example, we build a flow that offers a callback to the customer. If the customer selects yes, this flow executes the **Transfer to queue** block to transfer the contact to the callback queue named CallbackQueue, with an initial delay of 99 seconds, and then hangs up.
+ **Outbound whisper flow** -- When a queued callback is placed, the customer hears this after they pick up and before they connect to the agent. For example, "Hello, this is your scheduled callback..."
+ **Agent whisper flow** -- The agent hears this right after they accept the contact, before they are joined to the customer. For example, "You are about to be connected to Customer John, who requested a refund for..."

In this example, John calls customer service. Here's what happens:

1. Inbound flow creates contact record-1:

   1. John calls customer service at 11:35. The Inbound flow runs and puts him in queue at 11:35. 

   1. The Customer queue flow runs. At 11:37, John chooses to schedule a callback, so Amazon Connect initiates a callback contact at 11:37, before the inbound contact is disconnected. 

1. Callback flow creates contact record-2:

   1. The callback contact was initiated at 11:37.

   1. Because the initial delay is 99 seconds, the callback contact is placed into CallbackQueue at 11:38:39, after the 99 seconds pass. Now the callback contact is offered to an available agent. 

   1. After 21 seconds, an agent available at 11:39:00 and accepts the contact. The 10-second agent whisper flow is played to the agent. 

   1. After the agent whisper flow is complete, Amazon Connect calls John at 11:39:10. John picks up, and listens to the 15-second outbound whisper flow. 

   1. When the outbound whisper flow is complete, John is connected to the agent at 11:39:25. They talk until 11:45, and then John hangs up. 

This scenario results in two contact records, which include the following metadata.


| Contact record-1 | Data | Notes | 
| --- | --- | --- | 
|  Initiation Method  | Inbound  |   | 
|  Initiation Timestamp  | 11:35  | The inbound contact is initiated in Amazon Connect.  | 
|  ConnectedToSystem Timestamp  | 11:35  | Because this is an inbound contact, InitiationTimestamp = ConnectedToSystemTimestamp.  | 
|  Next Contact Id   | points to contact record-2  |   | 
|  Queue  | InboundQueue  |   | 
|  Enqueued Timestamp  | 11:35  | The inbound contact is put in queue.  | 
|  Dequeued Timestamp  | 11:37  | Because no agent picked up, this is the same as DisconnectedTimestamp.  | 
|  ConnectedToAgent Timestamp  | N/A  | John scheduled a callback before any agent could pick up.  | 
|  Disconnected Timestamp  | 11:37:00  | John was disconnected by flow.  | 


| contact record-2 | Data | Notes | 
| --- | --- | --- | 
|  PreviousContactId  | points to contact record-1  |   | 
|  Initiation Timestamp  | 11:37  | The callback contact is created in Amazon Connect.  | 
|  Queue  | CallbackQueue  |   | 
|  Enqueued Timestamp  | 11:38:39  | The contact was put into the CallbackQueue, after the 99-second initial delay completes.  | 
|  Dequeued Timestamp  | 11:39:00  | After 21 seconds, an agent accepts the contact.  | 
|  Queue Duration  | 120 seconds  | This is the initial delay (99 seconds), plus any additional time sitting in queue waiting for an agent to become available (21 seconds).  | 
|  ConnectedToSystem Timestamp  | 11:39:10  | John is called after the 10 second agent whisper flow completes.  | 
|  ConnectedToAgent Timestamp  | 11:39:25  | John and the agent are connected, after the 15 second outbound whisper flow completes.  | 
|  Disconnected Timestamp  | 11:45  | John hangs up.  |