Microsoft’s Omnichannel for Customer Service includes the ability to alert your agents when incoming conversations arrive or if someone transfers a conversation to them or someone just wants to consult them about a live conversation. These notifications are as you’d expect a standard feature of Omnichannel for Customer Service but there are quite a few options we can use to tailor how and when these notifications appear. In this post I will explore those options.

In this post I plan to explain the different types of notifications plus how you configure templates to adjust the content and timing of notifications. I might not cover literally every option! But I do hope to explain all of the key concepts and I will definitely explain the options I have commonly used.

A typical notification in Omnichannel for Customer Service is shown below. Notice that the agent commonly has an accept and reject button. Plus a timer counts down, if that timer reaches zero and the agent hasn’t accepted the conversation it would be automatically routed to another agent. Additionally the notification can include information about the chat, in mine for example I show the queue the conversation has been routed from.

Below you can see another notification, this time I have shown the notification generated when I route an entity to a agent. In this example the agent has a much shorter time to open the record. Additionally they get no reject button. Meaning if they don’t open the case it will still be allocated to them!

Hopefully you can see that we can therefore have different styles of notifications which additionally have different behaviours. This allows us to configure how agents interact with incoming conversations (and entities). Within Omnichannel for Customer Service each channel is linked to a workstream. And it is on this workstream that we define many of the key settings that dictate how notifications behave.

Tip:
Additionally we can define a notification that supervisors will see if a conversation sentiment dips below a threshold. (More on that later!!)

Workstream Settings

Below you can see my web chat work stream, each channel will have a workstream. Typically most channels have similar settings, although I will reference a few differences later in this post.

The work distribution section of the workstream has an influence on when we get notifications. As notifications will be displayed when the work distribution mode is set to “Push”. Notice that once a workstream has been created the distribution mode is fixed and can’t be changed.

An alternative distribution mode is “Pick”. In that mode instead of the agent being presented with a notification they would “just” pick the conversations (work items) from their of open items. To be honest I pretty much always use the “push” distribution mode. As typically conversations types such as web chat or Facebook messenger would require a rapid response from agents, therefore you’d want the conversations to be pushed to the agents.

I have experimented with the pick distribution mode for entity routing, when a case (for example) might be allocated to an agent but as it doesn’t need immediate attention they could pick as required. I say experimented as I now favour setting even these to be push mode!! I just make the length of time the notification is visible for quite short. The agent then knows the case has been allocated to them but can opt to “ignore” the case until they are ready to open it.

The allowed presences options is also useful. As we may wish to allocated work items and therefore trigger notifications when an agent is classed as “Available” or “Busy” (with capacity). Meaning if the agent sets their status to “Do Not Disturb” then new conversations would not be allocated to them. But there might be examples when regardless of the agents status you still want to assign work items. In my previous example of using entity routing to allocate cases to agents might be one instance when you wish to include things like “Do Not Disturb” in the allowed presences. As the work items will still be allocated and the agent will be expected to simply pick them up later.

In addition to the work distribution settings on the workstream we can define which templates to use for various types of notification. Most messaging channels like webchat, Facebook and Twitter have a similar set of notifications. When you first install Omnichannel for Customer Service a default set of notification templates will be applied. You might never need to change these! But it is worth understanding what they are and how you might want to tailor them.

I will cover a little more detail on what each template includes later in this post.

As you can see above we have separate templates for various scenarios ….

• Transfer – Triggered when one agent transfers a conversation to another agent.
• Incoming authenticated – Triggered when a new conversation begins for an authenticated chat. (Implying we know the contact!)
• Consult – Triggered when one agent reaches out to another agent. Maybe with a question about a conversation.
• Incoming unauthenticated – Triggers when a new conversation begins for an unauthenticated chat. (Commonly this might be the most common notification type for new conversation!)
• Supervisor assign – If a supervisor manually assigns a waiting conversation to an agent then this notification might be triggered.

Note: In many ways a supervisor assigned conversation is going to be similar to a typical incoming chat. Except, when a supervisor assigns a chat the agent’s capacity will be ignored. It might be that the supervisor has deliberately decided a particular conversation has had a long wait time and manually overrides any capacity constraints. Hence why the agent might need a prompt to see that a conversation has been assign directly by their supervisor rather than following the normal route for incoming messages.

