Contact usRequest a demo

Queue status for visitors

This is a preview feature. It may be subject to change or removal with no further notice.

To enable preview features, set com.unblu.platform.enablePreview to true.

For more information on preview features, refer to the Unblu release policy.

If you’re using Unblu Spark’s chat feature in a call center environment, your customers may start conversations when no one’s available to reply to them immediately. In that case, their conversation almost certainly lands in a queue once they’ve completed the onboarding process.

The queue status feature can give your customers an idea of how long they’re going to be waiting for an agent to join their conversation. It’s displayed immediately above the text input field in the Visitor UIs and can include the following information:

  • The visitor’s position in the queue

  • The time visitors should expect to wait until an agent joins their conversation

Note that forwarded and delegated conversations don’t have a queue status.

Calculating the queue status

The Unblu queue depends on a number of factors besides the number of conversation requests and agents. The invitation target—​for example, the named area or domain a conversation is intended for--, the conversation language, and the agents' individual queue filters all contribute to increasingly fine-grained queues.

As a result, determining a visitor’s position in the queue and their waiting time is not as straightforward as you might think. No single calculation method can take into account all the factors that influence how long a visitor has to wait. Conversely, which factors should be taken into account, and how Unblu should take them into account, also depends on the circumstances you use Unblu in.

Calculating the queue position

A visitor’s queue position is calculated based on the number of conversations with one of the following initial engagement types:

By default, the conversation language isn’t taken into consideration. To do so, set com.unblu.conversation.queuestatus.useLanguageForQueuePosition to true.

How often Unblu checks for updates to the visitor’s position is specified in the configuration property com.unblu.conversation.queuestatus.queuePositionPollingInterval. By default, it checks every 30 seconds.

Calculating the expected wait time

The visitor’s expected wait time doesn’t count down to show how much longer they have to wait. Rather it’s how long earlier visitors had to wait for their conversation request to be answered. Specifically, the expected wait time is calculated as the average wait time of the assignment requests that were accepted within a given time frame. The default time frame is one hour, but you can change it with the configuration property com.unblu.conversation.queuestatus.invitationResolutionTimestampWindow. Assignment requests are conversations that require an assigned agent but don’t have one.

By default, the conversation language is taken into consideration. If you don’t want to, set com.unblu.conversation.queuestatus.useLanguageForQueueAverageWaitingTime to false.

How often Unblu polls the database to retrieve the wait times in the timestamp window depends on the configuration property com.unblu.conversation.queuestatus.queueAverageWaitingTimePollingInterval. By default it does so every 5 minutes.

Configuring the queue position and estimated wait time

The default configuration for calculating the queue position and estimated waiting time may not be suited to your use case. For example, if your call center doesn’t get many incoming conversations, there’s little point in polling for the wait times every 5 minutes, and the one hour polling window may be too short. Conversely, if you have a call center with a high volume of incoming requests, a smaller polling window—​15 minutes, say, or even less—​is probably more useful to your visitors.

Finding the best polling intervals and window is more art than science. There are, however, some rules of thumb:

  • The higher the volume of conversation requests, the shorter the polling interval and polling window should be for the estimated wait time.

  • If the number of conversation requests can vary greatly—​because your clients tend to contact you before or after work, for example—​a short polling interval and polling window provide visitors with a more accurate estimate of their wait time.

  • If your conversations tend to be long, you can use a longer polling interval for the queue position. Conversely, short conversations mean a visitor’s queue position can change more frequently, so you should keep the polling interval short.

  • If the number of customers you deal with in different languages differs greatly, you should probably use the language to calculate the queue position.

Other configuration possibilities

There two groups of properties to configure the queue status for visitors:

See also