CX-Routing

When a request to talk to an agent is received by CIM, the Routing Engine looks for an available human agent to service the request. It uses Routing Attributes assigned to the agents and evaluates the resources based on Queue Steps and Expressions defined for a particular queue. Learn more about each of these terms in the following sections of the doc.

Routing Attributes

While creating an Attribute, the admin can specify a default value. This default value is automatically assigned to the agent at the time of attribute assignment. The admin may change the default value for each assigned agent at the time of the Attribute assignment.

Media Routing Domains (MRDs)

For instance, an admin creates an MRD called, CHAT, for handling all types of Chat requests. It creates separate Channel Types such as Facebook chat, WhatsApp chat, Web chat, and associates the same CHAT MRD to all those Channel Types since all chat-type requests are of the same nature.

When a new customer request is received from a Channel, it is pushed to an MRD associated with the Channel Type of that channel. Based on Agent States on the MRD, the Routing Engine evaluates and assigns an agent to the request.

Business admins can define the maximum number of requests that any agent can simultaneously handle on one MRD through Unified Admin.

Read more about Channels, Channel Types, Channel Connectors, and Channel Sessions on _Channel related terms.

Queue

A queue or precision queue is responsible for hosting new requests generated by a customer. In each precision queue, there are some agents to answer customer requests being queued in the precision queue. Agents become members of precision queues automatically based on their Routing Attributes.

For instance, if a precision queue requires an agent who lives in Boston, is fluent in Spanish, and is skilled enough in troubleshooting a piece of equipment, an agent Sussane with the attributes, Boston = True, Spanish = True, and Repair = 10 automatically becomes a part of the precision queue. Therefore, a Spanish caller in Boston who needs help with the equipment is routed to that agent.

A precision queue consists of Terms, Expressions, and Steps.

Term

A term compares an attribute against a value. For example, you can create the following term: Spanish == 10. Each precision queue can have multiple attributes, and these attributes can be used in multiple terms. For example, to select an agent with an English proficiency value between 5 and 10, the admin may create one term for English > 5 and another for English<10.

Expression

An expression is a combination of one or more terms. For instance, an expression (Boston == true) AND (Spanish == true) AND (Repair == 10) implies that agents living in BOSTON, fluent in Spanish and excellent in repairing skills are the best candidates for routing customer requests in this queue.

The expressions are by default evaluated from left to right. For instance, the following expression is evaluated as the following:

CODE

(Boston == true) AND (Spanish == true) AND (Repair == 10)

→ true AND true AND false

→ true AND false

→ false

Step

A step consists of a combination of one or multiple expressions. When a request is landed in a queue, the steps are executed to evaluate the routing logic and pick the right agent. You can add one or more steps for one queue. Each step has a step timeout in seconds which determines the time that the system waits before jumping on to the next step in the queue.

After the evaluation of the first step, if the system finds no agent matching the routing logic defined in the step, it jumps to evaluate the next step and keeps doing so until it finds an available agent. Steps are executed in the order they are created.

List

Most small-scale businesses or certain channel types with asynchronous activities require customer requests to be broadcasted to a List that an agent may subscribe to. Lists allow the system to park requests of certain channels in a list instead of queueing them. Agents subscribed to the List get real-time notifications of new chats being landed on the List. Agents may subscribe to one or multiple Lists. This type of request routing is called Pull-based Routing. See the following sections to learn more about Pull Routing.

To learn how to create new lists and assign them to certain channels, see Administrator Guide.

A Request (a List entry or a new chat in the list) may be in any one of the following states:

UNREAD - until no agent has joined it
ACTIVE - when at least one agent is working on it
INACTIVE - when there's no agent working on this request. But, at least one agent joined this request earlier and left without closing it.
CLOSED - upon closure of the request when the request was removed

Agents

Agents are supposed to be the contact center users who are eligible to answer customer requests.

Agents can be synchronized with the client's Active Directory and/or can be created and managed within Keycloak manually. Business admins can view all users having a certain Keycloak role or a set of roles in a User list within the Unified Admin App. They can then assign these users some Routing Attributes for the system to route customer requests to them.

Agent States

An Agent can be in any one of the following global states irrespective of the MRD which the agent is a part of:

