Queuing and routing customer requests in Pega Chat

From PegaWiki
Revision as of 18:23, 11 September 2020 by Fultd (talk | contribs) (Interview review)

Jump to navigation Jump to search

Curator Assigned
Request to Publish Yes
Version as of
Capability/Industry Area

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.

When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓


For text-based interactions between service representatives 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.


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.

Configuring queues[edit]

Separate queues are needed for business functions which need distinct set of skills in a service representative. For e.g. Billing could be a queue to direct all billing related inquiries. It is recommended to not configure too many queues as this may result in spreading the available agent capacity too thinly across the queues. As queues cannot be prioritized, all incoming requests will be given equal weight, and this may at times 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 available agents have any free capacity.

As customer wait times and rejection rates increase, even with a sizeable agent pool, it could point to too many queues. Five or fewer is usually a good number to target but it is dependent on other factors such as question complexity, handle times, number of agents, concurrency limits etc.

Channel specific queues[edit]

Queues work the same 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, the implications of which are detailed above. The one use case where channel specific queues might make sense for your business is when you need to change concurrency rate per channel. For example, your 'live chat' agents might need a lower concurrency rating given the live nature of the channel for billing questions, versus your Facebook Messenger focused agents, resolving issues over longer periods of time (and periods of inactivity by end-users) are asked to work a much larger list of concurrent assignments to address the 'dead-time' between a CSR question and an end-user getting back with a response.

Customer wait time on queues[edit]

While queuing customer requests, Pega considers not only the current unutilized capacity of the agent pool, but also the potential capacity that will 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 can ensure that an optimal balance is achieved between responsiveness to customer requests and contact center capacityat any given point in time.

Maximum wait time[edit]

This configuration ensures that your customers will never spend egregiously long times waiting on the queue to connected with an agent. Setting too low a limit will lead to customers being denied a place on 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 e.g. setting maximum wait time to 600 seconds would ensure 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.

Expected wait time[edit]

Key factors that impact the expected wait-time:

Picture 1.png

·      the capacity of the agent pool at any point in time (this would be 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 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 App Studio > Settings > Chat and Messaging > Chat and messaging configuration


Workload based routing[edit]

Workload based routing, which is enabled as 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:

  • customer issues are repeatable, consistent in nature, low complexity and the workforce are generalists, and knowledgeable about most products and services
  • 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]

Skill based routing: Selecting this 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

  • customer issues are complex and non-generic, requiring differentiated skills in a CSR
  • SLAs need to be adhered to, have penalties if missed, and hence 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 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.

  1. Global: this value applies to all the CSRs handling text-based interactions
  2. Queue: a value can be configured at the queue level to specify the maximum number of interactions, on the particular queue, a CSR can concurrently handle
  3. Agent: Service managers are provided with an option to define concurrency limits at the individual CSR level to suit the agent's experience and competence

Conditional screenpop behaviors[edit]

In order 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 screenpop behaviors at App Studio > Settings > Chat and Messaging > Routing. This allows (within reason) declines or ignores - but focuses on reducing the number of declines and ignores within your contact center. This functionality is important if you have granular queues with low staffing, where a decline by a CSR may have a detrimental impact on the overall service experience for the customer.

Conditional screen pop.png

Intelligent routing[edit]

It is recommended to utilize the metadata captured for each messaging interaction to auto-direct the requests to specific queues. Identified language, message type and channel data can be used to decide a queue based on the intelligent routing configurations. This avoids the need to expose queue names that are too specific to customers for e.g. 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.