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.
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 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.
- The administrator creates a new Media Routing Domain (MRD) to entertain chat channel requests.
- Adds a new Channel Type
- Creates a Queue
Q1to enqueue any Broadband-related inquiries coming from WhatsApp. While creating the queue, the admin links the MRD
xyzto the queue
Q1so 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,
C1of the Channel Type,
- Sets the Routing Policy of the channel as Push.
Q1, as the default queue of the channel
C1. This implies that all requests coming on the channel
C1will by default be enqueued to the queue
Q1unless 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.
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
- 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
- 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
Q1which is the default queue for the channel
- 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
Activestate with a minimum number of agent tasks on the MRD
- 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
ACTIVEon 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
- 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).
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.
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.
- Links the MRD with the Channel Type
- The admin creates a new List,
- Creates a new Channel
C2, sets the Routing Mode as Pull (instead of Push) and, maps the Channel
C2to the List
- 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
- A 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.