Queues and Routing
Conversations routing is a process of finding the right queue for new messages from where they can be further processed. The new message is evaluated against each route in routing and when the first route is matched, the message is added to the specified queue. If no route is matched, the message is added to a default queue.
The order of routes inside routing is important because the new message is compared to a rule in a given order in routing to find the first match.
Queues are buckets or folders for conversations. Agents are assigned to pick up work from specific queues.
New conversations are routed based on routing rules called routes. The purpose of queues is to categorize conversations. Supervisors can assign agents to certain queues, so conversations are managed in a timely manner by the most knowledgeable team members.
Routing is a set of rules which determine the assignment of a new conversation to a particular queue executed in a specific order.
Route consists of a set of conditions that determine the destination queue and priority for a new conversation.
Conditions are expressions defined based on the message or customer attributes and conversations tags.
Important
- Both queues and routes can be managed over web interface and API
- Only Supervisors can create and/or change route setup
- Customers can be defined and stored in People.
Managing Queues over Web Interface
Queue management on web interface is located under Apps > Conversations > Queues.
On the Queues page previously created queues are listed. Here Supervisors can:
- Check list of created queues
- Create new queue
- Manage existing queues
When you click a queue name, the Queue detail page will open. Here you can find more information about the selected queue such as:
-
Name of the queue
-
List of agents assigned to the queue
-
List of routes leading to that queue
For easier management, it is recommended to name the queue according to its purpose. For example, if you have frequent inquiries from premium customers you can name the queue Premium customers.
Managing assigned agents and routes setup is available from the same page.
Create a Queue in Web Interface
A Supervisor can create a new queue by clicking CREATE NEW in the top right corner.
Every new queue is by default named ‘Queue #X’ where X is a random number, but the Supervisor can rename the queue at any point. Agents and routes should be assigned to created queues to make them functional.
When you click ADD AGENT, the list of enabled agents appears on the right side panel and any agent can be added to the queue. To add a route, the Supervisor can choose from the list of existing routes or create a new one and assign it to the queue.
Auto assignment on the queue level is mandatory for calls, so you should enable this for the default queue and/or all other queues you expect calls to be routed to.
Delete a Queue in Web Interface
To delete a queue, the user needs to go to the List of all queues, click the three dots, and then Delete. Only queues that don’t have an active conversation associated with it can be deleted.
Automatic Assignment
With the automated assignment, you can distribute conversations between available Agents based on their workload and concurrent chat capacity.
The algorithm used is an even workload distribution among agents. New conversations will be assigned to the Agent with the lowest number of running conversations to keep the same utilization of all available Agents.
The automatic assignment is configured at the queue level. Whenever a conversation is routed to a queue with the automatic assignment, the system searches for available Agents and assigns the Agent to the conversation.
The criteria for agent selection are availability, current workload, and capacity. The Agent with the least number of conversations and biggest idle time will be assigned to the new conversation.
Availability
Agent availability is calculated based on the agent status and heartbeat. Heartbeat represents agent presence in the app (even if the window is collapsed) and is refreshed every minute. If the agent’s heartbeat is higher than 5 minutes, then we consider the agent unavailable and skip as eligible for assignment.
Workload
The current workload is the number of conversations assigned to the agent with the status: open.
Capacity
Capacity is the maximum defined opened conversations for an agent by channel; default capacity for all agents or default system capacity for live messaging is 5 concurrent conversations.
For voice calls capacity is always one since one agent can talk to only one person at any given time. This default value cannot be changed on system or agent level.
Default Capacity
To setup the default capacity for all agents go to Apps > Conversations > Capacity. Capacity represents the maximum number of concurrent conversations that can be assigned to one agent over the automatic assignment.
Instant Messaging stands for a group of channels: SMS, WhatsApp, Viber, or Facebook Messenger channels.
Default capacity is taken into account only when not defined at the agent level.
Agent Capacity
To set up agent capacity go to Apps > Conversations > Agents and then select the agent you want to edit.
Agent capacity is considered first. In case it’s not defined, default capacity is considered for new conversations assignments.
Setup
To enable Automatic assignment, go to Apps > Conversations > Queues, select the queue and switch the Automatic Agent Assignment toggle to ON.
You can select any available agent for the assignment or select to prioritize the assignment to the agent who last interacted with the customer. The system will attempt to find the last agent but in case they are not available it will assign the next available agent at that moment in time.
IMPORTANT
Auto assignment is now available on the Default queue as well. This is the queue where all conversations land in case no match is found in the Routing criteria for specific queues. Read more on routing criteria.
INFO
Default queue is a system defined queue that collects all unmatched conversations during routing. All agents have access to conversations in the default queue and can reply to customers. The default queue can be changed on a conversation but it cannot be deleted
Managing Queues over API
The purpose of queues is to categorize conversations and organize your team. New conversations are routed into queues based on business rules. Queues have agents assigned based on topic, channel or any other business need, so conversations are managed in a timely manner by the most knowledgeable team members.
Queues are buckets or folders for conversations. Agents are assigned to queues in order to pick up work from a specific list of queues.
Conversation distribution to queues is optional, but if you need to manage and organize your communication you can use the following API methods:
Create Queue
Create a new queue. Only the queue name is requested as parameter.
Update Queue
Delete Queue
Same as on the web interface, you can delete queues only if there are no conversations assigned to those queues.
Get Queues
Use this method to retrieve the list of queues for your account.
Add or Remove Agent from Queue
To manage agents within specific queues, use these methods to add or remove Agents from a queue.
Get Agents Assigned to Queue
To retrieve a list of agents assigned to a queue use this method.
Parameters
Property name |
Type |
Description |
---|---|---|
status |
string |
Optional filter. Match any status with the result. Possible values: |
role |
string |
Optional filter. Match any role with result. Possible values: |
displayName |
string |
Optional filter. Agent displayName to match result. This is case insensitive and will search for substring anywhere within string, 255 characters max. |
enabled |
boolean |
Optional filter. Match any enabled with the result. Possible values: |
Response example
{
"agents": [
{
"id": "E83E787CF2613450157ADA3476171E3F",
"displayName": "Bon Scott",
"status": "OFFLINE",
"role": "AGENT",
"enabled": true,
"createdAt": "2019-05-10T07:45:23.777+0000",
"updatedAt": "2019-05-10T09:53:58.463+0000"
},
{
"id": "F66D67327326FCCB027BEAA916B94542",
"displayName": "Phil Rudd",
"status": "AVAILABLE",
"role": "AGENT",
"enabled": true,
"createdAt": "2019-05-10T07:45:23.777+0000",
"updatedAt": "2019-05-10T09:53:58.463+0000"
}
],
"pagination": {
"totalItems": 2,
"page": 0,
"limit": 10,
"orderBy": "id:ASC"
}
}
For more information about Queues, refer to our Infobip API Developer Hub.
Managing Routes on Web Interface
With route management, you can define business rules according to which incoming customer requests will be assigned to queues and agents for the most effective resolution.
The rules are customizable and can refer for example to:
- Message attributes such as channel, sender, receiver, or message content
- Customer attributes that you specified through the Target module (e.g., name, city, purchase power, etc.)
- Conversation tags assigned manually or through the automated flow
- IVR inputs collected to variable through the automated flow
- Custom data from Web and In App Calls and Video
Create a Route over Web Interface
With route management you can define business rules according to which incoming customer requests will be assigned to queues and agents for the most effective resolution.
The rules are customizable and can refer for example to:
- Message attributes such as channel, sender, receiver, or message content
- Customer attributes that you specified through the Target module (e.g., name, city, purchase power, etc.)
- Conversation tags assigned manually or through the automated flow
- IVR inputs collected to variable through the automated flow
- Custom data from Web and In App Calls and Video
Only when all the above-mentioned parameters are defined, you can create a new route. Once the route is created it is shown in the list of all routes.
Any route can be set as Enabled or Disabled (default status is Enabled)
INFO
Only routes set as Enabled will be taken into consideration when a new conversation starts.
Destination Queue over Web Interface
Setting up routes means that when a new message arrives, the system will automatically check if message parameters comply with any of the rules specified within the route and will assign conversation according to the rules that match the defined destination queue.
Priority over Web Interface
If message parameters are matched with certain route rules, conversation will get a priority defined within that route setup. According to assigned priority, conversation will be shown in the list of All Conversations. Priority can be changed manually within the conversation details at any point.
Set Conditions over Web Interface
Conditions are a set of criteria that will be checked when there is an incoming conversation. Based on those, a conversation will be added to a specific queue.
Conditions work as key-value set of parameters where key is either standard attribute or a custom one. All attributes related to a customer profile need to exist in the Target module to be used within conditions.
Set Route Order over Web Interface
Considering that several different routes can be set at the same time, you can set up route ordering.
When there is an incoming message, parameters will be checked, and message will be assigned according to the first route that matches against parameters.
Imagine you need to set two routing rules – one for Spanish speaking customers and the other one for premium customers.
Rule 1:
If the message comes to the destination number 123 and the person sending the message has been marked as Spanish speaking within the Target module, route this message to the Spanish queue.
Rule 2:
If message comes to the destination number 123 and person sending message has been marked as premium customer within the Target module, route this message to the Premium queue.
Now, each queue has team of agents assigned to it:
- Spanish queue – Ten agents that can read and write Spanish but are juniors and don’t know anything about premium customers.
- Premium queue – Three agents who speak Spanish and English and know everything about premium customers.
What you want to make sure is that messages from your premium customers end up in the Premium queue and not in the Spanish queue. That’s why you need to set up the routing priority. The premium route should be priority number 1 and Spanish route priority number 2.
To re-arrange the routes, drag and drop them according to their priority.
Enable or Disable a Route over Web Interface
All created routes can be enabled or disabled based on user needs. In case a route is disabled, incoming messages will not be checked against conditions in disabled routes.
Configure Routing for Live Chat
This section explains what can be configured for Live Chat in Routing to assign specific requests to certain Agents queues.
Navigate to Apps > Conversations > Routs > CREATE NEW.
Available fields:
- To – Destination to which inbound conversation messages are sent to. This field accepts
widgetID
for Live Chat routing. Widget ID can be taken from the widget edit page and is unique for each widget configuration. - Channel – Defines if all inbound conversations from the specific channel shall be sent to a certain queue. For Live Chat applicable value is Live_Chat
- Person attributes – All Person attributes are applicable for Routing, however only if the session is coming from an authenticated (logged in) customer and if we have a Person associated with a key identity (email address, in this case).
- Authenticated customer/ anonymous visitor – can be used to differentiate which customer support queue should take on the on auth. customer or visitors. The parameter
is Visitor
defines if inbound conversation comes from anonymous visitor. If set tofalse
, then it’s treated as inbound conversation from auth. customer.
Manage Routing over API
With Routing you can define business rules according to which incoming customer requests will be assigned to queues and agents for most effective resolution.
The rules are customizable and can refer to:
- message attributes such as channel, sender, receiver or message content
- customer attributes that you specified through the Target module (e.g. – name, city, purchase power…)
- conversation tags assigned manually or through the automated Flow
Routing is the process of finding the right queue for new messages from where they can be processed further.
Routing can be managed over API through a list of route rules specified as a JSON object defined in a specific format.
Every expression within routing can be constructed with at least one or more available operators. Result of the expression will be a success true
only if all results of operations are true
. The query will be executed, one expression after another, in the order they are submitted until the new inbound message first matches the expression. Then the message will be assigned to the matched queue.
Example:
{
"routes":
[
{
"name": "English Support",
"queueId": "8772F93BC855D00A1036B771ACA7EC40",
"priority": "NORMAL",
"enabled": true,
"expression": {
"$or": [
{
"$eq": {
"customer.country": "United Kingdom"
}
},
{
"$eq": {
"customer.country": "Australia"
}
}
]
}
},
{
"name": "Spanish Support",
"queueId": "A1C93E138A8D831F49D047BC0A5B1D0D",
"priority": "NORMAL",
"enabled": true,
"expression": {
"$in": {
"customer.country": [
"Spain",
"Columbia",
"Mexico"
]
}
}
}
]
}
Bellow is a list of available methods for routing management:
Set Routing
The set routing method creates a new routing setup if it does not exist or replaces the existing setup.
Delete Routing
Use the delete routing method to remove the routing setup.
Get Routing
Use this method to get a list of rules within the routing.
Refer to the Routing article on the Infobip API Developer Hub for more information.
Routing Setup
The new message is compared by each rule (expression) in routing and when the first rule match, the message is added to the matched queue. If no rule has been matched, the message is not added to any queue.
The order of rules inside routing is important because the new message is compared to rules in the given order in Routing to find the first match.
Based on logical operators, every expression can be constructed with at least one or more available operators in combination. The result of the expression will be a success (TRUE) only if all results of operations are TRUE. The query will be executed, one expression after another, in the order they are submitted until the new inbound message first matches the expression. Then the message will be assigned to the matched queue. Because the processing order is crucial, only one operation (SET Routing) can set rules in the appropriate order.
Operators
Operators compare value and return the result of the operation (TRUE or FALSE) except AND and OR operator whichch compare the result of other operations (TRUE or FALSE).
Operator | Variable | Description |
---|---|---|
EQUALS | $eq | Compare two values. The searched value must be exact as a given value to return TRUE |
NOT_EQUALS | $neq | Compare two values. The searched value must be different than the given value to return TRUE |
LESS_THAN | $lt | Compare two values. The searched value must be less than the given value to return TRUE |
LESS_THAN_EQUALS | $lte | Compare two values. The searched value must be less or equal given value to return TRUE |
GREATER_THAN | $gt | Compare two values. The searched value must be greater than the given value to return TRUE |
GREATER_THAN_EQUALS | $gte | Compare two values. The searched value must be greater or equal given value to return TRUE |
AND | $and | Compare the result of two operations, both must be TRUE to return TRUE |
OR | $or | Compare the result of two operations, one or both must be TRUE to return TRUE |
IN | $in | Find the given value within the searched value. If found, the result is TRUE |
NIN | $nin | Return TRUE if the provided value is not found in searched value |
ALLIN | $allin | Return TRUE if all array values are found ([1,2,3] $allin [1,2] would return true, [1,2,3] $allin [3,4] would return false) |
ANYIN | $anyin | Return TRUE if any array value is found ([1,2,3] $anyin [1,20] would return true, [1,2,3] $anyin [4,7] would return false) |
STARTS_WITH | $starts_with | Find the given value in beginning searched value. If found, the result is TRUE |
Operands
Message data | Type | Description |
---|---|---|
from | string | Represents the sender ID and can be alphanumeric or numeric. Alphanumeric sender ID length should be between 3 and 11 characters (example: CompanyName). Numeric sender ID length should be between 3 and 14 characters. |
to | string | Message destination addresses. Destination addresses must be in international format (example: 41793026727) or FacebookId. |
content | string |
Text of the inbound message. Content limits are channel dependent. See length info for SMS. 1000 characters max. |
channel | string | Available channels are: SMS, VIBER, FACEBOOK_MESSENGER, WHATSAPP. |
Customer data is optional data but relevant only if you are using the People service. More information about customer data that can be used as operands can be found under the Body parameters section.
Query
Expression can be a single compare operation or complex compare operations.
Single Query
A single query is a simple expression containing only one compare operator.
The following example target is to route all messages that start with a keyword.
"name": "Keyword STOP",
"queueId": "1E54701F74BD86A070B43DB49478D82C",
"priority": "NORMAL",
"enabled": true,
"expression": {
"$starts_with": {
"message.content": "STOP"
}
}
If the message content is "STOP BOTHERING ME", the result is TRUE (operator $start_with) because the message content starts with the word "STOP" and the message will be routed to the queue name: "Keyword STOP".
"name": "Keyword STOP",
"queueId": "1E54701F74BD86A070B43DB49478D82C",
"priority": "NORMAL",
"enabled": true,
"expression": {
"$in": {
"message.content": "STOP"
}
}
An equal result can be achieved with the (operator $in) expression. The message content contains the word ''STOP''. Although different than the previous expression, this will also return TRUE if the message content is "PLEASE STOP BOTHERING ME".
Complex Query
For a more complex query, AND and OR operators can be used to combine multiple compare operation results. The following example target is to route messages with the phone number from a Croatian network operator and receive on any channel except Facebook Messenger.
"name": "Croatian Support",
"queueId": "04FAFF86C252478D324CF3F980799C9E",
"priority": "NORMAL",
"enabled": true,
"expression": {
"$and": [
{
"$starts_with": {
"message.customerNumber": "385"
}
},
{
"$neq": {
"message.channel": "FACEBOOK_MESSENGER"
}
}
]
}
Here operator $and requires that both conditions must be TRUE. The first condition is $start_with so the customer's number must start with 385 which pertains to the Croatian country code. The second operator is $neq which requires that the message channel is not FACEBOOK_MESSENGER. So, every message that comes from Croatian a operator and is sent from any other channel than Facebook Messenger, will be routed to the queue name: "Croatian Support".