Estimated Wait Time for Chat in Amazon Connect

 Some time ago I presented a method of calculating Estimated Wait Time (EWT) using Lambda function that in turn uses Amazon Connect API to get this info.

The same function can be also used to calculate EWT for chats and then you can display EWT to clients.

Step 1.

Add the same Lambda function getEWT that I mentioned in my previous article.

Step 2.

Now we can add this Lambda function to the contact flow used by chat.

1) Add Set Working Queue block

2) Add Set contact attributes block with UserDefined attribute statInterval that allows you to provide a statistical interval for which we will calculate estimated wait time.

In my case, I use 15 minutes.

3) Now invoke lambda function getEWT

4) After that we need to get the result of it by using Check contact attributes block. It will be in External attribute EWT.

5) Based on the value of EWT you can show different messages using Play prompt blocks.

Here is complete flow:


Troubleshooting flows in Amazon Connect

 I would like to share several methods that I use to troubleshoot contact flows in Amazon Connect.

1) Enable Amazon CloudWatch Logs

Official Amazon Connect documentation explains how to enable CloudWatch logs for Amazon Connect.


IMPORTANT - By default logs will not be collected. You have to manually enable logs for each contact flow or module.

2) Contact search


Contact search is the built-in interface of Amazon Connect that allows searching for contacts.
Contact search only shows contacts that were answered by an agent.
Contacts appear in the contact search several minutes after the call was disconnected.

What could be helpful for troubleshooting - when you use Set contact attributes block in your flow - this information will be also available in the Contact search. 


And in Contact search:

3) Lambda Logger function 

Another method that I use for troubleshooting is a very simple custom made Lambda function - logger (written in Python 3.9)

Source code on my GitHub:

It is very simple:

1) You add Invoke AWS Lambda function block anywhere in your contact flow.  This block will execute logger function.

You can place this block as many times as you need in all the places of your flow that you want to troubleshoot/debug.

2) Optionally you can add any number of input parameters that you would like to be added to the log for debugging.


3) Then you make a test call.

4) Now you can go to CloudWatch  and see logs generated by this function:

5) As you can see in my example in the log you can see all the contact details including the input parameter that you entered previously.

This function can be helpful when you want to see all the contact details at a certain place of your contact flow.


Check Queue is out of service in Amazon Connect

I want to talk about one issue with Amazon Connect. This is something that in my opinion Amazon should be fixing ASAP.

Scenario 1
1. Agent opened Amazon Connect Contact Control Panel (CCP) and changed their status to Available.
2. Agent closed CCP without changing status to Offline
3. Agent is still considered as Available so if you check the number of Staffed or Online agents for the queue this agent is still counted.
4. Agent would stay Available  until 
  • they are logged back in 
  • Supervisor manually changed their status
5. Since they are Available system might send a contact to them and after 20 seconds their status will change to Missed.

Scenario 2
1. Agent logged in to CCP and changed their status to Available
2. Agent fell asleep / went out to buy milk / ... and forgot to close CCP
3. Agent is still considered as Available so they would receive a call and after 20 seconds if it was not answered agent will be marked as Missed.
4. But again agent will be counted in the number of Staffed or Online agents forever.

It is very surprising that Amazon Connect does not have some sort of timeout value like in other contact center solutions. The system should be able to detect that agent left and change their status to logged out automatically after some time. It is not wise to always rely on agents to do the right thing.
What if it is the night shift and you have a very small amount of agents (maybe 1-2 agents) without any supervision?

Another issue that is directly related to the previous one - if in your flow you want to check if Queue is out of service (meaning that you have 0 agents logged in that could answer calls for the specific queue) - you cannot use the number of Staffed or Online agents to make this decision. You also cannot use Available agents, since Available agents show agents that are available right now to take calls, but if an agent is on the call, he is no longer available for the duration of the call but that does not mean that you should be excluding this agent from the total count of agents that are available to take calls during the shift.

Ok. Now what we can do about it?

1. Custom CCP application 
Create a custom CCP application that will automatically change agent status to Offline when they close CCP.
  • It requires custom development
  • Still, not a bulletproof solution as agents might simply close the browser or shut down their PC (or some technical problem)
  • The situation with missed calls is still not resolved
You can find a detailed solution in the official Amazon Connect documentation:

This would bring additional relief but still, you have to rely on agents to do the right thing. 

2. Custom formula to check if Queue is OOS

 Instead of using the number of Staffed agents use the following formula:

Potentially Available agents in Queue = Staffed agents - Agents in Error state
So, if this number is equal to 0  = Queue is Out of service.

