Headshot of Brandon Van Galder next to text that says, "Automate This! — Optimize Omni-Channel Waterfall Routing."

Automate This! — Optimize Omni-Channel Waterfall Routing

By

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by #AwesomeAdmin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, see how Brandon Van Galder uses an Omni-Channel flow to route and re-route incoming chats to multiple queues based on agent availability.


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.

Queue named All Chat supporting the Chat Transcript object with Tier 1, 2, and 3 support agents assigned.

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).

Queue named Tier 2 supporting the Chat Transcript object with Tier 2 support agents assigned.

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’.

Presence Configuration with Update Status on Decline and Update Status on Push Timeout set 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.

Omni-Channel flow diagram showing multiple paths for chat routing with elements numbered 1, 2, 3, 4, 5, and 6.

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.

Decision element with outcomes for Customer, Partner, and default.

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

  1. 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.
  2. 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).

Check Availability for Routing element set up to look at Chat Queue named Tier 1 with the outputs for number of online agents and queued work.

  1. 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).

Get Records element looking for Agent Work records filtered for Tier 1 and Opened status.

  1. 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.

Decision element for Route Work to Tier 1 if formula equals True.

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.

Route Work element set for routing current record to Tier 1 Chat 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.

Diagram showing the process for how chats get routed based on Agent Work status.

Agent Work!

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

Record-triggered flow showing a Get Records element and element calling a subflow.

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

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

SUBSCRIBE TODAY
Increase productivity and create starter flows fast with Einstein for Flow

Increase Productivity by Creating Starter Flows Fast Using Einstein for Flow | Automate This!

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by Awesome Admin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, learn how Eduardo Guzman enhanced productivity and […]

READ MORE
How I Created a Solution to Test Scheduled Flows Easier During UAT

How I Created a Solution to Test Scheduled Flows Easier During UAT | Automate This!

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by Awesome Admin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, let’s see how Nancy Brown created a […]

READ MORE