Then loop prompts block in Amazon Connect loops a sequence of prompts while a customer or agent is on hold or in queue.

Please note that you should always use an interruption period that’s greater than 20 seconds. This is the amount of time an available agent has to accept the contact. If the interruption period is less than 20 seconds, you might get contacts going down the Error branch. This is because Amazon Connect doesn’t support dequeueing the customer when they are being routed to an active agent and are in the 20 second window to join.
In other words, if at any interval the call is transferred while the call in queue is in the process of being offered to an agent recently so that the agent connection is still ongoing, this transfer will fail.
Below is my experiment on this topic.
I created a Connect instance and added set logging block, set working queue block, set customer queue flow block, transfer to queue block and disconnect block to the contact flow. In addition I created a customer queue flow including loop prompts block, transfer to phone block and end flow/ Resume block.


Then I set the loops prompts with an interrupt at 19s, 20s, 21s, 25s and 30s and tested them respectively. The testing result is as below.
Then I set the loops prompts with an interrupt at 19s, 20s, 21s, 25s and 30s and tested them respectively. The testing result is as below.
// Interrupt every 19s: After 38s, the call is transferred successfully.
Breakdown details in Cloudwatch:
1-19s: “ContactFlowModuleType”: “LoopPrompts”
19s: “ContactFlowModuleType”: “Transfer”
19s: “ContactFlowModuleType”: “Transfer” and “Results”: “Error”
19s: “ContactFlowModuleType”: “Resume”
19-38s: “ContactFlowModuleType”: “LoopPrompts”
38s: “ContactFlowModuleType”: “Transfer”
// Interrupt every 20s: After 40s, the call is transferred successfully.
Breakdown details in Cloudwatch:
1-20s: “ContactFlowModuleType”: “LoopPrompts”
20s: “ContactFlowModuleType”: “Transfer”
20s: “ContactFlowModuleType”: “Transfer” and “Results”: “Error”
20s: “ContactFlowModuleType”: “Resume”
21-40s: “ContactFlowModuleType”: “LoopPrompts”
40s: “ContactFlowModuleType”: “Transfer”
// Interrupt every 21s: After 21s, the call is transferred successfully.
Breakdown details in Cloudwatch:
1-21s: “ContactFlowModuleType”: “LoopPrompts”
21s: “ContactFlowModuleType”: “Transfer”
// Interrupt every 25s: After 25s, the call is transferred successfully.
Breakdown details in Cloudwatch:
1-25s: “ContactFlowModuleType”: “LoopPrompts”
25s: “ContactFlowModuleType”: “Transfer”
// Interrupt every 30s: After 30s, the call is transferred successfully.
Breakdown details in Cloudwatch:
1-30s: “ContactFlowModuleType”: “LoopPrompts”
30s: “ContactFlowModuleType”: “Transfer”
As you can see from above result, 20 seconds is the amount of time an available agent has to accept the contact.
Sometimes the value of the interrupt time in loop prompts block depends on the use case as well. You may need to increase it. Also to set the end flow/resume as the final block in the customer queue flow rather than a disconnect block, essentially extends the timeframe in which the call will be in queue before being transferred by an unknown y interrupt time * x failed transfers due to agent offers during the transfer.
Once no agents are in the process of being connected, then the external transfer will succeed. Please note that if the agent clear the missed call status, then the call will be routed to this agent again. With this case the transfer will fail too.
No Comments