When calling a hotline, many customers are used to being told the position in line. But with new dynamic queuing systems, this is often not the best approach. Reading out the position in queue has its place and some of our customers use it, but it means that you can lose the ability to make things better for you and for the caller. Why?

Back in the day, phone lines were linear. Imagine an assembly line. You put one piece of a car on the conveyor belt and it will always keep its position. It cannot go back or forth, it always remains there until it reaches the end of the processes it is going through. 

That's how old phone systems worked:

You had a static line of calls. No call could ever take over a call that was in front of it. It had its fixed position until being connected to an agent.

This means the call in position 1 had to be taken by any agent before the call in position 2 was even available for distribution. Therefore, only one agent could be called at the same time. The second available agent had to wait before receiving the next call.

Nowadays things look very different.

Systems like babelforce will always try to connect the longest waiting call first, however, they are much more flexible. 

If there are three agents available to take a call and three calls waiting, babelforce will of course try to connect all three agents with a call.

But what's the problem with the queue position? I could still tell the longest waiting caller that she is in position 1, right?

Well, imagine the following scenario: 

• A caller just receives the information that they are in position 1. 
• However, at the same time, the call that was previously in position 1 isn't taken by the agent and takes back the first position in the queue (because it's still the oldest call). 
• Now, the first caller suddenly goes back one position and will now hear that she is in position 2.

Not a great user experience, right? And this happens a lot if there are many calls and many agents.

But let's say you are just not reading out the position to the customer too often. So maybe it is less likely that they are "jumping up" with their queue position. However, there is another layer we need to talk about.

In babelforce, you can add many selection rules to a queue. For instance, you can say that callers reaching you at a specific line are preferred over other callers. What would that mean?

• You have a caller just getting the information that he is on position 1. He called the standard hotline.
• Now another caller reaches your hotline via the VIP line. This caller is preferred over the standard support calls. This means the caller will now take away the customer's position.

These setups will mess with any order in your queue as you are no longer going for "first in first out" but you have certain customers that you would like to be connected quicker. And since they share the same queue there is no way that any announced queue position would ever be true.

But what can I do instead?

babelforce offers a great option for announcing expected queue wait time which is very reliable. How do we do that? We have a metric that takes the average expected queue wait time (combined with all calls taken or hung up within the last 30 minutes) and subtracts the time the call actually waited in the respective queue. It works like this:

1. A call comes into a queue
2. The average queue wait time is 5 minutes
3. After 1 minute you have the first point to announce the expected wait time
4. This specific call will now have an expected wait time of 4 minutes

We also suggest to never read out the exact time this expression returns. After all, it's just an estimate. Our best practice is to have expected wait time ranges, e.g.

⇒ The expected wait time is below 1 minute

⇒ The expected wait time is less than 5 minutes

⇒ The expected wait time is more than 10 minutes

This way you can offer the customer the best possible service and provide a very accurate estimate.

And let's be honest: just because customers are used to a queue position announcement it doesn't mean that we should present them with something that is not always reliable. It often makes little sense since a queue position never tells me how many agents are actually there to answer my call.

Finally, by opting for reading out expected wait time to your callers, you open up a world of further optimizations that you can do: prioritize callers based on any data (e.g. that they are VIP customers by doing a lookup in your CRM), prioritize based on information received from the caller in the IVR and offering call-backs and switches to other automation dynamically.