I mentioned that most channels / workstreams have a common set of notification templates. Below you can see that entity routing has just the one template that is triggered when the entity is assigned to the operator. If you think about it, this makes complete sense! As with no “live” conversation we don’t need the same consult options and concepts of authenticated / unauthenticated conversations simply don’t apply.

Templates

So we have seen that each workstream can potentially be linked to several templates covering different conversation triggers. But what does a template include? And how might you wish to tailor it?

As already shown you can access the notification templates directly from the workstream. But you should be aware that you can also navigate to the notification option and amend any templates from there.

As an example I have shown one of my templates for web chat.

I have made some amendments to this template but it is based on the default which comes with Omnichannel for Customer Service. I opted to amend the default! You could (of course) decide to create a new custom template fi you’d prefer.

A few fields I have found useful to change include ….

Timeout (seconds) – this value dictates how long the agent has to accept the chat. If not accepted after this period the conversation might be automatically rejected.

Reject button – in some scenarios you might not want the agents to have the ability to reject incoming conversations. Maybe, for example, if the supervisor assigns the chat then you will not allow the agent to reject it.

Show desktop notification – I will cover this option in more detail later in this post. But here we can decide if desktop notifications will be shown. (Useful if the agent doesn’t have focus on their omnichannel dashboard!)

Notification fields – Here we list any fields the agent will see in the notification. Examples include the queue the chat came from or details of the case / customer etc.

Below you can see a list of the out of the box notification fields. Many of these fields might be more use in some circumstances than others! For example if I’m using entity routing to route a case than case priority might be really useful. Or when transferring a chat adding the sentiment might help the agent receiving the chat understand the “state” of the customer.

Below I have opened the case priority notification field. I have done this as an example! See the value field …. Notice how it contains an odata string which returns the prioritycode field from the case. I hope by viewing this you can appreciate that you could create custom notification fields. Say you have a bespoke “case type” field, you could create a “Case Type” notification field to show this if required!

By way of a comparison I have also shown my default CDS entity template. (I showed an example of this at the start of this post!) notice how I have a very small timeout value. Also I do not have a reject button. And we have also changed the text shown on the accept button, to “Open Item”.

Tip: This approach to CDS entities is why I probably favour sticking with the push method rather than setting my workstream distribution method to pick. As the agent will get a notification for just a few seconds. If they do nothing the notification will clear but the case will be in their work items anyway and they can pick it as and when required.

Windows Desktop Notifications

But what if your agents aren’t glued to their omnichannel agent dashboard? They might miss important notifications ….

This problem is resolved with the help of windows desktop notifications. As once enabled your agents will see them regardless of what application has focus on their windows desktop.

To enable desktop notifications you first need to set the “Show desktop notifications” option on the appropriate notification template . Below you can see that the options are “Never” or “When app is in background”. I wanted desktop notifications, so I set mine to “When app is in background” …

Once enabled, when your agent first loads their omnichannel for customer service apps their browser will prompt them to allow notifications (or not). They will need to allow them!

You can see below that is was distracted (aka reading the news in BBC new app) and a chat arrived. I still received a notification. As you’d expect, clicking “Accept” or “Reject”, will open the chat or reject it. Clicking on the text in the notification will give focus to my agent dashboard and I could then open the conversation from there.

Tip:
You do need to ensure that windows notifications are enabled! So if you aren’t seeing the notifications, check that notifications are enabled for your browser in the “Notifications & actions” area of your windows settings.

Supervisor Sentiment Notification

There is also a “special” type of notification that you can enable for supervisors, one I think could be really useful! You can generate an automatic notification for supervisors if a negative conversation is in progress. The supervisor could then decide to monitor that conversation.

You can see below that I have opted to give the supervisor a notification is a conversation becomes very negative. The supervisor can see which agent is involved in a negative conversation and can decide to monitor the conversation if required.

To enable this feature you first need to have sentiment analysis enabled and set the threshold for conversations. I set mine to only alert when the conversations were very negative. Maybe if I had generally happier customers I could have opted for a setting like “Slightly Negative” instead!

Once you have enabled the sentiment notifications for the supervisor, a system / default notification template will be created for sentiment alerts. Mine is shown below. As with other notifications, here you can control what information is shown to the supervisor, how long the notification lasts etc.

I appreciate that I have actually covered quite a lot of ground in this post! That just goes to show how flexible notifications within Microsoft’s Omnichannel for Customer Service can be. Whist the out of the box defaults maybe sufficient for some circumstances I think you may find that most implementations will involve at least some requirements to tweak these settings. Enjoy.