From	To	Description
LOGOUT	LOGIN	LOGIN is a transient state and transitions to NOT_READY.
LOGIN	NOT_READY	When an agent is NOT_READY MRE doesn’t route any new request to this agent. After login, the agent is transitioned to NOT_READY.
NOT_READY	READY	Once an agent is ready, new requests of an MRD may be routed to the agent depending upon the Agent MRD State.
READY	NOT_READY	Once an agent switches the state to `NOT_READY` state`,` all MRD switches will be turned off. The top agent-state dropdown turns grey and displays the Not Ready reason of the agent.
NOT_READY	LOGOUT	Switch-off all MRDs, re-route all tasks, and Logout this agent
any logged-in state	LOGOUT	If the agent has any active tasks on any MRD it'll be re-routed.

Agent MRD States

Additionally, the agent can be in a different MRD state based on the number of tasks he/she's handling on that MRD.

From	To	Description	Routable
-	LOGIN	The agent's state immediately after signing in. No tasks are assigned to an agent while in this state. The LOGIN state is a transitive state; LOGIN triggers a change that results in a new state (NOT_READY).	None; the user transitions to NOT_READY automatically
LOGIN	NOT_READY	The agent won't be assigned tasks. The agent enters the NOT_READY state automatically after signing in. The toggle switch of the MRD state turns grey and remains `OFF`.
NOT_READY	READY	The agent is available to take new requests on this MRD. The toggle switch of the MRD state goes green and turns `ON`.
	INTERRUPTED	When the routing engine has interrupted the agent on this MRD because of some other high-priority MRD task. Note: The agent cannot switch himself to this state.	(yet to implement)
READY	NOT_READY
READY	ACTIVE	When the agent is working on at least one task in this MRD. The toggle switch of the MRD state goes orange and remains `ON`.
ACTIVE	BUSY	When the agent has already been offered the maximum number of tasks in this MRD. The agent can therefore not receive new tasks in this MRD. [no-of-tasks = max_tasks] Note: The agent cannot switch himself to this state. The toggle switch of the MRD state goes red and remains `ON`.
	UNKNOWN	In a failover scenario, an agent state may be set to UNKNOWN. The agent can switch to READY or NOT_READY from an UNKNOWN state.
ACTIVE	PENDING_NOT_READY	If and when the agent switches off this MRD while the agent is `ACTIVE` . The toggle switch of the MRD state goes purple and turns `OFF`.
ACTIVE	READY	If the last task for an Agent MRD is closed, change state to READY
BUSY	PENDING_NOT_READY	If and when the agent switches off this MRD while the agent is `BUSY` . The toggle switch of the MRD state goes purple and turns `OFF`.
PENDING_NOT_READY	NOT_READY	The agent state will be transited to NOT_READY automatically after all the active tasks are ended when the agent is in the PENDING_NOT_READY state. The toggle switch of the MRD state goes grey and remains `OFF`.

Task

The Routing Engine creates a new task for a human agent for each new request that is routed to the agent. When the agent closes the request, the task status is also closed.

A Task can be in any one of the following states:

Queued: When the Task is enqueued in a precision queue
Reserved: When the task is offered to an agent and the agent is yet to accept it.
Active: When an agent has accepted and is active on the Task.
Wrap-up: When the agent is applying a wrap-up (yet to implement)
Closed: When the task is done and no further action is required.

Routing Policy

Routing policy determines if a request should be pushed to an agent or published to a Subscription List.

There are two types of routing policies:

Push Routing
Pull Routing

Push Routing

In this type of routing policy, the business decides to route and assign requests to the best suitable agent based on the agent selection criteria defined under the queue configurations. Whenever a new request is received from a channel, it is parked in a queue associated with the channel. To learn how to add new channels and associate queues to channels, see Administrator Guide.

Based on the routing logic embedded in the Queue Steps (mentioned above), the Routing Engine picks an available agent who best matches the criteria and assigns the request. In short, this type of policy lets the system push a customer request to an agent. The agent has no option other than to Accept such a request.

Sample Use case with Push Routing

Example Use case

Customers from Los Angeles are facing problems with their broadband devices these days. A special channel and a queue need to be set up to answer customer queries.

To achieve this, let's see what will be configured and experienced on the Unified Admin and Agent Desk respectively.

Admin Configurations

