Contact usRequest a demo

When a visitor to your organization’s website wants to start a conversation, you need to ensure that they’re put in touch with the right part of your organization quickly. Unblu offers two mechanisms for achieving this: manual and automatic request dispatching.

The queue

Regardless of whether your organization opts for manual or automatic request dispatching, the queue will almost certainly play a central role in dealing with visitor inquiries efficiently.

The queue is an agent’s view of all conversations without an assigned agent. It only contains items that they themselves can join as the assignee.

Each agent’s queue depends on the filters applied to it. Some filters may be applied automatically as a result of the agent’s team. Other aspects of the conversation that may affect the filters include the named area and the language of the conversation request.

The queue of an agent who only provides technical support, for example, won’t contain any items for conversations requesting sales advice.

Filtering the queue

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. This in turn has an impact on agents' availability, which is reflected in the availability shown to visitors to your website.

For example, suppose the only available agent providing technical support is filtering their queue to look for an item in Swedish. In this case, visitors whose language isn’t Swedish will have no available agents to respond to their request.

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.

Queue sort order

As a rule, the queue lists conversation requests in chronological order, with the oldest request appearing at the top of the list. 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.

By default, all conversations have the same priority.

For more information, see the description of the configuration property.

Forwarding conversations from the queue

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 visibility

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

Suppose your agents only ever establish conversations by sending visitors a PIN, In that case, there won’t be any inbound conversation requests, and you can safely hide the queue by setting the configuration property com.unblu.desk.ui.showQueue to false. Agents will then no longer see the queue in the Agent Desk navigation menu.

Another possible scenario applies to specialists such as 2nd level support agents. You may want your 1st level agents to be able to forward conversations to them, or to invite the specialist team to join a conversation. On the other hand, you don’t want the 2nd level agents to see all the inbound conversation requests.

In this case, set the configuration property com.unblu.desk.ui.showVisitorRequestQueue to false. This will hide chat queue items but show forwarded conversations and invitations

Manual request dispatching

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

This dispatch mechanism has a number of drawbacks:

  • When two agents try to take the same queue item simultaneously, one of them will get an error message that the conversation is already assigned to another agent. This reduces user confidence in the system and may create a false sense of competition for conversations.

  • 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 previews with the configuration property com.unblu.queue.ui.chatQueuePreviewEnabled. However, agents may still select queue items based on the information displayed in the queue overview, such as the last message, or the visitor’s language or location.

  • Agents may prefer to accept a single conversation request at a time, rather than work on two or three conversations in parallel, despite having the capacity to do so. This increases the time visitors must wait for an agent to deal with their query.

  • The configuration property 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.

    When an agent reaches this limit, they can no longer accept incoming requests—​but they’re still shown a toast notifying them of the new request.

Automatic request dispatching

Automatic request dispatching offers an alternative approach to handling conversation requests. Instead of agents manually answering conversations, they simply signal that they’re available for conversation requests. Unblu reserves conversations for the agents automatically, and the agents can choose to accept or decline a reservation. If they decline a reservation, the dispatch mechanism assumes they’re unavailable for conversation requests and reserves the request for another agent. The dispatch mechanism also changes their availability status.

You can activate automatic request dispatching for individual agents, teams, entire accounts, or globally. Automatic request dispatching could thus be used for agents in a contact center, for example, while allowing relationship managers to answer conversation requests manually. Additionally, you can specify which categories of conversation that the dispatch mechanism should reserve automatically.

How automatic request dispatching works for agents is outlined in the relevant section of the Agent Desk guide.

It isn’t possible to limit automatic request dispatching to certain types of conversation. You can’t specify that an agent should, say, be assigned chat requests automatically but should answer audio calls manually.

Prerequisites for reserving queue items

For the dispatch mechanism to reserve queue items for an agent, the following conditions must be met:

  • Automatic request dispatching must be enabled for the agent.

  • The agent must have the queue availability status Available.

  • The agent must not already be participating in the maximum number of active conversations.

  • There may be no pending reservation for the agent.

  • There must be an unreserved queue item that meets the agent’s queue filter criteria.

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 will have no way of accepting reservations. 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:

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

Queue availability

Agents use a toggle next to their avatar to signal to the dispatch mechanism that they’re ready for new conversation requests. This status is independent of their online status, which is indicated as a badge on their avatar. This means it’s possible for agents to signal to the dispatch mechanism that they’re unavailable while at the same time indicating to their coworkers or visitors that they’re online.

An agent’s queue availability status is displayed in the agent monitor along with their online status. The various queue availability statuses are:

Available

The agent is subscribed to the queue and available for new inbound conversations. The dispatch mechanism will take the agent into consideration when reserving queue items.

Unavailable

The agent is subscribed to the queue but they’re not available for new inbound conversations. The dispatch mechanism won’t take the agent into consideration when reserving queue items.

Busy

The agent is subscribed to the queue and available for new inbound conversations in principle. However, they’re already participating in the maximum number of active conversations. The dispatch mechanism won’t reserve any further queue items for them.

Not subscribed

The agent isn’t subscribed to the queue.

Busy limits

Once an agent’s availability status switches to Busy, the dispatch mechanism can no longer assign them conversation requests. To avoid leaving important requests unanswered while all agents are engaged in less important conversations, Unblu offers a way to set an agent’s busy status separately for different conversation priorities.

As mentioned in the section on the queue sort order, different types of conversation can be assigned different priorities in the queue. 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.

Unblu allows you to 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.

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.busyStateSessionLimit=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 account-wide

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.

How Unblu behaves when all agents are busy

When all your agents are busy, Unblu still lets visitors send new conversation requests. This can lead to a growing backlog of unanswered conversation requests in the queue.

To change this behavior, set com.unblu.agentavailability.treatBusyAsAvailable to false. That way, Unblu will show visitors that your agents are currently offline. They’ll only be able to create offline chat requests.

See also