Pull-mode vs Precision Routing

When a new customer request is received on a channel, the system determines if this request should be PUSHED/ routed to an agent or be published on a List for any agent to PULL and answer it.

Push Routing

Whenever a new request is received from a channel, it is enqueued to a queue associated with the channel, only if the Routing Policy of the channel is set to Push mode.

In this type of routing policy, the Routing Engine routes and assigns requests to the most suitable agent based on the agent selection criteria defined in the Queue Steps. 

In summary, this type of policy lets the system push a customer request to an eligible agent. The agent sees a button to accept the request in the ringing alert.

Sample Use Case with Push Routing

Example Use caseCustomers 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 ConfigurationsThe 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 (4.5) 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 channel C1. This implies that all requests coming on 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 (4.5) 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 particular channel is supposed to land on a List (described above) instead of a Queue. 

Agents subscribed to the List would automatically receive new request notifications on the List. They can then choose to Join a request or Dismiss the notification, and later join if needed. 

Sample Use Case with Pull Routing

Example Use case:The customer posts a comment on the company's Facebook Social Media page. Admin ConfigurationsThe 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.Links the MRD with the Channel Type Facebook.The admin creates 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 now set to receive all customer comments posted on the Facebook page. The channel then publishes all new requests on the List L1.WorkflowA customer, John Williams, posts a new comment on the company's Facebook page.  The system receives the comment and publishes this as a new chat request to the List associated with the channel.  All agents who are subscribed to the List get the new incoming request notification.One or more agents join the conversation.The agent(s) who have joined the conversation get subscribed to the Conversation notifications and will see notifications such as, Agent joining, and Agent leaving that are flown through during the conversation.