Use case with Push-based 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

1. The administrator creates a new Media Routing Domain (MRD) to entertain chat channel requests.

2. Adds a new Channel Type WhatsApp to handle WhatsApp chats and link this Channel Type to the MRD, xyz, created above.

3. 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.).

4. 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.

5. Sets the Routing Policy of the channel as Push. 

6. 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:

1. 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. 

2. The chat request is received on the channel C1. 

3. 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.

4. The customer is identified as John, using his channel identity for WhatsApp channel. 

5. 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.

6. The chat request landed in the queue Q1 which is the default queue for the channel C1.

7. The Routing Engine looks for an available agent in the queue based on the routing logic defined in the Queue Steps.

8. 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.

9. The Routing Engine assigns the chat request to Sussane.

10. The Routing Engine creates an Agent Task for Sussane to work on this chat request.  

11. Sussane accepts the request and starts the conversation with John.

12. Sussane's state turns from READY to ACTIVE on the MRD xyz. See Agent States for details of MRD state transitions.

13. John gets the answer to his query.

14. Sussane greets John and leaves the conversation.

15. John also leaves the conversation.

16. Sussane's MRD state turns from ACTIVE to READY on the MRD xyz.

17. The system clears the conversation from Sussane's frontend interface.

18. 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).