Omnichannel for Customer Service – Grab / Pick Chats

With Microsoft’s Omnichannel for Customer Service it will be common to use a push method to route your chats to the “best” agent . An alternative method of working is to show all agents all chats and someone “grab” (or cherry pick) their next chat. In this post I will look at how we configure this “pick” method for web chats.

Spoiler alert … I admit I prefer the more typical push approach. As I have more control over who will be presented with which chat. And I also hopefully distribute chats in an approach that will help ensure all agents receive a similar workload.

But if you’d like to have a cherry picking approach then it is possible. An approach which I guess would work well with smaller number of agents. For example, maybe you have just one queue of say 10 agents. And all the agents can handle all incoming chats.

To configure this approach first of all you will need a work stream that has a distribution method of pick. If you have a push work stream already defined for your web chats you’d need to create a new one. (As once with work stream is saved you cannot change the distribution mode.)

Below you can see my newly created work stream.

Incidentally, don’t forget that after you save your work stream you will probably need to add routing logic to route to an appropriate queue. Or simply do what I tried! As leaving the routing blank will simply route to your default messaging queue.

Next you will need a chat channel to use this work stream. You can’t edit the work stream on an existing chat channel! So again you may need to create a new record.

See below that I have created a new chat channel. And I selected my “pick work stream” as the work stream for this channel.

On save of the channel a widget code snippet will be automatically created. If you have just created a new channel then this will be different from your previous snippet. Meaning this snippet will need to be updated in your Microsoft Portal or whatever website you are using for chats. In my example I was “just” using a Microsoft portal, so I simply needed to update the “Chat Widget Code” content snippet in the settings of my portal. You can see below how I have changed this in my portal management app.

So now I was ready to test my changes. Meaning it was time for a cup of coffee … as changes in Omnichannel take up to 15 minutes to apply!

Now when a chat arrives the chat message will show in the “Open work items” area of the agent’s dashboard. Any agent seeing this can select the “Assign to me” option. Assuming the assign is successful the chat will open and they can engage with the customer.

Once one agent has opened the conversation it will disappear from the open work items of the other agents. (When their dashboard refreshes.)

If two agents do happen to try and open the chat at the same time. Only one agent will actually open the chat. The other will get a message that their pick failed.

So what do I think of this approach!

I do see some benefits in this simple approach. And as I explained in my introduction maybe there are some specific examples when it will work well.

But honestly for a fast paced chat environment I have some reservations. Meaning I much prefer the push option. But if you want to use a pick approach then this does work.

My reservations are these;

  1. We don’t get any notifications on with this approach. Meaning we are reliant on one of the agents seeing and picking the chat.
  2. The dashboard does automatically refresh every few minutes … but whilst waiting for this refresh to happen a customer could be waiting for a chat to start. When a push notification may have prompted an agent to begin the conversation sooner.
  3. Whilst waiting for my dashboard to refresh I could be looking at a chat which another agent has already picked. This won’t cause any problems but agents may get frustrated if they frequently try to pick a chat that someone else has already grabbed.

Having voiced these reservations about the pick approach when applied to web chat, I do see that it might be useful on “slower” moving channels. For example, SMS. Twitter or entity routing. As when a less instant response is needed maybe having a list of open items and the agents cherry picking their next work item could be very useful.

The positive here is we have choices! You might want to experiment with a push and pick approach to see which works best for you. Enjoy.

Leave a Reply

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

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

Facebook photo

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

Connecting to %s