Contact usRequest a demo

Queue and request dispatching configuration

The queue is Unblu’s principle mechanism for assigning incoming conversation requests to the right part of your organization. Automatic request dispatching can improve the handling of conversation requests.

This article describes how to configure the queue and request dispatching. It assumes you’ve read the guide to The queue and manual and automatic request dispatching.

Queue configuration

There are a number of ways to affect the queue independently of the dispatching mechanism your organization opts for.

Changing queue visibility

If your use case doesn’t require a queue, you may want to change the visibility of the queue.

If your agents don’t have any inbound conversation requests, you can hide the queue by setting the configuration property com.unblu.desk.ui.showQueue to false. Agents then no longer see the queue in the Agent Desk sidebar.

If you want some agents only to see invitations and forwardings in their queue, set the configuration property com.unblu.desk.ui.showVisitorRequestQueue to false. This hides chat queue items but still shows forwarded conversations and invitations.

Disabling the queue filter

Agents can filter the queue by language and named area. The filters agents apply to their queue affect the items displayed in their queue and hence the conversation requests they can accept. It also affects the agents' availability shown to visitors.

You can disable the option for agents to filter their queue with the configuration property com.unblu.queue.ui.enableFilterChanges. The configuration property may be set globally, for an account, a team, or an individual user.

The queue filter works the same for both manual and automatic request dispatching.

Disabling the conversation preview function

Conversation forwarding allows agents to forward a conversation to another agent, team or named area. If the queue is configured in such a way that agents can preview conversations before answering a request, agents can also forward conversations without interacting with the visitor.

The preview function can be disabled with the configuration property com.unblu.queue.ui.chatQueuePreviewEnabled. This prevents agents from forwarding conversation requests without answering them first.

Changing queue sort order and conversation priority

By default, the queue lists conversation requests in chronological order, with the oldest request appearing at the top of the list. Furthermore, all conversations have the same priority. You can, however, assign different types of conversation different priorities with the configuration property com.unblu.conversation.invitation.conversationRequestQueueSortingOrder. This affects the sort order of the queue and the order in which conversation requests are dispatched by the automatic request dispatching mechanism.

If you assign different types of conversation different priorities, the following rules apply:

  • Conversations with a higher priority appear in the queue before conversations with a lower priority.

  • Conversations with the same priority are listed chronologically.

For more information, refer to the description of the configuration property.

Manual request dispatching

Manual request dispatching refers to agents selecting items manually from their queue. Conversation requests remain unassigned until agents answer them.

The configuration property com.unblu.agentavailability.maxActiveSessionLimit specifies the number of concurrent active sessions agents may have. Once an agent reaches this limit, they can no longer accept requests from the queue.

Since agents can preview conversations in their queue, they may be tempted to cherry-pick requests rather than answer the most urgent ones. This can be mitigated by disabling the preview function.

Queue configuration properties whose effects aren’t limited to automatic request dispatching affect manual request dispatching.

Configuring automatic request dispatching

To activate automatic request dispatching, set com.unblu.queue.ui.autodispatching.autoRequestDispatchingEnabled to true.

The following configuration properties must also be true:

Make sure that the Agent Desk displays toast notifications, or agents have no way of accepting conversations reserved for them. For this, com.unblu.core.client.ui.notification.NotificationService.notificationDestination must be set to BOTH or TOAST. The Desktop notification provides no means to accept a reservation.

You can customize how the automatic dispatch mechanism works with the following configuration properties:

  • com.unblu.queue.ui.autodispatching.autoDispatchedQueueCategories contains a list of the queue categories that automatic dispatching is enabled for. If more than one category has pending queue items, the dispatch order is determined by this configuration property.

    Unblu evaluates the list of queue categories before it determines the queue sort order. This allows you to give higher priority to, say, requests addressed directly to an agent rather than their team or the named area in general when reserving a request for the agent.

  • com.unblu.session.inboundConversationReservationTimeout specifies in milliseconds how much time agents have to accept a request. This setting is only available in the ACCOUNT scope.

  • com.unblu.queue.ui.autodispatching.reservationDelay specifies the delay before Unblu reserves a conversation for an agent. If agents have a high latency connecting to Unblu, increasing the delay can improve the fairness of how conversations are distributed amongst agents. On the other hand, increasing the delay also increases the time visitors must wait for an agent to accept their conversation request.

    If latency is greater than 500ms, Unblu features such as co-browsing become so slow that the user experience suffers significantly. With latency greater than 2000ms, the features are all but unusable. You should take measures to keep network latency as low as possible.

  • com.unblu.agentavailability.maxActiveSessionLimit specifies the number of concurrent active sessions agents may have. Active sessions are ones the agent has open in an Agent Desk tab. Once an agent reaches this limit, the dispatch mechanism stops reserving new requests for them.

  • As mentioned above, an agent’s online status and their readiness to accept new reservations are independent of one another. While this may be helpful in some circumstances, it can also be confusing. You should therefore consider disabling the ability for agents to set their online status when automatic request dispatching is in use. To do so, set com.unblu.ui.usermenu.showStatusEditor to false.

  • com.unblu.queue.ui.autodispatching.nextConversationPushTimeoutAfterAccepting specifies in seconds how long the dispatch mechanism waits before reserving an additional request for an agent when they have accepted a request.

  • Setting com.unblu.queue.ui.autodispatching.allowAcceptFromQueueForAutoDispatchedQueueCategories to true allows agents to answer requests from the queue manually despite automatic request dispatching being active.