The administrator creates a new Media Routing Domain (MRD) to entertain chat channel requests.
Adds a new Channel Type WhatsApp to handle WhatsApp chats and link this Channel Type to the MRD, xyz, created above.
Creates a Queue Q1 to enqueue any Broadband-related inquiries coming from WhatsApp. While creating the queue, the admin links the MRD xyz to the queue Q1 so that agents who are part of the queue can be assigned chat requests based on the available MRD states (i.e. Ready, Active, Busy, etc.).
Creates a new Channel, C1 of the Channel Type, WhatsApp, assuming that this channel is supposed to take customer chat requests from a dedicated WhatsApp number such as 123456.
Sets the Routing Policy of the channel as Push.
Adds Q1, as the default queue of the channel C1. This implies that all requests coming on the channel C1 will by default be enqueued to the queue Q1 unless the bot decides, otherwise.

The following diagram depicts the linking of internal solution components and their relationships with each other.

Since customers who approach from Los Angeles for fixes to their broadband devices should be routed to agents who can speak in English and are skilled enough to answer technical queries related to Broadband connection, the admin creates the following Routing Attributes.

English (Boolean type)
Los Angeles (Boolean type)
Broadband (Proficiency type)

So the queue logic would state:

(English==true) AND (Los Angeles==true) AND (Broadband>=7)

See Administrator Guide -> Add Steps to the Queue to see how to define queue criteria.

Example chat.

Let's see what happens when a new request on C1 comes in:

A customer 'John Williams' sends a WhatsApp message from Los Angeles, to report a problem related to a broadband device and wants to talk to a human agent.
The chat request is received on the channel C1.
A new channel session for the customer, John is created in the system for the WhatsApp channel request since this is the first message from the customer on this channel.
The customer is identified as John, using his channel identity for WhatsApp channel.
Bot Framework checks if a Conversation from John already exists. If not, it creates a new Conversation for the customer, and the Channel Session is added to the same Conversation.
The chat request landed in the queue Q1 which is the default queue for the channel C1.
The Routing Engine looks for an available agent in the queue based on the routing logic defined in the Queue Steps.
The Routing Engine finds an agent, Sussane who meets the queue criteria, and is the Longest Available in READY or Active state with a minimum number of agent tasks on the MRD xyz.
The Routing Engine assigns the chat request to Sussane.
The Routing Engine creates an Agent Task for Sussane to work on this chat request.
Sussane accepts the request and starts the conversation with John.
Sussane's state turns from READY to ACTIVE on the MRD xyz. See Agent States for details of MRD state transitions.
John gets the answer to his query.
Sussane greets John and leaves the conversation.
John also leaves the conversation.
Sussane's MRD state turns from ACTIVE to READY on the MRD xyz.
The system clears the conversation from Sussane's frontend interface.
The bot framework decides whether or not to close the conversation based on the Bot training (such as closing the conversation when both the customer and the agent leave the conversation).

Pull Routing

In this policy, a customer request received from a certain channel is supposed to land on a List (described above) instead of a Queue. To learn how to add new channels and associate Lists to channels, see Administrator Guide.

An agent who's subscribed to the List notifications would be able to see that a new request is received on the List. He may then choose to JOIN the request or Dismiss the notification and may later join if needed. One or more agents may JOIN a request simultaneously and may choose to Leave the request at any time.

A request listed on a List may be closed by an authorized agent at any time. A request can be closed if it is:

Active with an Agent
In Inactive state
In Unread state

Sample Use Case with Pull Routing

Admin Configurations

The same level of configurations are done in Unified Admin, for this scenario as done for Push-based Routing, except for the following differences:

The admin creates an MRD to capture Social media requests from customers.
Adds a new Channel Type Face Page Comments.
The admin adds a new List L1.
Creates a new Channel C2, sets the Routing Mode as Pull (instead of Push) and, maps the Channel C2 to the List L1. This channel is supposed to receive all customer comments posted on the Facebook page. The channel should then publish all new requests on the List L1.

Example Chat.

A new comment is posted on the company's Facebook Page mentioned in the Service Identifier field of the channel configs. See Administrator Guide to learn more.
The system publishes the request to the list associated with the channel, i.e. L1.
All agents subscribed to the List L1 get the new incoming request notification.
One or more agents try to join the Conversation.
The agent(s) who joined the chat are subscribed to the Conversation notifications such as, Agent joining, and Agent leaving notifications that are flown through during the conversation.

Flow Diagram