An agent is considered to be in an Error state if they missed the call. So as you can see this formula covers both scenarios. 

Now, the question is how to add this formula to contact flows.
In order to do that we need to use Lambda function.

I created a sample Lambda function that is called checkQueue (using Python 3.9)

How it works:
1) In the contact flow you need to use Set working queue block as you would normally do before transferring call to queue.
2) After that you need to call lambda function checkQueue
3) This function would first read all the details about current call (queue id, instance id, channel).
4) Then it will use Amazon Connect API to get realtime metrics data about the queue - Staffed and Error agents.
5) It would calculate the difference and return back Queue Out of service status.
6) If it returned OOS = false - your Queue is in service and you can use transfer block to transfer call to queue 
7) If OOS = true - Queue is out of service and you can offer client some alternative treatment:
      • callback
      • voicemail
      • transfer call to cell phone/external number
      • transfer call to another queue
      • simply play message "Please call us later" and disconnect)

Source code of this function you can find on my GitHub:

How to use it:

1) In your flow first add Set working queue block
2) After that add Invoke AWS Lambda function checkQueue

 3) After that use Check contact attributes to verify the output of lambda function.

If External attribute OOS = true -  Queue is out of service, otherwise, it is in service.

4) If Queue is OOS you can offer an alternative treatment to the client (in my case I just play announcement and disconnect call)
5) If Queue is in service - you can transfer call to Queue.

Some additional ideas:
  • the same checkQueue function can be used while the call is already waiting in the queue. Just add it to your customer queue flow. This would allow you to check if Queue is OOS in a loop, for example, once every 2-3 minutes.  If during the time client is waiting for an agent you can catch the situation when Queue goes to OOS. Again that would allow you to offer the client alternative treatment instead of waiting in the queue forever.
  • you can advise management that Queue is now OOS by sending Email/SMS/Task notifications. You just need to add additional Lambda blocks in your flow. You can read how to send SMS/Email/Task from IVR flows in my blog articles:


Export users and queues to CSV-file in Amazon Connect

I created 2 simple Lambda functions that allow exporting users and queues to CSV files.

1. Export users to CSV

How it works:

  • Uses Amazon Connect API to fetch all available information about users
  • Saves it in CSV format
  • Uploads CSV to S3 bucket

Here is the source code of my Lambda function (using Python 3.9)

Before running this script you need to edit the following values:

#Amazon Connect InstanceID 


 #csv-file name 


 #S3 bucket name 



Here is output format:

  • id  - id of user
  • username - username
  • firstname
  • lastname
  • email
  • phonetype  -  phone type SOFT_PHONE / DESK_PHONE
  • autoaccept - auto answer True/False
  • acw_timeout - after call work timeout
  • desk_number - phone number for Deskphone
  • security_profiles - list of security profiles, example = Agent|QualityAnalyst|CallCenterManager
  • hierarchy_group_name - agent hierarchy
  • routing_profile_name - routing profile
  • routing_profile_concurrency - concurrency configuration for routing profile - using following format CHAT|TASK|VOICE  (example - 4|10|1)
  • routing_profile_outbound_queue_name - default outbound queue for routing profile
  • routing_profile_details_list  - detailed configuration of routing profile in the following format:
    • QueueName1|Priority1|Delay1|Channel_type1,...QueueNameN|PriorityN|DelayN|Channel_typeN
    • Example:Tech_support|1|0|VOICE;BasicQueue|1|0|CHAT;BasicQueue|1|0|TASK;BasicQueue|1|0|VOICE

You can run it from Lambda or from AWS CLI. 

  • aws lambda invoke --function-name exportUsersToCSV --invocation-type Event return.json

2. Export queues to CSV

How it works:

  • Uses Amazon Connect API to fetch all available information about queues
  • Saves it in CSV format
  • Uploads CSV to S3 bucket

Here is the source code of my Lambda function (using Python 3.9)

Before running this script you need to edit the following values:

#Amazon Connect InstanceID 


 #csv-file name 


 #S3 bucket name 



Here is the output format:

  • id  - queue id
  • name - queue name
  • desc - queue description
  • status - queue status ENABLED/DISABLED
  • hours - hours of operation
  • ob_callerid_name - Outbound caller ID name
  • ob_phonenumber - Outbound caller ID number
  • ob_flow - Outbound whisper flow (optional)

You can run it from Lambda or from AWS CLI. 

  • aws lambda invoke --function-name exportQueuesToCSV --invocation-type Event return.json