In this installment, we’ll take a look at Amazon Connect customer queue treatment. Put another way, we’ll look at what we can do for/to the customer when they are first placed into the queue, and while they’re waiting in queue.
While in queue, the customer experience is governed by the Customer Queue Flow you chose prior to transferring the call to the queue.
Audio While In Queue
While they’re in the Customer Queue Flow, they will be listening to the audio you’ve hopefully defined in a “Loop Prompt” block. Note that you don’t have to include a Loop Prompt block in the flow. If you don’t, the customer will hear dead air (I checked…).
In a Loop Prompt block, you can string together multiple prompts. Each prompt can be defined by text to speech, or by including an audio file from your prompt library. All configured prompts are played in sequence, then repeated until the call is assigned to an agent. You can define a timeout value in the block, in which case, you exit the block when the timeout occurs.
In a typical treatment, you would play music for, oh, say, two minutes, then play a message such as “Your call is important. Please wait”. The customer queue flow would look like this:
What’s going on here is:
- The Loop prompt block loops your music clip
- A timeout set in the Loop prompt block sends the flow to the next Play prompt block (“Your call is important”). Typically, that timeout would be in the 1-2 minute range
- Repeat. The End Flow/Resume block restarts the flow at the entry point.
This will go on until the call is sent to an agent, or the customer bails.
Estimated Wait Time Messages
Are not available. Nor are there messages that will tell the caller how many customers are ahead of them.1
But, it’s really important that the customer knows that their wait time will be long. Some customers, faced with a long wait, will hang up and try again later. Unless this is a sales queue, YOU WANT THIS TO HAPPEN. This is one of your few strategies that you have to control call floods.
Normally, I would check the estimated wait time when the call enters the queue2, and if the wait time is longer that what we define as acceptable, play a message such as “We are experiencing excessive wait times. Your call will be answered in the order which it is received”.
Unfortunately, Amazon Connect doesn’t provide estimated wait time yet . And there’s no API (yet) that would let me get what I need to do this myself.
I CAN check the time the oldest call has been in queue3, or I can check if the number of calls waiting is greater than a threshold I define. The time of the oldest call is a better choice, since it does have at least some correlation to our current ability to service the queue.
Not ideal, but it will have to do for now.
Customer Queue Treatment Options for Long Wait Times
Other standard customer queue treatments when wait times are long include sending them to voicemail, or offering a callback.
Voicemail isn’t currently an option with Amazon Connect, though it wouldn’t be too hard to build using Twillio or a similar service. I’m not a fan of using voicemail for dealing with long wait times, but it’s not uncommon in smaller centers.
You can offer a callback to a customer in queue. To clarify, a customer is asked to provide a number that they can be reached at. Their request is placed into a queue as a “callback”. When there’s an agent available, an attempt is made to connect the caller, and if successful, the agent is connected to the caller. The queue flow segment looks like this:
In theory, you could use the Caller ID as the callback number, but I don’t recommend it. If the Caller ID is from their company desk phone, let’s just say “your mileage may vary”. It’s best to ask them for a number that they can be directly reached at.
Now, the callback feature is limited. The customer has no idea when the callback will happen (depends on how backed up the queue is), and there is no way for the customer to specify a preferred callback time. If the call back could be delayed, oh, say, longer than 15 minutes, I would think carefully before I would offer a callback.
Serving More Customers Faster
The options we’ve discussed for long wait times will result in some callers willingly leaving the queue . Ideally, we’d like to be able to serve the waiting customers quicker. That will be covered in a future post. Until then, take a look at my series on queue best practices to see what I’ll be trying to implement.
1Telling the customers how many are ahead of them is a bad idea anyways. The customer cannot translate that number to a wait time. 20 people ahead of them isn’t a problem if there’s 120 agents on the queue.
2The industry standard method of calculating estimated wait time is (Average Talk Time * Position in Queue/Number of Agents Available). This is reasonably accurate when the number of agents is reasonably large. Not so good with a small number of agents.
3The “Sample Queued Callback” flow Amazon provides as an example checks the oldest call in the queue, and if it exceeds the threshold, tells the customer that their call will take longer than the threshold time. This isn’t true. The time the person just entering the queue will wait is not going to be the same the next person being served had to wait. In practice, it won’t make much of a difference to overall customer care, but my engineering sense of accuracy was twitching.