This guide describes the concept of Precision Queue, its contributing elements, and configuration. MRE triggers (getting newly created agents from UMM, new configuration application in MRE, task selection triggers in MRE) and limitations of MRE (MRE, Mre Microservice & Mre UI).
Architecture and Communication Flow
Following components are involved in MRE:
Mre is a Java-based backend service that routes tasks to agents. MRE contains routing logic, when a new task is initiated, this task is enqueued in a precision queue in MRE which routes this task to Longest Available Agent
Mre-microservice is Node.js based backend API which is directly connected to MongoDB and stores the following configurations in the database:
- Agents (replica of UMM agents)
- Precision Queues
MRE Microservice exposes APIs for CRUD of mentioned configurations
Mre-UI is UI part of Mre-Microservice which consumes these APIs and is used to CRUD operations of these configurations. MRE-UI connects to Mre-Microservice via UMM (UMM is middleware for microservice architecture).
User Management Module stores agents in its database which is accessible via its APIs.
The following diagram shows the flow of communication between these components.
In this image, green-colored boxes represent ActiveMQ queues, and other boxes represent Media Routing Engine components.
The communication flow is as follows:
- Administrator logs into MRE-UI, this request is sent to UMM for authentication
- MRE-UI fetches data from Mre-Microservice via UMM
- When clicked on the Agents tab, MRE-Microservice fetches agents from UMM to sync if any new agent is added in UMM, Agents list takes some time to load in MRE-UI and this is the reason for its slowness
- When / if new agents are added, Mre-Microservice pushes this information to the “routing engine” queue, MRE listens to this queue and receives that information
- Mre updates its agent list
- When an attribute / mrd/ precision queue is added is Mre-UI, Mre-microservice pushes this information to “routing engine” queue from where MRE gets this information and acts accordingly
MRE Start / Restart Steps
When MRE is restarted/started, the following steps are performed:
- MRE calls UMM API to get all agents (depending upon user type i.e. CC or DB)
- MRE associate all agents with Default Precision Queue
- MRE pushes the following commands to the mre-microservice queue in the same order as written below
- Get all Attributes
- Get all Agents
- Get all MRDs
- Get all Precision Queues
- Mre-Microservice consumes messages from the mre-microservice queue, gets the information from DB according to a command received, and pushes data to the “routing engine” queue.
- MRE receives configuration events from the “routing engine” queue and acts accordingly
How Media Routing Works
Media Routing Features & Definitions
MRD (Media Routing Domain)
MRD organizes how requests for each communication medium are routed to agents. An MRD for each media channel is configured in deployment.
Types of MRDs
These are major categories:
- Interactive/Non-Interactive MRDs
- Interruptible/Non-Interruptible MRDs
Interactive MRDs maintain a session b/w customer and agent, in which both communicate in real-time. E.g. chat, SMS, etc.
Non-interactive MRDs do not maintain a session. E.g. eMail. These tasks are asynchronous as customers can send an eMail, close the window, and check back later for a response.
Interruptible and Non-Interruptible MRDs
- Interruptible: Agents handling tasks in the MRD can be interrupted by tasks from other MRDs. Non-interactive MRDs, such as an email MRD, are typically interruptible.
- Non-Interruptible: Agents handling tasks in the MRD cannot be interrupted by tasks from other MRDs. The agents can be assigned tasks in the same MRD, up to their maximum task limits.
MRE only supports Interruptible & Interactive MRDs until this version. Non-Interactive & Non-interruptible MRDs support is still in pipeline
Media Routing Engine consists of two components:
- Communication Server
- Routing Engine
Following is a brief introduction of both components:
Communication Server manages the Agent States & Task States for non-voice MRDs. Communications Server subscribes to Finesse notifications for Agent & Dialogs Voice MRD states. It enables the Communication Server to provide Media Blending.
- n-interruptible chat tasks; if the agent is currently handling two chat tasks, the media routing engine can assign the agent another chat, but cannot interrupt the agent with an email. Interactive MRDs, such as a chat MRD, are typically non-interruptible. Voice is non-interruptible.
- Mixed: agent's active chat sessions will remain active while he'll continue to receive the inbound call as well because MRE will not change the agent's Finesse state.
Following approaches are used to handle interrupts:
- Accept Interrupts
- When an agent is interrupted by a task from a non-interruptible MRD while working on a task in an interruptible MRD, an interrupt event is accepted.
- The agent state in the interrupted MRD change to INTERRUPTED.
- The agent cannot perform dialog actions while a task is interrupted.
- Ignore Interrupts
- When an agent is interrupted by another task while working on a task in an interruptible MRD, the interrupt event is ignored.
- The new task does not affect any of the agent's other assigned tasks. The agent state & task dialog state in the interrupted MRD does not change.
Mixed-mode for routing is not supported as per this release, so is Ignore Interrupts.
The agent can perform dialog actions on original task and the interrupting task at the same time. The agent's time on the original task does not stop while the agent is handling the interrupting task.
Example: An agent has an email task for 20 minutes, and is interrupted for 3 of those minutes with a chat task. The handled time for the email task is 20 minutes, and the handled time for the chat task is 3 minutes. This means that during a 20-minute interval, the agent handled tasks for 23 minutes.
Max Concurrent Tasks per agent per MRD
Hybrid Chat allows you to configure the maximum number of chat sessions an agent can handle at any given point. Max Concurrent Tasks Limit can be configured in Communication Server properties. However, the default max concurrent tasks limit is 5.
Tasks Routing to Agent
It depends upon:
- Agent State: Agent’s state in MRD. Following are agent states
* Every MRD has its own state
Conditions for a task to be routed
The task is routed to the agent if ALL these conditions are TRUE:
- The agent is in the ready state, AND
- The agent has not reached Max task limit in MRD, AND
The agent is NOT working on a task in a different Non-Interruptible MRD.
Scenario State Description If the agent is in between a conversation but the state is pending not ready PENDING_NOT_READY No more tasks will be routed to the agent until he changes his state from pending not ready to the ready state. If the agent is in an active state and has reached Max task limit ACTIVE No more tasks will be routed to the agent, as he is already handling a number of chats and has reached the limit of Max task limit, and the state will be changed to busy. If the state is ready and Max task limited has not reached READY The task will be routed to the agents. If the agent is in an interrupted state INTERRUPTED No chat will be routed to that agent in the INTERRUPTED state, agent chat state will be restored when the voice call ends.
Agent Selection Criteria
The agent is selected on the following criteria:
- Longest Available: Task is routed to an agent
- For example, if agent A is available for 50 minutes and agent B is available for 30 minutes, both agents have 0 tasks, a new task comes in, this task is routed to agent A. Now agent A has 1 task and B has 0. Another task comes in, this task is routed to agent B. At this point, both agents have 1 task per head. A new task will be routed to agent A at this point.
- Who is in a READY state for the longest time, AND
- Has not tasked more than any other available agent
Precision Queue Routing
Precision routing offers a multidimensional alternative to skill group routing. Routing Engine runs on precision queues.
To configure Precision Routing, you must do the following in Media Routing Engine Administration:
- Create attributes. Attributes are characteristics that can be assigned a True | False value or a Proficiency rating from 1 to 10.
- Assign attributes to agents. Routing Engine fetches agents from EF User Management Module.
- Create precision queues. Create Expressions and Steps while creating Precision Queues.
There is no need to add an agent to a precision queue; agents become members of precision queues automatically based on their attributes. If a precision queue requires an agent who lives in Boston, who speaks fluent Spanish, and who is proficient in troubleshooting a specific piece of equipment, an agent with the attributes Boston = True, Spanish = True, and Repair = 10 is automatically part of the precision queue. A Spanish caller in Boston who needs help with equipment is routed to that agent.
A precision queue includes:
- Terms: A term compares an attribute against a value. For example, the administrator can create the following term: Spanish == 10. The term of the attribute is the highest proficiency in Spanish. Each precision queue can have multiple attributes, and these attributes can be used in multiple terms. For example, to select an agent with a Spanish proficiency value between 5 and 10, one term for Spanish > 5 and another for Spanish < 10 would be created.
- Expressions: An expression is a collection of one or more terms. The terms in an expression must share the same operator—they must all be AND or must all be OR relationships.
- Steps: A precision queue step is a time-based routing point within the precision queue. A step is a collection of one or more expressions. A step may also include wait time. Use wait time to assign a maximum amount of time to wait for an available agent.
The default queue used for Task Routing is the FIFO queue.
This is the default queue used in the Routing Engine. The first task to enter the queue is the first to be served. Precision Routing uses FIFO queues.
The Task Scheduler decides which of the available agents is to be allocated the next task after a signal or property change.
Task Scheduler Invocation
Here are events/signals/property changes which invoke Task Scheduler for a specific queue in an MRD:
- An agent changes state to READY for the MRD
- A possibility of an unattended task in queue remains when an agent changes state to READY for MRD i.e. task is in queue and 1st agent gets READY for handling.
- A new task arrives for the MRD
- Possibility of an unattended task in queue remains in this scenario e.g. Single agent handling tasks, voice call interrupts tasks, new tasks arrived and agent state was INTERRUPTED so he was not selected on new task arrived trigger, and after end of voice call, agent becomes ACTIVE/READY. Trigger in following bullet states this issue.
- Agent state transition from INTERRUPTED to ACTIVE/READY for the MRD
- Possibility of unattended task in queue remains in this scenario e.g. Single agent handling tasks, voice call interrupts tasks, new tasks arrived and agent state was INTERRUPTED so he was not selected on new task arrived trigger, and after end of voice call, agent becomes ACTIVE/READY
- Agent state transition from BUSY to ACTIVE for the MRD
- Possibility of unattended tasks in queue e.g. agent is busy with max task sessions, new task arrives and is not assigned to the agent, after sometime agent ends a task.
Every queue in an MRD has its own Task Scheduler.
This is the default queue used in Routing Engine. First task to enter queue is the first to be served. Precision Routing uses FIFO queues.
Default Precision Queue
Upon startup, MRE fetches all agents from UMM with the MRE_Agent role. MRE creates a precision queue named DefaultPrecisionQueue and associates all agents with this queue. Meaning any task submitted to this queue will be routed to any available agent.
As per current release, here are limitations regarding MRE, Mre-Microservice & MRE-UI:
- Attributes must not be deleted in MRE-UI, otherwise unexpected behavior cannot be avoided
- Precision queues can be updated but not be deleted in MRE-UI, if a precision queue is deleted, MRE will need to be restarted to take effect