Last week Amazon announced the release of a new node for Amazon Connect: Get Metrics. It is available from the Set menu in regular contact flows, customer queue, hold and even whisper flows and allows us to dynamically query queue data.
While the Check Queue Status node (available under the Branch menu in some contact flows) already gave us some capabilities to check on a queue, this new node adds more variables and opens up a lot more options. The official announcement points out a few ways we can now improve routing, however, thanks to two new metrics, “Metrics.Queue.OldestContactAge” and “Metrics.Queue.Size,” we can now also offer a much more robust queue hold experience.
Before using the Get Metrics node, a typical queue hold flow could look similar to the screenshot below. We would loop an audio clip and interrupt it every minute or so to check the queue status and, based on the longest time in queue, play back a hard-coded message. Each one of the prompts in the image below would have a text like, “The longest time in queue right now is approximately 2(or 4 or 6 or 8) minutes,” then we would maybe offer a callback option for times over 6 minutes.
The disadvantage of this option is obvious. Not only are the messages very rough approximations but we need to build several branching paths to make sure we capture all possible combinations. This is where the Get Metrics node comes in. We can reference its results using the $.Metrics.Queue.OldestContactAge notation and, instead of several branches, we can build something like this.
In the screenshot above, the prompt has the following text, “The longest time in queue is approximately $.Metrics.Queue.OldestContactAge”. Instead of 4 branches with hard-coded messages, we have one dynamic prompt.
However, before calling it a day, we need to listen to what the OldestContactAge format is. This metric is returned as seconds and your callers will hear, “The queue time is approximately 480” when the longest wait time is 8 minutes. This is not ideal, but it can easily be fixed with a Lambda function.
Add an invoke Lambda function node and pass in the metric as a parameter.
Keep in mind attributes passed in this way will appear as parameters in the Connect JSON payload. If you instead save the metric as a contact attribute using the Set Contact Attributes node, the metric will be accessible under ContactData.Attributes in the JSON payload.
Once passed into Lambda, you can simply divide by 60 to get the minutes or use the modulus operator (%) to get the seconds. That being said, seconds might be too detailed for most call centers, so we will just find the minute wait time and, if it’s less than 1, let the caller know they have less than 1 minute to wait.
Here is the code I used:
exports.handler = (event, context, callback) => {
let input = event.Details.Parameters.timeInQueue.substr(1);
(input > 60) ? callback(null, { "time":Math.floor(parseInt(input) / 60)}) : callback(null, { "time": 0 });
};
Something to note is that the variable provided by Get Metrics and passed into Lambda (timeInQueue) had a . before the seconds, which I remove before converting to integer. Also, I am returning an external attribute called “time” which will be 0 if the input was less than 1 minute; you can of course choose to return the seconds or a rounded up result.
With the Lambda result back in Amazon Connect, you can check the external attribute “time” using a Check Contact Attributes node and, if it’s equal to 0, play a prompt letting the caller know they have to wait less than 1 minute; otherwise simply play back the Lambda results using the following text, “The wait time in queue is approximately $.External.time minutes. Please continue to hold.”
Our queue hold flow already sounds much better; however, keep in mind the Metrics.Queue.OldestContactAge variable will contain (hopefully not surprisingly so) the wait time of oldest contact in queue. This means your oldest caller in queue will hear the time increasing if they hit this node repeatedly. We always recommend having a max wait time with a custom message and maybe even forcing the caller to a callback if the wait times goes beyond a few minutes. You can also check if any agents are online and play a special message if it looks like everyone left for the day or maybe trigger a Lambda function that will alert a supervisor.
Also keep in mind that if you don’t have callbacks set to use their own queue and a callback was left waiting overnight, it could potentially skew the numbers for the first callers of the day.
An alternative which can avoid a lot of these issue is instead checking the queue size by using $.Metrics.Queue.Size. If there is one call in queue, you can let the caller know they are next in line (queue size will include the current call in its count), and if the queue size is larger than one, you can let the caller know there are approximately X calls waiting for an agent.
Hopefully this gave you some ideas on what is possible using the new node for Amazon Connect. For a full list of all metrics available check out the official documentation and for more ideas on how to improve your contact flows please email Craig Reishus.
