Difference between revisions of "Queuing and routing customer requests in Pega Chat"

From PegaWiki
Jump to navigation Jump to search
(Adjusted the capability areas)
Tag: Visual edit
(Changed Application name - Daniela Siek)
Tag: Visual edit
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Design pattern|Title=Queuing and routing customer requests in Pega Chat|Description=Recommendations for balancing chat queues and agent workloads.|Version=8.4|Applications=Customer Service|Capability Area=Pega Chat|Owner=Don't know}}
+
{{Design pattern|Title=Queuing and routing customer requests in Pega Chat|Description=Recommendations for balancing chat queues and agent workloads.|Version=8.4|Applications=Pega Customer Service|Capability Area=Chat and Messaging|Owner=Don't know}}
  
 
== Overview ==
 
== Overview ==
For text-based interactions between customer service representatives (CSRs) and customers, a chatbot is usually the first point of contact and it is always available. When escalation to a human agent is sought by the customer (or triggered by the chatbot), Pega queuing and routing logic kick in.  
+
For text-based interactions between customer service representatives (CSRs) and customers, a chatbot is usually the first point of contact, and it is always available. When escalation to a human agent is sought by the customer (or triggered by the chatbot), the Pega queuing and routing logic kicks in.  
  
 
== Queuing ==
 
== Queuing ==
The first expected action from the customer will be queue selection, which is generally a proxy for intent expression. A chat queue is manned by one or more agents with a capacity to work on one or more text-based customer requests at the same time: concurrency is a configurable option at the agent, queue, and global level.
+
The customer's first expected action will be queue selection, which is generally a proxy for intent expression. One or more agents man a chat queue with a capacity to work on one or more text-based customer requests at the same time: concurrency is a configurable option at the agent, the queue, and the global level.
  
 
=== Configuring queues ===
 
=== Configuring queues ===
Separate queues are needed for business functions that need a distinct set of skills in a service representative. For example, billing could be a queue to direct all billing-related inquiries. It is recommended to avoid configuring too many queues because this might result in spreading the available agent capacity too thinly across the queues. Because queues cannot be prioritized, all incoming requests are given equal weight, which might lead to more urgent customer requests remaining queued for longer periods of time. It is also possible for customers to be denied a route to an agent on a particular queue because no agents have any free capacity.  
+
Separate queues are needed for business functions that need a distinct set of skills in a service representative. For example, billing could be a queue to direct all billing-related inquiries. Avoid configuring too many queues because it could spread the available agent capacity too thinly across the queues. '''''Chat requests are not prioritized by queue -'''''  all incoming requests are given equal weight, leading to more urgent customer requests remaining queued for longer periods of time. It is also possible for customers to be denied a route to an agent on a particular queue because there are no agents associated with that queue with free capacity.  
  
As customer wait times and rejection rates increase, even with a sizable agent pool, it could point to too many queues. Five or fewer is usually a good number to target, but it depends on other factors such handle times, number of agents, concurrency limits, etc.  
+
As customer wait times and rejection rates increase, even with a sizable agent pool, it could point to too many queues. Five or fewer is usually a good number to target, but it depends on other factors such as handle times, number of agents, concurrency limits, etc. For detailed steps on configuring queues, see [https://community.pega.com/knowledgebase/articles/pega-customer-service-implementation-guide/84/configure-chat-and-messaging-queues Configure chat and messaging queues]. 
  
 
=== Omnichannel queues ===
 
=== Omnichannel queues ===
Queues work in the same way for all messaging channels including asynchronous channels such as Facebook Messenger, WhatsApp, etc. Unless it is essential to have a queue specific to the source channel, it is recommended to use the same queue for a particular business function across multiple channels. This helps prevent the proliferation of queues, whose implications are detailed above.  
+
Queues work in the same way for all messaging channels, including asynchronous channels such as Facebook Messenger, WhatsApp, etc. Unless it is essential to have a queue specific to the source channel, use the same queue for a particular business function across multiple channels. This helps prevent the proliferation of queues, whose implications are detailed above.  
  
 
=== Customer wait time on queues ===
 
=== Customer wait time on queues ===
While queuing customer requests, Pega considers not only the ''current unutilized capacity of the agent pool'', but also the ''potential capacity'' that will be freed up to consume queued chats within a configured maximum wait time of a customer. By always estimating the wait time for a customer and evaluating this estimate against the maximum wait time (as configured by the business, keeping customer experience in mind), you ensure that an optimal balance is achieved between ''responsiveness to customer requests'' and ''contact center capacity'' at any given point in time.  
+
While queuing customer requests, Pega considers the ''current un-utilized capacity of the agent pool'', and the ''potential capacity'' that will be freed up to consume queued chats within a configured maximum wait time of a customer. By estimating the wait time for a customer and evaluating this estimate against the maximum wait time (as configured by the business, keeping the customer experience in mind), you ensure that an optimal balance is achieved between ''responsiveness to customer requests'' and ''contact center capacity'' at any given point in time.  
  
 
==== Maximum wait time ====
 
==== Maximum wait time ====
 
This configuration ensures that your customers will never spend egregiously long times waiting in the queue to be connected with an agent. Setting too low a limit will lead to customers being denied a place in the queue too often. So, it is important to find the optimal configuration after taking into account your business objectives.  
 
This configuration ensures that your customers will never spend egregiously long times waiting in the queue to be connected with an agent. Setting too low a limit will lead to customers being denied a place in the queue too often. So, it is important to find the optimal configuration after taking into account your business objectives.  
  
It is recommended to configure the maximum wait time to greater than the average handle time of customer interactions. A wait time between 300 and 600 seconds is generally agreeable to most customers. For example, setting the maximum wait time to 600 seconds would ensure that in cases where customers are expected to wait for longer than 10 times, the chat application would deny them service and request to retry later.  
+
Configure the maximum wait time to be greater than the average handle time of customer interactions. A wait time between 300 and 600 seconds is generally agreeable to most customers. For example, setting the maximum wait time to 600 seconds would ensure that in cases where customers are expected to wait for longer than 10 minutes, the chat application would deny them service and request to retry later.  
  
[[File:Picture 1.png|thumb|none|534x534px]]
+
[[File:Picture 1.png|thumb|none|534x534px|Setting wait time calculation]]
  
 
==== Expected wait time ====
 
==== Expected wait time ====
Line 36: Line 36:
 
·      Average time to handle a single chat
 
·      Average time to handle a single chat
  
A good balance of these two configurations (image above) would result in the most optimal data set to utilize for computing the expected wait time. Settling for too small a set of previous interactions or waiting for too large a set can skew the expected wait time. These settings are available in '''App Studio > Settings > Chat and Messaging > Chat and messaging configuration'''.
+
A good balance of these two configurations (image above) would result in the most optimal data set for computing the expected wait time. Settling for too small a set of previous interactions or waiting for too large a set can skew the expected wait time. These settings are available in '''App Studio > Settings > Chat and Messaging > Chat and messaging configuration'''. For more information, see [https://community.pega.com/knowledgebase/articles/pega-customer-service-implementation-guide/84/configure-chat-and-messaging-configuration-settings Configure chat and messaging configuration settings].  
  
 
== Routing ==
 
== Routing ==
  
 
=== Workload-based routing ===
 
=== Workload-based routing ===
Workload-based routing, which is the default option, works best in cases where 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
+
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 very specific set of skills
+
* 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
+
* agent compensation is directly tied to the amount of work they have handled, and it is important to distribute work uniformly
  
 
=== Skill-based routing ===
 
=== Skill-based routing ===
The skill-based routing option routes new requests to the CSR with the highest skill level of all the CSRs who are 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
+
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
 
* 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
+
* SLAs need to be adhered to, and therefore customer issues require the attention of the most skilled CSR available
  
 
=== Third-party routing ===
 
=== Third-party routing ===
Line 55: Line 55:
 
=== Concurrency limits ===
 
=== 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:
 
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
+
* 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
+
* 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
+
* 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]]
 
[[File:Global Concurreny image.png|left|frame|Conditional screen pop behaviors]]
  
 
=== 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 on the three configurations related to screen pop behaviors at '''App Studio > Settings > Chat and Messaging > Routing'''.
+
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 ===
 
=== Intelligent routing ===
It is recommended to use the metadata captured for each messaging interaction to autodirect the requests to specific queues. Identified language, message type, and channel data can be used to 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 simply be shown the Billing queue and the metadata can be used to select the more specific queue internally.
+
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.

Latest revision as of 23:03, 8 June 2021

Queuing and routing customer requests in Pega Chat

Description Recommendations for balancing chat queues and agent workloads.
Version as of 8.4
Application Pega Customer Service
Capability/Industry Area Chat and Messaging



Overview[edit]

For text-based interactions between customer service representatives (CSRs) and customers, a chatbot is usually the first point of contact, and it is always available. When escalation to a human agent is sought by the customer (or triggered by the chatbot), the Pega queuing and routing logic kicks in.

Queuing[edit]

The customer's first expected action will be queue selection, which is generally a proxy for intent expression. One or more agents man a chat queue with a capacity to work on one or more text-based customer requests at the same time: concurrency is a configurable option at the agent, the queue, and the global level.

Configuring queues[edit]

Separate queues are needed for business functions that need a distinct set of skills in a service representative. For example, billing could be a queue to direct all billing-related inquiries. Avoid configuring too many queues because it could spread the available agent capacity too thinly across the queues. Chat requests are not prioritized by queue - all incoming requests are given equal weight, leading to more urgent customer requests remaining queued for longer periods of time. It is also possible for customers to be denied a route to an agent on a particular queue because there are no agents associated with that queue with free capacity.

As customer wait times and rejection rates increase, even with a sizable agent pool, it could point to too many queues. Five or fewer is usually a good number to target, but it depends on other factors such as handle times, number of agents, concurrency limits, etc. For detailed steps on configuring queues, see Configure chat and messaging queues.

Omnichannel queues[edit]

Queues work in the same way for all messaging channels, including asynchronous channels such as Facebook Messenger, WhatsApp, etc. Unless it is essential to have a queue specific to the source channel, use the same queue for a particular business function across multiple channels. This helps prevent the proliferation of queues, whose implications are detailed above.

Customer wait time on queues[edit]

While queuing customer requests, Pega considers the current un-utilized capacity of the agent pool, and the potential capacity that will be freed up to consume queued chats within a configured maximum wait time of a customer. By estimating the wait time for a customer and evaluating this estimate against the maximum wait time (as configured by the business, keeping the customer experience in mind), you ensure that an optimal balance is achieved between responsiveness to customer requests and contact center capacity at any given point in time.

Maximum wait time[edit]

This configuration ensures that your customers will never spend egregiously long times waiting in the queue to be connected with an agent. Setting too low a limit will lead to customers being denied a place in the queue too often. So, it is important to find the optimal configuration after taking into account your business objectives.

Configure the maximum wait time to be greater than the average handle time of customer interactions. A wait time between 300 and 600 seconds is generally agreeable to most customers. For example, setting the maximum wait time to 600 seconds would ensure that in cases where customers are expected to wait for longer than 10 minutes, the chat application would deny them service and request to retry later.

Setting wait time calculation

Expected wait time[edit]

Key factors that impact the expected wait time:

·      Capacity of the agent pool at any point in time (this would be the active agents multiplied by the concurrency allowed for each agent on the queue)

·      Number of queued chats ahead of the customer in question

·      Number of active chats that the agent pool is currently working on

·      Average time to handle a single chat

A good balance of these two configurations (image above) would result in the most optimal data set for computing the expected wait time. Settling for too small a set of previous interactions or waiting for too large a set can skew the expected wait time. These settings are available in App Studio > Settings > Chat and Messaging > Chat and messaging configuration. For more information, see Configure chat and messaging configuration settings.

Routing[edit]

Workload-based routing[edit]

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[edit]

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[edit]

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[edit]

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
Conditional screen pop behaviors

Conditional screen pop behaviors[edit]

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 Configuring chat and messaging routing.

Intelligent routing[edit]

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.