When a visitor to your organization’s website wants to start a conversation, you need to ensure that they are put in touch with the right part of your organization quickly. Unblu offers two mechanisms for achieving this: manual and automatic request dispatching.
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 of the conversations without an assignee. 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, will not contain any items for conversations requesting sales advice.
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 is not 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.|
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.cobrowsing.chatQueuePreviewEnabled. This prevents agents from forwarding conversation requests without answering them first.
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.core.client.desk.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 of the inbound conversation requests.
In this case, set the configuration property com.unblu.core.client.desk.showChatQueue to
false. This will hide chat queue items but show forwarded conversations and invitations
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 answering the most urgent ones. This can be mitigated by disabling previews with the configuration property com.unblu.cobrowsing.chatQueuePreviewEnabled. However, agents may still select queue items based on the information displayed in the queue overview, e.g. 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.
Automatic request dispatching offers an alternative approach to handling conversation requests. Instead of agents manually answering conversations, they simply signal that they are 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 are 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 is not possible to limit automatic request dispatching to certain types of conversation. You cannot specify that an agent should, say, be assigned chat requests automatically but should answer voice calls manually.|
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.
To activate automatic request dispatching, set com.unblu.queue.ui.autodispatching.autoRequestDispatchingEnabled to
The following configuration properties must also be
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
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. 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.
Configuring the number of concurrent conversations agents may have open involves three configuration properties:
The number of concurrent active sessions an agent may have before their status changes to busy is specified in config:Key: com.unblu.core.server.livetracking.agent.unavailableSessionLimit.
The number of concurrent active sessions an agent may have is specified in com.unblu.session.agentBusyLimit. Reaching this value does not affect an agent’s queue availability status.
You can specify which of these two properties should determine the maximum number of concurrent sessions with com.unblu.session.agentBusyLimitType.
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. We therefore recommend that you disable 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
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
trueallows agents to answer requests from the queue manually despite automatic request dispatching being active.
Please review the individual configuration properties to find out more about their possible values and their scope.
Agents use a toggle next to their avatar to signal to the dispatch mechanism that they are ready for new conversation requests. This status is independent of their online status, which is indicated as a badge on their avatar. It is thus possible for agents to signal to the dispatch mechanism that they are unavailable while at the same time indicating to their coworkers or visitors that they are online.
An agent’s queue availability status is displayed in the agent monitor along with their online status. The various queue availability statuses are:
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.
The agent is subscribed to the queue but they are not available for new inbound conversations. The dispatch mechanism will not take the agent into consideration when reserving queue items.
The agent is subscribed to the queue but and available for new inbound conversations in principle. However, they are already participating in the maximum number of active conversations. The dispatch mechanism will not reserve any further queue items for them.
- Not subscribed
The agent is not subscribed to the queue.
The availability of agents to respond to a conversation request can only be determined once the Collaboration Server 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 cannot determine whether or not 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.core.server.livetracking.agent.availabilityOverride to
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 could also use the Web API to change the configuration property. Refer to the Web API documentation on account updates for further details.