Table of Contents

Omni-channel queue-based routing mechanism

Pega Customer Service uses omni-channel routing to direct new conversation requests to the right queue and customer service representative (CSR) based on the skills required to complete the work as efficiently as possible. Omni-channel queue-based routing is available for chat and Facebook Messenger.

The routing algorithm is divided into the following major sub-processes:

Pre-routing processing

When a customer requests to chat with an agent from a supported conversation channel, the application presents a list of available queues from which the customer can select one. If pre-assignment questions are configured for the queue, the customer is required to answer each of the questions, which the routing engine takes and routes with the request. The answers to pre-assignment questions become a part of the interaction transcript. The routing engine adds the request to a queue below other existing requests. The routing queue prioritizes the requests based on their arrival time: older requests take higher priority over more recent ones. 

Request routing

When a new request enters the queue, the queue processor calls the routing API, which routes the request present in the queue to a qualified CSR. The routing engine selects from the available CSRs based on the following criteria, in descending order of priority:

  1. Least occupancy: A request is sent to the CSR who is handling the least number of active chats. For example, if CSR1 is handling three active chats and CSR2 is handling two, the new request is routed to CSR2. 
  2. Time since last acceptance: If there is a tie between multiple CSRs on least occupancy, the engine routes the request based on the time gap since they last accepted a request. For example, if CSR1 accepted the last request at 9:00 AM and CSR 2 accepted the last request at 9:01 AM, the engine routes the request to CSR1.
  3. Earliest log in: If more than one CSR has the same occupancy level and time since last acceptance (for example, the start of the first shift of the day), the request is routed to the CSR who logged in to the application first. For example, if CSR1 logged in to the application at 9:00 AM and CSR 2 logged in at 9:15 AM, the engine routes the request to CSR1.

For more information about how queue processors work, see Queue Processor rules

Transferred conversations

As a part of the resolution, a CSR might have to transfer a conversation to another queue or agent. If the CSR transfers the conversation to another queue, the request goes through the routing process again. However, to reduce further customer wait time due to a transfer, the routing algorithm prioritizes transfers ahead of other work for that queue (effectively telling the routing engine to route the transferred Interaction first). 

In the case of agent-to-agent transfers, the transferring CSR can only select another available agent; the CSR cannot transfer a conversation to a CSR who is unavailable or who has reached their maximum number of concurrent interactions. These transfers bypass the routing algorithm and send a request alert directly to the recipient CSR. The conversation is transferred only when the recipient CSR accepts the request.

Pending request routing

Sometimes a CSR loses availability prior to the conversation being successfully routed or the CSR declines the new work. The routing engine reroutes a conversation request in the following two cases:

  • Busy CSRs: When all of the available CSRs in the queue are handling conversations to their full capacity as configured in the Max concurrent conversations (from this queue) field.
  • CSR decline: When the agent to whom the request is routed declines it.

For rerouting a pending conversation request, the routing engine adds the request to the queue and then waits for a specified time period before for reattempting. After the delay, the routing engine attempts to route the request again.    

The rerouted requests take precedence over new incoming requests because the engine considers the initial queuing time for prioritization rather than the latest queueing time.

Conditions for non-routing of live chat requests

Customers cannot chat with a live CSR in the following cases:

  • No CSRs available (applies only to live chat conversations): When no agent has logged into the selected queue, the routing engine sends the configured Agent not found message to the customer after selecting a queue.
  • Maximum wait time exceeded (applies only to live chat conversations): The routing engine periodically calculates the estimated wait time required to route the incoming or queued conversation requests based on the configured Wait time evaluation window. If the calculated wait time for the conversation request exceeds the configured maximum wait time, the routing engine sends the configured Agent not found message that is configured for the queue after the customer selects the queue. 
  • Off Hours (applies only to live chat conversations): The routing engine sends the configured Off-hours behavior message to the customers when they attempt to live chat during the queue off hours. 
In the case of messaging conversation requests through Facebook Messenger, the routing engine does not stop the customer from initiating a conversation during off-hours or when the maximum wait time is exceeded. Customers may send a message when no CSR is available. The routing engine can acknowledge receipt of the message, and then hold the messages in the queue until a CSR becomes available. At this point, the routing engine attempts to route these delayed messages to an available CSR.
Suggest Edit

Have a question? Get answers now.

Visit the Pega Support Community to ask questions, engage in discussions, and help others.