The queue and manual and automatic request dispatching
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. Both of them use the queue to accomplish their task.
Regardless of whether your organization opts for manual or automatic request dispatching, the queue almost certainly plays 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 assigned agent.
By default, the queue treats all conversations with the same priority. It lists conversation requests in chronological order, with the oldest request appearing at the top of the list.
You can affect the sort order of the queue by assigning different types of conversation different priorities. This also affects the order in which conversation requests are dispatched by the automatic request dispatching mechanism.
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, or the named area or language of the conversation request. The queue of an agent who only provides technical support in Norwegian and Swedish, for example, won’t contain any items for conversations requesting sales advice or technical support in French.
Agents can filter their queue by language and named area. The filters that 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 their 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 for technical support.
You can disable the option for agents to filter their queue.
Conversation forwarding lets agents forward conversations 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. You can change the configuration to prevent this.
If your agents only ever establish conversations by sending visitors a PIN, displaying the queue in the Agent Desk serves no purpose, so you can hide it completely.
Another possible scenario is related 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 inbound conversation requests.
In this case, you can configure Unblu to 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 an agent answers 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. 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 number of concurrent active sessions agents may have can be limited. 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 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 (as determined by the addressee of the conversation request) that the dispatch mechanism should reserve automatically.
|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.|
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.
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:
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’re not available for new inbound conversations. The dispatch mechanism won’t take the agent into consideration when reserving queue items.
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.
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 is defined in the conversation template it’s based on.
You can define up to four priority bands. Each priority band has its own threshold for changing an agent’s availability status to Busy.
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.
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 before onboarding.
To work around this, you can specify manually when your queues are available.
When all your agents are busy, visitors can normally still send new conversation requests. This can lead to a growing backlog of unanswered conversation requests in the queue.
You can configure Unblu to inform visitors that your agents are currently offline and prevent new conversation requests.
For information on configuring the queue and request dispatching, refer to Queue and request dispatching configuration
If you’re interested in integrating Unblu into your existing automatic call distribution (ACD) system, read Delegating the queue to a third-party system.
If you use automatic request dispatching, review the article on web notification permissions before you configure notifications.