Escalations

Chatbots escalate conversations in the following cases:

• Customer request: Customers can specifically ask to speak to a CSR by entering text that corresponds to an escalation command in the chatbot configuration. Chatbots use natural language processing (NLP) and text analysis to determine the customer intent. For more information, see Configuring the Web Chatbot.
• Bot failure: If the bot cannot understand the customer intent for a predetermined number of times, the bot automatically begins the escalation process. For more information, see Configuring bot failure escalation settings.

Queues

Determining an appropriate queue for a customer request is the first step in the escalation process. A queue is a temporary container that holds and processes incoming chat and messaging requests. There are several ways of mapping a specific request to a queue. For chats, the system can autoselect a queue based on the URL from which the customer initiated the chat. You must configure at least one queue for requests to be collected and then routed. If you have several queues, you can prompt customers to list questions or options that map to different queues.

You can assign a series of questions to a queue that customers can answer when selecting the queue during escalation. Collecting information before the CSR accepts and starts work on an interaction saves time for both the customer and the CSR. Customers answer questions one at a time. When the customer answers all the questions, the interaction is ready to route. CSRs can see the answers provided by the customers in the Here's what we know section displayed above the interaction transcript.

The following are the key queue configurations that you can select to streamline the escalation process:

• The number of queues: Determine the number of queues to suit your customer workflows, organization process, and CSR skillset.
• Max concurrent conversations (for queue): Vary the maximum number of active conversations that a CSR can handle simultaneously for different queues depending on the type of request and CSR skills.
• CSR skills: Enter the skills that are required for the CSR to work in the queue. For example, if a queue requires English speakers who can process service requests, you define a skill for English and another skill for Service. You can add only those CSRs who have the specified skills to the queue.

For more information, see the Configure chat and messaging queues section in Queues.

Routing

When a new request enters the queue, the queue processor calls the routing API to determine the routing. The customer waits in the queue until the routing engine finds an available CSR.

The routing processor periodically checks the queued requests and compares its wait time with the maximum wait time. If the current wait time is lower, it attempts to route the request. This process continues until the request finds a suitable CSR or has spent more than the maximum configured time on the queue at which point it notifies the customer with the configured Agent not found message. You can configure routing to use one of two routing algorithms for all chat and messaging routing decisions.

Selecting this option routes new requests to CSRs who have fewer active chats, for example, a CSR who has one active conversation receives the interaction pop-up window before a CSR with two conversations. However, if multiple CSRs have low occupancy percentages, the routine engine uses the following criteria to choose a CSR (if the first criterion finds a suitable CSR, the engine skips the second).

• Time since last acceptance: The engine routes the request based on the time elapsed time since the CSRs last accepted an offer. For example, if CSR1 accepted their last request at 9:00 AM and CSR 2 took their last request at 9:01 AM, the engine routes the request to CSR1.
• Earliest login: If multiple CSRs have the same occupancy level and the same time since last acceptance (for example, the start of the first shift of the day), the engine routes the request to the CSR who logged in to the application first. For example, if CSR1 logged in to the application at 9:00 AM and CSR 2 logged in at 9:15 AM, the engine routes the request to CSR1.

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. The operator record of a CSR lists their associated skills, and each skill has a rating. When a CSR logs in to Pega Customer Service, they select which queues to log in. CSRs can see all the queues that they can join, based on their skills. The algorithm considers all skills and skill levels associated with a queue and counts the CSR skill level for each relevant skill.

You can optimize the routing experience further by configuring expected CSR responses to new assignment requests. Using the configuration in Routing, you can enforce that CSRs cannot decline new chat offers when the queue capacity crosses a certain configurable threshold or if the offer was declined by another CSR previously. The configurations ensure that the estimated wait time is honored.

For more information, see the Configuring chat and messaging routing section in Routing.

Conversation transfers

To resolve a customer case, CSRs might need to transfer a conversation to another queue or CSR.

If the transfer is to another queue, the conversation goes through the routing process again. However, to reduce further customer wait time because of a transfer, the routing algorithm prioritizes transferred conversations ahead of other work for that queue (effectively telling the routing engine to route the transferred interaction first).

In the case of agent-to-agent transfers, the transferring CSR can select only another available agent; a CSR cannot transfer a conversation to a CSR who is unavailable or has reached their maximum number of concurrent interactions. These transfers bypass the routing algorithm and send a request alert directly to the recipient CSR. The conversation is transferred only when the recipient CSR accepts the request.

Rerouting requests

The routing engine attempts rerouting the conversation requests that do not find a CSR in the following cases:

• Busy CSRs: When all the available CSRs in the queue are handling conversations to their full capacity as configured in the Max concurrent conversations (from this queue) field
• CSR decline: When the CSR to whom the request is routed declines it

For rerouting a pending conversation request, the routing engine adds the request to the queue and waits for a specified period for reattempting. After the delay, the routing engine attempts to route the request again.

The rerouted requests take precedence over new incoming requests because the engine considers the initial queuing time for prioritization rather than the latest queuing time. However, these requests have lower priority than transferred conversations.

Escalation failure in chat conversations

Customers cannot escalate a chat request in the following scenarios cases:

These cases apply only to Pega Customer Service chat requests and not to the other conversation channels because those requests can be routed later when the CSRs are available.

• No CSRs available: When no CSR has logged into the selected queue, the routing engine sends the configured Agent not found message to the customer after selecting a queue.
• Maximum wait time exceeded: The routing engine periodically calculates the estimated wait time required to route the incoming or queued conversation requests based on the configured Wait time evaluation. Suppose the calculated wait time for the conversation request exceeds the configured maximum wait time. In that case, the routing engine sends the configured Agent not found message that is configured for the queue after the customer selects the queue.
• Off hours: The routing engine sends the configured Off-hours behavior message to customers when they attempt to live chat during the queue off hours.

For conversation from the unified messaging channels, the routing engine does not stop the customer from initiating a conversation during off-hours or when the maximum wait time is exceeded. Customers may send a message when no CSR is available. The routing engine can acknowledge receipt of the message, and then hold the messages in the queue until a CSR becomes available. At this point, the routing engine attempts to route these delayed messages to an available CSR.

Wait time calculation

The routing engine calculates the estimated wait time for a new request to be escalated to a CSR as follows:

((average chat handle time * ((number of active chats/2) + queued chats) / average concurrency rate) / number of active agents

The following are the key factors in calculating the expected wait time:

• The CSR pool's capacity at a specific time, which is the number of available CSRs in the queue multiplied by the concurrency allowed for each CSR
• The number of queued conversations ahead of the new request
• The number of active conversations that the CSRs are currently working on
• Average chat handle time for the queue

Calculating the estimated wait time based on a few conversations might provide skewed results. To avoid that, you can configure the minimum number of resolved interactions to evaluate before computing the estimated wait time for a new request. You can also configure the engine to consider only the resolved interactions within the last specified minutes.

A right balance of these two configurations results in the most optimal data set to utilize for computing the expected wait time.

When the above conditions are not satisfied, the routing engine does not calculate the expected wait-time. We instead fall back on the value configured under the Default wait-time setting.

For more information, see Configuring chat and messaging queues section in Queues.