Use customer first callback mode in Amazon Connect

When you set up queued callbacks, you have the additional choice of whether to use agent first callback mode or customer first callback mode.

The lifecycle of a customer first callback

The lifecycle for customer first callbacks is spread across three different contacts, as shown in the following diagram.

Following is a description of each contact.

Retries for customer first callbacks

Retry behavior for customer first callbacks differs significantly from agent first callbacks. Retries are configured on the dialed callback contact (C3), not on the queued callback contact (C2).

How retries work

Configure retries with Check Call Progress

Use the Check call progress block in the C3 outbound flow to detect whether a human or voicemail answered the call. Based on the output, configure the flow as follows:

The AnsweringMachineDetectionStatus field on the C3 contact record captures the full answering machine detection result. Possible values include:

HUMAN_ANSWERED | VOICEMAIL_BEEP | VOICEMAIL_NO_BEEP | AMD_UNANSWERED | AMD_UNRESOLVED | AMD_NOT_APPLICABLE | SIT_TONE_BUSY | SIT_TONE_INVALID_NUMBER | SIT_TONE_DETECTED | FAX_MACHINE_DETECTED | AMD_ERROR

Adjust priority for retry contacts

To ensure retry contacts are routed appropriately, use the callback creation flow that runs when the C4 contact is created. The recommended approach is:

This approach allows you to differentiate first-attempt callbacks from retries and apply custom prioritization logic without relying on external state.

Control retry timing

By default, retry timing is not system-controlled for customer first callbacks – you have full control over when a retry is initiated.

To introduce a delay between retry attempts, use the Initial delay parameter in the Transfer to queue block when recreating the callback contact (C4) in the C3 outbound flow. This is the recommended approach because it:

A typical retry flow with timing control looks like:

Metrics for customer first callbacks

You can access the following metrics in either the Queue performance dashboard or by using the GetMetricDataV2 API.

Example contact records for customer first callbacks

Following are example contact records to show what information is stored for the C2 and C3 legs of a customer first callback.

Example C2 queued customer first callback contact record

InitialContactId : C1 (Inbound contact)
ContactId : C2 (this contact)
PreviousContactId : C1 (Inbound contact)
NextContactId : C3 (Dialed customer first callback contact)
Channel : VOICE,
InitiationMethod : CALLBACK_CUSTOMER_FIRST_QUEUED, 

ConnectedToSystemTimeStamp : time // Timestamp when callback creation flow got started

CustomerEndpoint : customer phone number endpoint

DisconnectTimestamp : time // Timestamp indicating contact is disconnected and customer will be dialed

DisconnectReason : // Disconnect reason code 

InitiationTimeStamp : time // Timestamp indicating customer first callback has been created in connect systems

QueueInfo : {
    Arn : arn // Queue arn representing customer first callback queue
    EnqueueTimeStamp : time // Timestamp indicating customer first callback has been put in queue and waiting out to dial.
    DequeueTimeStamp : time // Timestamp indicating customer first callback has been taken out from queue to dial out end customer.
    Duration : time // total time it took connect systems to dial out end customer. 
}

Example C3 dialed customer first callback contact

InitialContactId : C1 (Inbound contact)
ContactId : C3 (this contact)
PreviousContactId : C2 (Queued customer first callback contact)
Channel : VOICE,
InitiationMethod : CALLBACK_CUSTOMER_FIRST_DIALED,

ConnectedToSystemTimeStamp : time // Timestamp when the outbound call associated with callback was connected with customer.

CustomerEndpoint : customer phone number endpoint

SystemEndpoint : Outbound caller id assigned to the outbound queue

Agent : {
    // All agent information associated with the outbound call. 
    // Like Agent Arn, ConnectToAgentTimestamp, ACW duration etc. 
}

AgentConnectionAttempts : number

DisconnectTimestamp : time // Timestamp indicating outbound call for the callback is disconnected

DisconnectReason : // Disconnect reason code

SegmentAttributes : { 
    'connect:TrafficType' : 'CUSTOMER_FIRST_CALLBACK'
}, 

AnsweringMachineDetectionStatus : HUMAN_ANSWERED|VOICEMAIL_BEEP|VOICEMAIL_NO_BEEP|AMD_UNANSWERED|AMD_UNRESOLVED|AMD_NOT_APPLICABLE|SIT_TONE_BUSY|SIT_TONE_INVALID_NUMBER|SIT_TONE_DETECTED|FAX_MACHINE_DETECTED|AMD_ERROR|AMD_UNRESOLVED_SILENCE(WIP)

CustomerVoiceActivity : {
    GreetingStartTimestamp : timestamp
    GreetingEndTimestamp : timestamp
}

InitiationTimeStamp : time // Timestamp indicating start of outbound call to customer
 
QueueInfo : {
    Arn : arn // Queue arn representing customer first callback queue
    EnqueueTimeStamp : time // Timestamp indicating customer first callback has been put in queue to join with agent.
    DequeueTimeStamp : time // Timestamp indicating customer first callback has been taken out from queue to join with agent.
    Duration : time // total time it took connect systems to join dialed end customer with agent.
    CallbackTotalQueueDuration : time // total time the customer first callback spent in queue (Includes the total queued time for C2 and C3.)
}

Sample flows for customer first callbacks

The following sample flows show how you can configure a flow for customer first callbacks.

Sample Inbound call flow

The following image shows a Transfer to queue block in a flow.

In this flow, the Transfer to queue has Set creation flow configured and an outbound dial flow is specified.

Sample callback creation flow configuration

The following image shows a sample callback creation flow. The Set customer queue flow block is configured so a customer queue flow runs while the callback contact is in queue waiting for agent availability to dial out to customers.

Example outbound dial flow for callbacks

In the outbound dial flow shown in the following image, Amazon Connect evaluates the presence of the customer by using a Check call progress block. If voicemail is detected, a callback contact is recreated. If a customer is detected on other end of the call, the call is transferred to queue for the agent to be joined to the customer.