I am currently revising for the MB-230 exam. This exam is for Microsoft Dynamics 365 and covers all aspects of customer service. As I revise I plan to publish blog posts that collectively will become a complete revision guide for anyone embarking on the same journey as me. In this post I will begin to discuss Omnichannel for Customer Service.
You can see an extract from the current skills measured statement below. What we can immediately see is that Omnichannel for Customer Service covers a large section of the exam! And also that this topic includes numerous subjects for us to revise. I will attempt to cover as much information as possible in a collection of blog posts that should aid your understanding of Omnichannel. In this post I will concentrate on an overview of Omnichannel and I’ll expand on any topics raised in future posts.
My blog also includes many posts about Omnichannel for Customer Service. You might also benefit from reading at least some of those as they might dive deeper into specific topics.
What is Omnichannel?
I guess I should set the scene by explaining what Omnichannel is and why we might need it!
We live in a digital age where empowered customers can (and will) contact service-focused organisations in a multitude of ways. The customers will typically reach out using whatever communication method works best for them. And regardless of the channel selected by the customer the agent will need to have the customer’s details close at hand to be able to quickly and effectively handle queries.
Organizations therefore have to offer a variety of support channels including; phone, email, live chat, SMS, virtual agents, social channels and more. And regardless of the channel being used the agents will need consistent access to knowledge base articles, agent scripts and other productively tools to help them resolve the queries.
Additionally agents may need to juggle multiple customer conversations simultaneously. In my experience it has been common for one agent to be required to handle between 3 to 5 web chat conversations simultaneously. This can only be achieved when the applications they use support contextual sessions which enable them to seamlessly swap from conversation to conversation.
Microsoft’s Omnichannel for Customer service app can support multiple channels and has numerous features to help organizations provide first class service in this omnichannel / digital world.
In recent months Microsoft have made a massive push to make continuous improvements to their Omnichannel offering. It is therefore very likely that some of the concepts I show in these posts could evolve quite quickly. I encourage you to ensure your revision doesn’t rely purely on my posts but you also seek out additional information on the latest features. Plus Omnichannel is a large subject, so don’t assume I will have covered every last detail!
Customer Service Workspace and Omnichannel for Customer Service Apps
Microsoft provide two customer service apps which support a multi-session interface and can be used by agents to manage Omnichannel conversations.
The first of these is the “Omnichannel for Customer Service” app. This is their original multi-session app that shipped with Omnichannel for Customer service. You may therefore commonly notice it being used in any examples you see for Omnichannel.
We now also have the “Customer Service Workspace” app. In many respects this offers exactly the same agent experience as the original omnichannel app. In the Customer Service Workspace the default dashboard (typically) isn’t the agent dashboard we see in the Omnichannel for Customer Service app. But the agents can easily open that dashboard or the default can be changed.
I guess the key difference (in my opinion) is that you can opt to use the “Customer Service Workspace” app without enabling Omnichannel. Therefore maybe its usage could become wider than the original Omnichannel for Customer Service app.
I personally normally favour using the “Customer Service Workspace” app. But any of the agent or supervisor experiences I describe in these posts will work pretty much exactly the same in either application. (At this point in time I think your only “take-away” needs to be an understanding that we have two multi-session apps available!)
Regardless of which app you use there are several components to the agent experience you need to be aware of. I have shown a screen shot of a live conversation below. Then below the screen shot I will highlight the purpose of each part of the screen.
As agents accept the notifications from incoming conversations sessions will automatically open. They can swap from session to session by clicking on the session names in the left panel. Also notice that the agent always has access to their “Home session”. It is here that they will view any global tabs. Typically that will be their agent dashboard showing the status of conversations.
Agent can start sessions automatically by clicking on notifications agents. In addition they can also open cases (and other records) from their home dashboards by clicking the mouse whilst holding down shift.
Tip: If you find holding shift to start sessions “clicky” then checkout this blog post. As I describe how we can enable a simplified method of navigation. Also … I think I recently read that the second release wave in 2021 will enable this simplified navigation by default!
One – Session tabs
Inside each session we will have one or more session tabs. Each tab will include a Dynamics 365 form or other web resource. Administrators can actually enhance the session starts to open multiple tabs if required! Or holding “ctrl” when you click a link will open a new tab in the session. You can also use the “+” icon to open new tabs in the session. (Yes, the simplified navigation mentioned above does remove the need to hold “ctrl”.)It is these concepts of sessions and session tabs which give us the multi-session interface within our Omnichannel apps.
Two – Conversation panel
During conversations we also have a conversation panel. It is from this panel that the agent can swap messages with the customer or even other agents. Additional capabilities transferring the conversation to another agent. Plus quick replies can be used from the conversation panel, these are a great way to quickly and consistently send commonly used phrases.
Agents can also quickly take notes, access the knowledge base and even turn on real-time language translations from the conversation panel. Plus if enabled the agent can escalate a web chat into a voice or video call.
Importantly agents can also see a real-time analysis on the customer’s satisfaction level or sentiment. As I will describe in later posts the sentiment ranking is also visible to supervisors when they are monitoring ongoing conversations.
Three – Presence control
The agent’s presence is an important concept! If you have ever used Microsoft Teams you will already be familiar with the idea that each person can be green (available) or red (busy). We can also define custom presence values if the agent wants to flag they are on a break etc.
The agents presence will default and change from available to busy automatically as they start / end conversations. But in addition to this agents can manually change their presence as required.
Four – Customer summary
The customer summary tab or conversation tab if you prefer contains details of the incoming conversation. This is the “anchor tab” for the session. As you open customer records or create cases these will be linked to the conversation.
Also on this tab the agents can see the conversation summary control. It is here they can see all sorts of useful information about the conversation. Including any pre-chat survey responses, wait times, customer location, language and more.
Five – Productivity panel / agent scripts
The productivity panel can include three things. Smart assist, agent scripts and knowledge base. All of these are designed to help the agent research and resolve customer queries.
The smart assist panel uses AI to give suggestions on knowledge articles, similar cases and other suggestions which may be useful.
The agent scripts are guided processes to help the agent resolve queries. In their simplest form they give prompts to the agent to help them decide what messages to convey to the customer. But beyond that they can also trigger macros which can automate processes, such as opening a new case and much more.
Omnichannel Admin Center (and NOT Omnichannel Admin app)
As I am sure you can appreciate administrators have loads of configuration options connected with Omnichannel for Customer Service. Therefore we have an administration app called “Omnichannel admin center”. This is used to define the channels, routing rules and other settings that make up our Omnichannel solution. As I progress with these blog posts we will cover many options within the admin center
At this point I should mention the “Omnichannel Administration” app! Yes we have two admin apps at the moment. (Confusing I know!!) As mentioned earlier Microsoft have been continuously improving their Omnichannel capabilities …. When Omnichannel first launched all of the administration was completed in the “Omnichannel Administration” app. That app does still exist and does still operate.
BUT IMPORTANTLY. Once you have started to maintain settings in the newer “Omnichannel Admin Center” you can no longer maintain your channels in the older experience. Therefore in all of these blog posts I will be showing screen shots from the newer Omnichannel Admin Center. This does mean you may still find some information published which shows the old app. (My older blog posts for example!) In most cases the concepts from the old app can be applied in the new one. Often it is just the navigation which is different. But the new app will also include new features not present in the old app. (Intelligent machine learning for routing of cases being one of many examples!)
Channels / Workstreams / Queues
The admin center allows us to configure Omnichannel settings. So this might be a good point to introduce a few new concepts / terms.
Channels can be created. These can be for web chat or social channels such as Facebook or Twitter. Each channel is linked to a workstream. Workstreams are the key definition of how we want conversations on the associated channel to operate. The workstream will include a definition of the behaviours and user features applicable to the channel. For example, it will include a definition of the pre-conversation survey or enable certain features like conversation transcripts.
Workstreams can also include classification rules. These may include details of what skills we expect agents to have to be able to answer customer queries.
Next the workstream will include routing rules to define which conversations will be routed to which conversation queues. Queues in Omnichannel are pretty similar to other queues in Dynamics 365! In that we have a queue and it can be associated with a number of members. (or agents.)
Other settings on the workstream define the work distribution logic. For example, how much capacity of the agent will be consumed for each conversation on this workstream. Or when we are using skills based matching if an exact match is required or if a closest match logic can be applied.
I will no doubt return several times in future posts to explaining concepts connected with workstreams! As they are the core component in the definition of our Omnichannel behaviour.
As already mentioned … in both Omnichannel apps agents will use the Omnichannel Agent Dashboard. This is their starting point for managing conversations.
Generally speaking the agent will get a notification that a conversation has been assigned to them. They will accept that conversation and therefore trigger a session to open. Commonly they will complete the conversation and then exit the session. At least that will be a common process when we are talking about a web chat conversation!
Not all conversations will operate in the same way. Consider an SMS conversation … these tend to be long running. As customers will probably not give the instant responses we’d expect with a web chat. It that scenario it may be quite likely that the agent closed the session prior to the conversation ending. And then re-open the conversation later.
Another scenario is the pick distribution method. Often we will “send” the conversation directly to an agent with a notification. This is called the push distribution method. But we have another approach called “pick”. With the pick approach the conversation is routed to the queue but the agents would then manually pick the conversation when they are ready. I have used the pick approach when routing cases created from a web-portal to agents, as the cases didn’t need the same instance response as we’d expect with the push method.
These scenarios and more are where the agent dashboard comes into play. It contains three panels that automatically refresh every few seconds. (Although the agent can also click the “Refresh All” button to force a refresh if required.)
- My work items – this panel contains a list of all the conversations currently active with the agent. These maybe already open in sessions. But the agent may have closed the sessions. So they can use the “…” option on the conversation card to open a session when required.
- Open work items – This central panel will show any conversations (or records) which have been routed into a queue the agent is a member of. The items here are available for picking. When this happens the agent can use the “…” option to pick the conversation. Doing so would effectively assign them to the conversation and move it from the “Open work items” panel into the “My work items” panel.
- Closed work items – Recently completed work items will show in the closed work items panel. As conversations are closed in the “my work items” panel we will see their status changes to “wrap up”. And then they become completed as they progress into the closed work items area. This panel might be useful if an agent needs to review the details of a recently finished conversation.
Agent Presence / Capacity Concepts
Earlier I mentioned the concept of agent presence … and how this will change automatically as conversations are started. I also mentioned how conversations are routed in the workstream to queues.
Each queue contains a number of agents and the system needs to decide which agent to push the conversations to. (Assuming you are using the push distribution method!) This is when the concept of capacity can come into play.
Firstly the agent presence will be evaluated. As any agents who are off line or in a do not disturb mode would be excluded. (Actually the presences that are considered for routing can be tailored on your workstream!)
Next we will typically allocate the conversation to the agent who has the most capacity. Each agent’s system user record includes some additional fields specific to Omnichannel. You can see my record below! I have a capacity of 300. This means I can handle up to 300 “workstream conversation points” at one time. Each workstream has a capacity setting that will be applied to conversations arriving on that workstream. So, say I have a chat workstream and that has been set to 100 points. This would mean I could handle up to 3 chats concurrently as my capacity is 300. But say SMS conversations are rated at 50 points. Then I could handle up to 6 SMS conversations at once. And any combination …. So I could handle 4 SMS conversations and still complete one web chat. Etc etc.
It might also be worth noticing that our agents also get a default presence. This is actually really useful. As I often set my default presence to “Do not disturb”. Meaning when I first log into Omnichannel I will not start getting any notifications until I manually make myself available.
You can also see that within the Omnichannel tab you can see which conversation queues I’m a member of and also access my skills profile as well.
WOW that’s a lot of concepts for one blog post! I hope you are still with me. Future posts will build on these concepts and more to hopefully give you an overview of the key information you’ll need to be aware of for your MB 230 exam. Enjoy.