View source for Queuing and routing customer requests in Pega Chat

== Routing ==

=== Workload-based routing ===
Workload-based routing, which is the default option, works best when customer interactions are of low complexity and high volume in nature. Selecting this option routes new requests to agents who have fewer active chats. Choose this option if your objective is to uniformly distribute the incoming customer requests among all available agents. Workload-based routing is applicable where
* customer issues are generic and not differentiated or complex to require a very specific set of skills
* agent compensation is directly tied to the amount of work they have handled, and it is important to distribute work uniformly

=== Skill-based routing ===
The skill-based routing option routes new requests to the CSR with the highest skill level of all the CSRs available to take on more requests. Choose this option if customer interactions are of high complexity and low volume in nature. Skill-based routing is applicable where
* customer issues are complex and non-generic, requiring differentiated skills in a CSR
* SLAs need to be adhered to, and therefore customer issues require the attention of the most skilled CSR available

=== Third-party routing ===
In cases where you need to support blended agents, you can opt for third party routing. With this option enabled, the responsibility of routing incoming chat requests will be delegated to a third-party routing service, which could be the same service that handles the routing of incoming calls. This type of routing helps centralize your routing logic in an external service to support agents who can handle both call and text-based customer interactions. 

=== Concurrency limits ===
Service representatives are typically expected to handle multiple text-based conversations at the same time (concurrently). Pega Chat allows you to define this limit at three different levels:
* Global: A value that applies to all the CSRs handling text-based interactions
* Queue: A value that can be configured at the queue level to specify the maximum number of interactions, on the particular queue, that a CSR can concurrently handle
* Agent: An option for service managers to define concurrency limits at the individual CSR level to suit the agent's experience and competence
[[File:Global Concurreny image.png|left|frame|Conditional screen pop behaviors]]

=== Conditional screen pop behaviors ===
To ensure that the wait time estimates communicated with the customer are honored, it is essential that the agents accept chat offers as expected. A level of certainty can be achieved by toggling the three configurations related to screen pop behaviors at '''App Studio > Settings > Chat and Messaging > Routing'''. For detailed steps on configuring routing, see [https://community.pega.com/knowledgebase/articles/pega-customer-service-implementation-guide/84/configuring-chat-and-messaging-routing Configuring chat and messaging routing]. 

=== Intelligent routing ===
It is recommended to use the metadata captured for each messaging interaction to automatically direct  requests to specific queues. Identified language, message type, and channel data can decide on a queue based on the intelligent routing configurations. Using the metadata avoids the need to expose queue names that are too specific to customers, for example, Billing-German-Twitter-Public. The customer can be shown the Billing queue, and the metadata can be used to select the more specific queue internally.