Omnichannel for Customer Service – Routing Diagnostics

I have recently started using Microsoft’s “Omnichannel Admin Center” app to configure Dynamics 365 Omnichannel for Customer Service. This replaces our previous app to administer Omnichannel for Customer Service. The new app contains many features connected with Unified Routing. Some I am still experimenting with! But one feature I have already used to great effect is the new routing diagnostics option. I will explain how in this post.

A key concept with Omnichannel is the idea that we will need to route the right conversations to the right agents. This starts off as a simple theory but in the real-world can quickly become very complex as you add more channels, queues and complexities such as skills based routing and more. This is where the new diagnostics option comes into play to help you understand what has and hasn’t happened as a result of your routing configuration.

For example, I recently wanted to route cases records to my agents. This was simple enough but I needed to only route high priority cases and I wanted to ensure the correct queue was used and for good measure I also routed based on agent skills. This was a reasonably complex requirement but actually quite typical of those real-world scenarios mentioned above.

The “record routing” options in the new style admin center have changed slightly so as I created my routing config my cases didn’t route as I expected. (All because of user errors on my part!) But this turned into my first chance to use the new routing diagnostics option.

The diagnostics option is connected with Unified routing and can be found in two places! Firstly you will find it in the Omnichannel as shown below. But you can also find it in the Service Management area of the customer service hub.

Initially the diagnostics will not be running, so your first task maybe to turn them on. Once that has been done whenever you try to route a conversation or record to one of your agents a record will be created in the diagnostics view.

For example, below you can see that I have routed a customer conversation on my portal. In this example the chat wasn’t routed directly to a human as from the chat widget in question I routed to my BOT instead.

The diagnostics let me see that a conversation was started. The status of “agent assignment – completed” indicates that the routing process completed and the conversation was assigned to an agent. (In this case a virtual agent!) I can also see which workstream was used and which queue the conversation ended up on. As I mentioned at the start just knowing your workstream and queue sounds simple but with many active workstreams and queues just understanding which conversations ended up on which queues is essential.

Lets return to my initial issue of routing case records. As I was setting up my workstream and routing rules I hit a few issues!

My actual results are shown below. You can see that it took me five attempts to get my routing exactly right.

In my first two tests I hadn’t correctly defined which records I wanted to route. The “Intake rules” were completing but the result of those didn’t route my case to a workstream or queue. My third attempt improved as my case was routed to my case workstream but it ended up on my default queue. Technically this had worked but wasn’t the result I wanted.

Test 4 was user error. Whatever I did to improve my routing was a mistake as it went back to not trying to route my case! But with test 5 you can see that I finally got things right and my case routed my correct workstream and queue.

So just having this high-level information of how far the routing got and which workstream / queue my case ended up on really helped me see the mistakes I’d made.

But there’s more …. Much more!

Below you can see that I have opened one of the diagnostics records created by my tests. Here I can see much more useful information. This data will show you exactly what has happened and should be really valuable in identifying any issues.

You can see that I have a number of “tabs” which explain the details of what happened at each stage in the routing process. I also have a summary tab which actually might show you most of the information needed!

When “something” is routed several stages are applied on order. Depending on your routing setup some or all of these may apply. The stages are;

  1. Intake – intake checks any conditions and routes your item to a workstream.
  2. Classification – you may use a ruleset to classify how the item is to be routed. In my example I classified items based on skill levels.
  3. Route to queue – next the ruleset will route your item to a queue
  4. Prioritization – selecting an agent from the queue has a prioritization ruleset you will see which rule set was used here. (Note: I just used a simple method of routing based on agent capacity, so this stage wasn’t needed. But prioritization might be done on a first in first out basis or maybe it could be based on created on date or maybe my cases could have been prioritised based on their SLA.)
  5. Assignment selection – As I was always routing based on capacity I didn’t need this stage. But I could have conditionally assigned to agents based on several other methods including a “round robin”, “capacity”, “proficiency” and more.
  6. Assignment – finally an agent is assigned based on the selected assignment method. (Notice mine is based on capacity!)

I guess our aim is to ultimately end up with the assignment stage completing! Along the way the routing could stop or you could end up diverting the item to an incorrect queue etc. (As I did!)

When viewing the summary if you identify that any stage did not work as expected you can open a tab specific to that stage to see exactly what rule was applied. For example, below you can see that in my intake I only route cases that have a high priority. One of my many initial mistakes was I’d got this condition wrong so my cases weren’t being routed to the next stage as expected. The diagnostic tool allowed me to see exactly what was happening as cases were created and I quickly managed to fix this condition.

Hopefully you agree that having this diagnostics option to understand how you Omnichannel routing (Unified routing) is operating is an essential tool. I am already wondering how I previously configured my routing without such a tool!

You can read the Microsoft documentation about the diagnostics for unified routing here. Enjoy!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s