Review the individual configuration properties to learn more about their possible values and their scope.

Busy limits

Busy limits let you set agents' Busy status for conversations with different priorities. A conversation’s priority in the queue is based on the value of the configuration property com.unblu.conversation.invitation.conversationRequestQueueSortingOrder in the conversation template.

You can define up to four priority bands. Each priority band has its own threshold for changing an agent’s availability status to Busy. You create the priority bands with the configuration property com.unblu.agentavailability.queueSortingOrderToPriorityMapping. The configuration property’s value consists of a list of queue sort order values. Each element in the list corresponds to the minimum queue sort order value that maps to a priority band: the first element specifies the minimum queue sorting order for counting a conversation towards priority band 1, the second element does the same for priority band 2, and so on.

Note how Unblu interprets the value of the configuration property:

  • The entries must be in ascending order, from the smallest to the largest value.

  • If the list is empty, all conversations are treated as if they’re in priority band 1.

  • If the list contains fewer than four entries, the lower priority bands aren’t used.

  • If the list contains more than four entries, Unblu only takes the first four entries into account.

Once you’ve defined your priority bands, you can assign each of them an individual busy limit with the following configuration properties:

When an agent reaches the busy limit for a particular priority band, their availability status switches to Busy for that priority band and all lower priority bands. They remain available for conversation requests in higher priority bands.

Busy limit configuration example

To illustrate how priority bands with different busy limits work, consider the following configuration:

Listing 1. Example for priority-based busy limit configuration 
com.unblu.agentavailability.queueSortingOrderToPriorityMapping=1,11,21,31
com.unblu.agentavailability.busyStateSessionLimitPriority1=1
com.unblu.agentavailability.busyStateSessionLimitPriority2=3
com.unblu.agentavailability.busyStateSessionLimitPriority3=2
com.unblu.agentavailability.busyStateSessionLimitPriority4=5

Suppose there’s currently only one agent responsible for the queue in question, and they’re already participating in several conversations:

Table 1. Effect of busy limit example configuration on a single agent
Priority band Busy limit Number of ongoing conversations Available?

1

1

0

Yes

2

3

1

Yes

3

2

2

No

4

5

2

No

As you can see, the agent is busy for requests in priority band 4, even though they’re currently only participating in two conversations and the busy limit for that priority band is 5 conversations. This is because they have reached the busy limit of priority band 3. The dispatch mechanism therefore considers them busy for priority band 3 and all lower priority bands, that is, priority band 4.

The following list shows how different incoming requests would affect availability status of the agent in the example:

  • Incoming request with queue sort order 7

    • The request is in priority band 1.

    • The agent is available for priority 1 requests, so the dispatch mechanism assigns them the conversation.

      Once that happens, the agent is unavailable for priority 1 requests because they’ve reached the busy limit for that priority band. As a result, the agent is also unavailable for all other priority bands.

  • Incoming request with queue order 55

    • The request is in priority band 4.

    • The agent is unavailable for priority 4 requests, so the dispatch mechanism can’t assign them the conversation.

    • The agent’s availability status is unchanged.

  • Incoming request with queue sort order 19

    • The request is in priority band 2.

    • The agent is available for priority 2 requests, so the dispatch mechanism assigns them the conversation.

      Even after that happens, the agent is still available for priority 2 requests because they haven’t reached the busy limit for that priority band or any higher priority bands.

    • The agent’s availability status is unchanged.

  • Two incoming requests, one with queue sort order 7, one with queue sort order 19

    • The request with the lower queue sort order is in priority band 1, the other request is in priority band 2. The dispatch mechanism will therefore try to assign the request with the higher priority first.

    • The agent is available for priority 1 requests, so the dispatch mechanism assigns them the conversation.

      Once that happens, their availability status for priority 2 requests switches to Busy, so the dispatch mechanism can’t assign them the priority 2 request.

    • The agent’s availability status is now Busy for all priority bands.

The possibility to set an agent’s availability based on conversation priority was introduced in Unblu 7.9.1.

Setting queue availability manually

The Unblu Collaboration Server can only determine the availability of agents to respond to a conversation request once it has enough information to determine which queue to assign the request to. In part, this depends on the named area that the visitor’s request relates to.

If you use the concierge, the named area may not be known until the visitor selects it during the onboarding process. This means that the Collaboration Server can’t determine whether there are agents available to respond to their request.

To work around this, you can specify manually when your queues are available. To do so, set com.unblu.agentavailability.availabilityOverride to ALWAYS_AVAILABLE or ALWAYS_UNAVAILABLE This adds a toggle to the account overview page of the Account Configuration interface which allows you to turn the queue on or off. You can also use the Unblu web API to change the configuration property.

For more information, refer to the Unblu web API documentation on account updates.

Defining Unblu’s behavior when all agents are busy

To prevent visitors from sending normal conversation requests when all your agents are busy, set com.unblu.agentavailability.treatBusyAsAvailable to false. That way, Unblu tells visitors that your agents are currently offline and they can only create offline chat requests. If you disable offline chat requests too, visitors ẃon’t be able to send conversation requests until your agents are available again.

See also