Automate This! — Optimize Omni-Channel Waterfall Routing

Business problem

Initial chat setup didn’t allow for prioritized routing

We have three places chats can come in from: the main web page, the User Community, and the Partner Portal.

When chats come in from the web page or the User Community, they currently get routed to a queue that contains Tier 1 agents. However, chats are often missed at specific times of the day (for example, during the Tier 1 agent meeting). We would like the routing prioritized to Tier 1 > Tier 2 > Tier 3.

When chats come in from the Partner Portal, chats route to a queue with Tier 2 agents and Tier 3 agents. We would like the routing prioritized to Tier 2 > Tier 3.

Note: This work was completed at my prior place of employment, Scale Computing. Shout out to Kellie and Rebecca for all their help on this issue.

The first solution

Use queues, presence configuration, and an Omni-Channel flow

We created a parent queue (All Chats Queue) so the chat buttons recognize when agents from any tier are online and available to accept chats. Along with creating the queue, we added all agents as members of this queue.

We created queues for each tier to route chats to (Tier 1, Tier 2, Tier 3) to replace the current queues that were used to allow for a smooth transition to the waterfall method. Again, we added each agent as a member to the specific queue aligned with their role (Tier 1, Tier 2, Tier 3).

In Presence Configurations for Chat - Standard Agent (all agents assigned to this), we set Update Status on Push Time-Out to ‘Busy’ and Update Status on Decline to ‘Busy’.

Next, we created an Omni-Channel flow to route chats to appropriate queues based on where they came from according to our specific business requirements.

After the assignment of the recordId variable and getting the name of the chat button the chat originated from in the first two elements of the flow, we created the flow following these steps.

1. We used a Decision element to determine which path to send the chat down first (Customer Service to Tier 1 or Partner to Tier 2) to meet our business use case.

The following elements are used multiple times in the Omni-Channel flow, once for each different queue we could potentially route chats to.

2. In order to follow best practices, we used a Get Records element named ‘Get Tier 1 Queue’ to get the Tier 1 Queue ID for element #4 by looking for a specific Developer Name and Type = Queue.
3. Using the Check Availability for Routing action, we checked to see if any agents are in the specific queue (will show agents with no chats all the way to full capacity as available).

4. Then, using a Get Records element, we ‘Get Tier 1 Agent Work’ to find out how many chats are being worked on by Tier 1 agents (Status = Opened). It will be assigned to a variable in the next element (varT1Count).

5. We then used a Decision element with a formula to determine if there’s any availability in Tier 1 for chats to be routed there. The formula we used is based on each agent being able to receive two chats. If the formula = True, send to #6, and if False, send to the next tier for evaluation.

Here’s the formula we used for a boolean data type: ({!Tier_1_Availability.onlineAgentsCount}*2)>{!varT1Count}

Example: If there are two Tier 1 agents and three chats being worked on in Tier 1, the formula would calculate as:
(2 x 2) > 3 = True

If there are two Tier 1 agents and four chats being worked on in Tier 1, the formula would calculate as:
(2 x 2) > 4 = False

          6. Next, we used an Action element called ‘Route Work’ to route chats to the Tier 1 Queue.

At this point, chats are now routed to the correct queue upon creation, but if an agent declines or times out, they would stay in the same queue (if agents are available) and potentially cancel out (if no agents are available).

The second solution

Re-route the chat if declined, timed out, or cancelled

After a few unsuccessful attempts to re-route using Chat Transcript Events (initially worked but found out these could take up to 24 hours to be created) and then learning about Pending Service Routings (never worked with this!), we found the answer in this Help article.

Agent Work!

We used a record-triggered flow to re-route chats through the Chat Waterfall flow again.

This flow is triggered when on the Agent Work object whenever the Status = Declined, Unavailable, or DeclineOnPushTimeout. The functionality of rerouting on Decline and Timeout stopped working but still works on cancelled (if agent is disconnected or updates their Presence Status to ‘Busy’ or ‘Offline’).

When triggered, a Get Records element is used to look up the related Chat Transcript (Work Item ID = Chat Transcript ID in our use case). Lastly, we called the Chat Waterfall flow (using a subflow action) with the Chat Transcript ID sent as the input into a variable.

Resources

• Salesforce Help: Advanced Routing With Omni-Channel Flows
• Salesforce Help: Make Smarter Routing Decisions by Checking Agent Availability
• Salesforce Help: Route Work Items to Queues
• Salesforce Help: Assign an Omni-Channel Flow to a Chat Button
• Trailhead: Enable Digital Experiences and Chat Agent
• Salesforce Help: Understand the Details of the Routing Lifecycle

Want to see more good stuff? Subscribe to our channel!