Category: Omnichannel

Omnichannel & LogMeIn

Overview

Many people in the IT scene will know of LogMeIn (https://www.logmein.com/), or LMI for short. For as long as I can remember (which means going back almost 2 decades!) they’ve been one of the main remote access solutions. With their product range, it was possible to leave your computer at home, travel abroad, and easily log into it from practically any computer anywhere.

It’s also a great product for IT professionals. Being able to deliver customer support through remote sessions, manage identity solutions, etc. The number of products over the years has grown, and been quite pleasing to watch:

Of course, LogMeIn Free (a great starter product for personal usage) was removed some years back, which to this I still believe is a great pity. Obviously the company decided to focus on the more enterprise side of things, which I can understand as a business.

So, why am I now writing about them? Quite simple, actually. LogMeIn are one of the providers that are working with Microsoft to provide Co-Browse solutions for Omnichannel! It’s a very new piece of functionality that’s been launched in the Dynamics 365 product, and there aren’t many providers out there that have integration points to it.

What is Co-Browse?

It’s important to understand what co-browsing is, and some useful stats:

“Co-browsing” refers to the ability to have a service provider & customer jointly navigate an application in real time through the web.

Co-browsing: The Gateway to Happy Customers & Better Financial Results, 2015

So co-browsing is useful. But just how useful can it actually be? Well, apparently it can be VITAL:

Co-browse has the potential to bridge the gap between human & AI-driven customer interaction, & to enable organisations to differentiate their customer service.

By 2022, co-browsing will be used in 2% of customer service interactions, up from 0.1% in 2017 (2000% growth).

Gartner 2017: How Co-browsing Can Differentiate Your Customer Service

LogMeIn has had their Rescue offering available on the general market for a while as a standalone product (alongside the rest of their offerings). They’ve now build it out into a new standalone product called Rescue Live Guide, and provided an integration into Omnichannel for Dynamics 365. Customers obviously need to have licenses for the product, but with these, they now have the ability to co-browse during support sessions. Not only can they see what’s going on, but they can also interact with the customer browser itself, providing an even better support experience.

So, let’s go ahead and take a look at how to set it up, the experience itself, and my thoughts on things.

Setup

When I first started testing out the LogMeIn offering, I had to go through a manual install process. This was due to the product just being released (in May 2020), but wasn’t actually that difficult to carry out.

However, they were in the process of switching over to an automatic installation through AppSource, as most of the other apps have. It’s great to be able to see that this has gone live, and is now available for users – it really does make the install that much easier!

Clicking ‘Get It Now’ takes you through the usual route of installing a solution from AppSource: selecting the environment, confirming the installation, etc. After around 5 minutes, I can now see the following:

Once it’s installed, we’ll need to set it as the co-browse provider for the channel that we’re wanting it for. To do this, open the chat record, go to Conversation Options, and select it there:

We’ll also need to put in two records for the LogMeIn co-browse configuration:

Finally, there’s a script block that needs to be added to the webpage where the chat widget is located. This enables the LogMeIn co-browsing ability from the customer side. It can be added right under the chat widget code itself; in the fullness of time, this may be able to be auto-generated as part of the chat widget code, but it’s not at the moment (this is dependent on Microsoft being able to offer it):

Right – setup all done, but before we see it in action, let’s take a quick look at the Rescue Live Guide admin console side of things.

Rescue Live Guide Admin Console

Although the functionality is within Omnichannel for Dynamics 365, administering agent licenses and groups takes places within the Rescue Live Guide admin console at https://console.logmeinrescue.com/admin. As companies will need to have Rescue Live Guide licenses, they would usually be familiar with this.

There’s the ability to create new users or groups, and manage them as well:

It’s also possible to set the names that are used for the agent & customer. These can be either the actual name of the agent, or instead potentially a job role/title:

I’m not going to go further into the admin functionality here – documentation can be found on the Rescue Live Guide site around this. Let’s instead take a look at the experience within Omnichannel, which after all is what we’re here to see!

Agent Experience

So how does this actually work, in practise? Well, from the customer side, they start a chat like they would usually do. When the agent responds, they’re given an option for ‘Live Guide’:

When the agent clicks on this, two things happen:

  1. Firstly, there’s a URL that’s posted in the chat. This contains a link for the customer to click, with an auto-generated ID number
  2. The agent is taken to the LogMeIn Rescue site page in a new tab.

Note: At the moment, the agent will have to sign in manually. LogMeIn have told me that their roadmap includes Single Sign On, so that after the initial setup they’ll be signed in automatically, and not have to perform this step in the future.

Once logged in, the agent will see that the session is ready, & waiting for the customer to connect to it. Once the customer has clicked the URL provided in the chat, it will open the Rescue Live Guide session, and authorise the agent to co-browse with them. They’ll then see the following prompt. This tells them that the session is connected to the agent, and that they can begin:

Once the customer has accepted to start browsing together with the agent, they get some small extra items appearing on their screen:

  • They can see that there is indeed a shared browsing session happening
  • They can also see where the agent’s mouse cursor is pointing to (by default, without the agent actually doing anything)

It’s important to note that that the co-browse session is taking place within the specific browser (tab) that is open. Therefore if the user navigates away, the session is paused until they navigate back to it.

On the agent’s side, they can view the customers browser. They can only see what’s happening in the actual tab that’s open for the co-browse session (see below for some more information around this though). It’s quite similar to the customer’s side, though has some LogMeIn features available. Well, obviously it’s similar to the customer – the agent is seeing the customer’s browser window!

They can of course still access the Omnichannel chat itself, and send information through that as well if they wish to.

Just as the customer can see the agent’s mouse position, the agent can see the customer’s mouse position. There are also gesture indicators so that each person can see what the other clicks etc as well, which can be really helpful when walking through a process.

The functionality currently available to the agents covers scrolling (within the page), highlighting, drawing and ‘virtual tabs’. As shown in the image above, the agent is able to highlight text/images, which will then be displayed as being highlighted to the customer. Agents are also able to enter text into text fields, click on buttons, and interact with the native webpage functionality.

Note: The Rescue Live Guide admin centre provides granular controls around these, so that customers can allow agents certain rights, rather than allow them to do everything.

The agent is also able to ‘draw’ on the webpage to be able to point something out, highlight a part of the page, etc.

Note: These annotations will disappear once the customer or agent starts scrolling up/down the page again.

As I’ve mentioned above, the session is taking place within a single browser tab. If the user nagivates away (to a different tab), the session is paused. The agent isn’t able to see any other tabs. So what happens if we do indeed need to open a new tab for something?

Well, there’s a really nice feature that the agent is able to use for this. It’s sort of a ‘virtual tab’ within the browser tab. Sounds interesting!

The customer is able to see this, and can navigate between the tabs. They’re now also able to open a new virtual tab themselves (which is an update to the functionality – originally they weren’t able to, and had to request the agent to do it).

Customer view of the support session

If the customer wants to pause or stop the session, the user simply has to click the ‘Stop’ button in the bottom left. They’ll then be presented with the following screen:

Whilst the session is paused, the customer can continue to use their machine as normal, but the agent won’t be able to see what’s going on. Only if the customer allows the session to resume by clicking ‘Continue Browsing’ will the agent be able to see the customer’s browser once again.

Alternatively, the agent can end the support session themselves, and the customer will be notified about this.

Security

I’m not going to dwell too much on security, as there’s a great document available at https://logmeincdn.azureedge.net/legal/gdpr-v2/Rescue_Live_Guide_SPOC_2020.pdf which goes into quite some detail.

Suffice it to say that LogMeIn have been a market leader for many years in this sector, and I’m happy that sessions through their products are adequately encrypted & protected.

Other functionality

Apart from the above, which is obviously the core of the product, there’s other functionality that’s possible to enable through the LogMeIn Rescue console:

  • Session recordings. It’s possible to record these for playback, which is then available from the LogMeIn portal. All recordings are carried out from the agent’s viewpoint, not the customers – there is therefore no issue that sensitive information from the customers side could be seen
  • Data masking. It’s possible to use data masking to hide sensitive information. At the moment the setup for this is a very manual process, so I’m not going to go into how to set it up it here. Having played with it a little, it’s really quite useful. Agents can’t see sensitive information on their screen, and if a customer needs to enter/update information, the session pauses whilst this is being done. However I understand that part of the LogMeIn roadmap for the near future is to make the setup process much more user friendly. When this is released & available, I’m planning to do a post on this
  • Reporting happens through the LogMeIn portal (see my thoughts below on this). It looks nice, and can be downloaded as a CSV file. Again, the functionality of this is going to be expanded in the near future.
Reporting in the LogMeIn website console

My thoughts

Having gone through testing out the product, I think that LogMeIn has brought a really great product of theirs into the Omnichannel experience. I used to use their products regularly (I ran an IT MSP some years back, in which we used LogMeIn products as well), and always found that they behaved well.

Now having the ability for agents to not only see, but also interact with the customer browsing experience really does take things to the next level. Audio and/or video support is great of course, but sometimes being able to see what the customer is seeing in their browser results in a much quicker resolution. This of course results in happy customers, which is what we’re striving to achieve!

As I’ve said above, I’ve used LogMeIn over the years, and always found their products to be pretty much amazing. With Rescue Live Guide, there are several differentiators that the solution brings to market:

  • For the standalone solution of Rescue Live Guide dedicated web resources aren’t needed. It’s an easy solution to set up, and for the customer to engage with – all it requires is a URL to be provided to them to get the session going. Obviously, as mentioned above, there is some slight coding needed for the Omnichannel integration, but this is really minor. Any company having Omnichannel installed/configured will already have power users/admin familiar with what’s needed for this, so it’s a very small additional step
  • It’s possible to co-browse on any website that the customer wants to, not just a single specific website. Once the co-browse session is active, the customer can change to any other website, as long as they do so within the co-browse session tab. Most other co-browse solutions out there can’t do this, so this is a really strong point in favour of this solution.
  • The data masking is really cool, and for most customers, will be a ‘must have’ rather than ‘nice to have’. I’m looking forward to when the setup for this is updated to be more business-user friendly, and will then do a separate blog post around it, together with a video!

A few things that I think would be nice to have:

  • The agent is already able to draw on a webpage during the co-browse session, and select different colours for this. It would be great if the agent could also type text in to display on the screen (not in a specific field) in colour. Sometimes being able to see an example written in front of you (without it going into the actual field) can be quite handy.
  • Being able to transfer the co-browse session to another agent. This could be either another Omnichannel agent, or a separate specialist team. It is of course possible to transfer the chat session to another Omnichannel agent, but then they’d have to start the whole co-browse session again (with a new PIN, etc)
  • Reporting (for the most part) all occurs in LogMeIn at the moment, as Dynamics 365 only has very limited reporting on this natively. However I understand that this is due to change at some point this year, with the ability to report properly on it within Dynamics 365 itself.

At the point when new items do get released, I’ll be aiming to do a review of them, and add to the knowledge around the product.

So, with all of that, how do you think this could best help you & your customers? Please comment below – I’d love to hear!

New functionality for Routing Rules

Within Omnichannel, we have the ability to route conversations based on different factors. At this point in time, there’s Skill-Based routing (covered at https://thecrm.ninja/omnichannel-for-dynamics-365-skills-part-ii/), and Workstream routing (covered at https://thecrm.ninja/omnichannel-pre-survey-responses-routing/).

Routing is used to send customer interactions to specific queues, in order to have them handled by the agents best suited. This could be based on the language that the customer is using, the query that the customer has (involving pre-chat survey questions), etc.

The way that this is done (included in the previous articles) is by selecting the details that we want to use. This could be the contact (when recognised as a record in the system), pre-chat survey responses, or several other options.

However, to date we’ve only been able to use fields/variables from the chat session itself. It’s not been possible to connect to other data that we’re holding within the system, and use that for routing. We’ve only been able to use items that are directly linked to the conversation:

  • Account
  • Case
  • Contact
  • Context Variable
  • Live Chat Context

So if we had identified the customer as existing in the system already, we weren’t able to query related records to them, eg accounts etc. That’s all changed now though – we are now able to do this!

End of term celebration | News Post Page

Let’s see an example of this. We have a customer, and we know from within Dynamics 365 that his company is a VERY large customer of ours. They spend a great deal on our products every year, and as a result, we want to route any interactions with them to a special VIP queue. Previously we were unable to do this, unless we somehow set a flag on the contact record to display this.

What we’re now able to do is go and get values from the linked account record, and use these as the routing variables within the workstream:

We can add multiple rows here, all connecting different parts of the data.

Note: The only caveat is that the entity needs to be linked to one of the Omnichannel items (which are listed above). We can’t daisy-chain non-related entities, eg Contact-Account-Invoices

These can obviously be put together in groups, to satisfy more complicated conditions, using AND/OR conditions. With this, we can therefore address very specific scenarios, tying together conditions across multiple entities.

Even nicer, we’re not restricted by the relationship type. We therefore can select an entity that’s related to the primary Omnichannel entities as:

  • One to Many
  • Many to One
  • Many to Many

With this being in place, we’re now really able to ‘fine tune’ how we can route customer interactions, and set up specific places for them to be directed to. Through this, we can identify & serve identified sectors of our customers in different ways, as we feel is best appropriate.

This is also applicable to skill attachment routing, where the same level of functionality is provided.

So with this in mind, how would YOU think that you would go ahead and use this? Leave a note in the comments below!

Omnichannel Macros

I’ve previously touched on macros in https://thecrm.ninja/omnichannel-productivity-tools/, but with some new functionality that’s now come out, I thought it would be quite interesting to dive deeper in them. By doing do, we can see how they work, the functionality that they offer, and some really cool & interesting scenarios!

Let’s have a quick reminder of what macros are all about (for those who don’t know, yet):

Macros allow customer service agents to carry out repetitive tasks that can span multiple entities. Eg opening forms (model-driven apps), pre-populating data into the form, etc. Through this, not only are there less manual tasks/steps to carry out, there’s now the ability to carry out the same tasks, without worrying about a step being missed, or the wrong data copied in, etc.

With that in mind, let’s see what there is for macros in Omnichannel. As a default, there were always the following 3 pre-defined automation actions:

With these, we’re able to do things like:

  • Opening a form to create a new record. This could be used to create a new contact automatically
  • Opening an existing record. This could be used to open an existing contact (based on pre-survey questions, such as email address etc
  • Searching the Knowledge Base using specified keywords/phrases
  • Opening an email form with a pre-defined templated
  • Linking records together

There’s now a new option available:

Hmm. This looks interesting. What happens when we select it?

We get a condition block! Clicking ‘Add an action’ will allow us to then add either one of the pre-defined automation actions, or another Control/Condition block.

OK – so you’re now thinking that I’m getting over excited about this. But hold on – let me explain further why I’m really liking this.

So when using Power Automate, frequently I’ll use condition blocks to check/satisfy things (it’s obviously available in Logic Apps as well, but I have minimal experience of those to date). Some of them can get quite advanced, but it comes in useful. However for Omnichannel macros to date, it’s not been possible to do this. We’ve been limited to just a few options, without being able to specify branching criteria based on variables.

Now we’re (finally) able to do this. The Condition field works in the same way as Power Automate does, with being able to string multiple statements together, and have actions that result from them. We’re also able to use slugs in them, to populate variables & use customer-entered data.

Let’s see an example of this. We have a customer who’s opening an Omnichannel chat session. They’ve filled in the pre-survey questions, in which we’ve asked for the following pieces of information:

  • First Name (required)
  • Last Name (required)
  • Email Address (required)
  • Company Name

With the condition check in place, we can either create just a contact record (if the customer didn’t fill in the company name field), or we can create both account & contact records, and link the two together. We could also check if the customer already exists as a contact, and then not need to create any records for them.

This means that there will be much less manual work for the agent to carry out, as they won’t have to manually create all of these records.

We’re able to string these together in ‘multi’ step scenarios, to allow things to flow on from each other:

There are also other options available to use, such as the ability to clone, and the ability to open a new application tab. I’ve covered application tabs at https://thecrm.ninja/omnichannel-application-tabs/, so we can see how helpful this could actually be. We wouldn’t need to automatically open a specific system for all customers contacting us; instead we’re able to selectively open things based on the actual customer. This makes for a much cleaner & better agent experience, in my opinion.

In summary, this is a really helpful & useful feature that’s been added, bringing even better functionality to macros. We’ve been able to do these sorts of things elsewhere to date, and being able to do it here now as well is great. All I can say is that I’m wondering what else we could do…perhaps kick off a Power Automate Flow as well? We’ll have to wait and see 🙂

Omnichannel & Application Tabs

One of the really nice things about the Omnichannel Agent experience is that it uses tabs. The conversation itself is in the left side of the screen, with the Customer Summary open in the right side of the screen. However this isn’t fixed into place – it’s possible to open additional tabs next tot he Customer Summary tab, and navigate to various places in the system.

This allows agents to easily look up additional information on records such as contacts & cases, as well as other places.

Agents are therefore able to quickly flip between different system records, getting the information that they may need to satisfy the customer interaction.

So that’s great. Clicking the + icon on the tab allows new tabs to be opened, and the agent can select which record type they’d like to see:

The system allows movement between these if they disappear off the screen with arrow buttons being available:

So all of this is really good, and is provided as system default behaviour, without any customisation or configuration being needed to be done.

So let’s now think about several other types of scenarios, and see what could be done to enable them:

  • You want the agent to see a dashboard showing how long the production line is currently taking with different order types
  • You want to be able to look up an item in another stock system
  • You want to carry out a custom search in your distributor network

All of the above items (and many more) are things that aren’t native within Dynamics 365. It’s therefore not possible to display this with native system functionality…or is it?

Well, it is! Omnichannel has something called ‘Application Tab Templates’. These allow you to specify custom tabs to open when a chat start. With these, you’re able to point to any web-based resource, even if it’s not within Dynamics 365!

Note: It’s not possible to point to a bespoke desktop application using Application Tab Templates. The resource that you’re wanting to point to needs to be web-based. This is one of the main differentiators between Omnichannel & Unified Service Desk – USD allows you to point to a desktop/server application within the window.

Setting up a new Application Tab Template is not too difficult, thankfully:

We’re able to select what the Application Type should be. There are various options here, including web resources, ‘third party’ websites, entity lists, etc:

When we save the record, we can then input the necessary parameters for that type. These parameters are system-defined, so we have to work within these, and can’t add any additional ones (at this point in time). We can also use values from pre-chat surveys based on information that the customer has provided before the chat starts. Imagine being an agent with a new conversation, and you already have the entire purchase history for them open, or their billing records!

Note: For a full listing of the parameters available for each application type, please refer to https://docs.microsoft.com/en-us/dynamics365/omnichannel/administrator/application-tab-templates#application-types

Once this has been created, the next step is to associate it with a session template. Session templates govern the following items:

  • The behaviour of the chat by default (Docked, Minimized or Hidden
  • The name of the session
  • The application tab/s that open (you can add as many as you want to)
  • The agent scripts that are available to be used.

To do this, open the relevant session template, and then add the application tab/s to it that you want to appear:

Save & close the session template record, and refresh the agent interface. When a new chat session comes in, Hey Presto!

Using the ability to have different chat widgets, it’s possible to customise each one in a different way. So for example:

  • The Sales team could have the distributor system open, to know how long it’ll take to fulfil an order
  • The Billing team could have their invoice/finance system open, to have the customer billing history
  • The Motorbike Servicing team could have their system which tracks all work done on your motorbike open, to see the entire service history

It’s really up to you how you choose to best make use of this. I feel it’s really quite helpful, and will cut down on the time that agents need to spend to pull up different pieces of information to help the customer.

How do you think you would use it in your company? Comment below to share 🙂

Omnichannel & Sentiment Analysis (II)

I’ve previously touched upon sentiment analysis within Omnichannel in several articles (https://thecrm.ninja/omnichannel-sentiment-analysis/ and https://thecrm.ninja/omnichannel-supervisor-tools/). It’s really a great feature that allows agents to quickly & easily see how the customer is interacting. It also allows for supervisors to see at a glance how interactions are going overall.

With all of that, I thought it would be helpful to take a further look into how sentiment analysis actually works, so that we can understand it a little better.

Now, the actual nuts & bolts for sentiment analysis are provided by Azure Cognitive Services. There are a wide range of tools available through this, but we have no need to go into Azure to configure this. It’s a simple setting within Omnichannel to get it working, rather than needing to fiddle around with many different things:

However, what’s actually going on during a conversation, and how is the sentiment analysis worked out/calculated? We see the pretty little face icons (with the different colours), but how are these actually being set?

Well, there are two ways in which algorithms are used to calculate the sentiment that’s shown:

  • Natural language processing (NLP)
  • Machine learning (ML) algorithms

With these two ways methods, it’s possible to not only see what the current interactions are showing, but also to enhance the model to understand sentiment better.

Note: In a session that I presented recently, one of the attendees asked if it’s possible to train the model, to result in a custom algorithm. Unfortunately this isn’t possible to do – the machine learning that takes place is the general Azure one, rather than one for a single company or customer

The following diagram shows the sentiments that are used. They’re nicely colour-coded, for ease of reference as well:

When a customer interacts through Omnichannel, the sentiment shown is based on the last 6 messages received from the customer. As a result, the sentiment shown can very well fluctuate & change during the conversation, based on how it’s going.

The Sweetest Languages in the World - | Beyond Exclamation

Obviously, customers aren’t just going to use English to communicate. Companies are based around the world, and will use their native/local language when providing support. Omnichannel allows for this without an issue, utilising the Azure Text Translator API behind the scenes to provide this. If you’re interested to see which languages are supported for this, head to https://docs.microsoft.com/en-us/azure/cognitive-services/translator/language-support which is the latest source of information for this.

There are some interesting things to know around how this actually works:

  • When a language other than English is used, the Text Translator API translates the text to English, and then it’s analysed/scored for sentiment
  • If a language isn’t supported by the Text Translator API, it won’t be scored
  • If profanity (eg a swearword) is detected, the sentiment will automatically be shown as Negative or Very Negative, regardless of the rest of the last 6 lines of conversation

Some people have expressed their concern to me around how accurate the Azure translation actually is, but to date I haven’t seen any major concerns resulting out from it. As with the other Azure services, Microsoft is continually refining & improving it. That being said, there are several languages with very nuanced terms. I’d like to think that these would be supported without issues.

There is, however, somewhat of an interesting behaviour when starting off the analysis at the beginning of the conversation:

  • If the initial language is detected as English, it’s assumed that all of the subsequent conversation will be in English. As a result, if the customer switches away from English, the system won’t recognise this, and a Neutral sentiment score will be shown
  • If the initial conversation is not in English, then the system will check every conversation line & re-detect the language as necessary.

This seems somewhat strange to me, as I’d have thought that the system would automatically check the language for each conversation line. I can think of plenty of scenarios where different languages are used in a single conversation, even if it does start with English being used. I’d like to think that this will be updated at some point, to make the experience better.

Omnichannel Supervisor Tools

While I’ve covered a lot of different pieces of functionality from both the end customer & agent experience, I haven’t really touched on the Supervisor experience to date. With the release of a nice little piece of functionality for it around Sentiment Analysis, I’ve therefore decided that it would be a good time to take a look at it.

Now obviously supervisors exist, in the sense that any contact centre would have managers in place to manage the agents. Indeed, they may actually handle customer queries directly as well – miracles have been known to happen! 😉

Really the aim of the supervisor role within Omnichannel is intended to help customer service managers or supervisors enhance their team’s performance and improve customer satisfaction. They need to ensure that customer queries:

  • Are being responded to quickly within an accepted period of time
  • have agents that are providing the right information necessary to handle the query
  • Are handled in a satisfactory way
  • Leave the customer feeling positive & satisfied around the interaction

To this end, the supervisor role includes access to various dashboards & views on the sessions that are taking place. From this, they’re able to ensure that KPI’s are being met, that queues aren’t overflowing, and that agents are carrying out the right work.

Please note that PowerBI Pro or PowerBI Premium licenses are required for users with the Supervisor role in order to access & view these dashboards

On-going Conversation Dashboard

The on-going conversation dashboard is one of the first tools available to supervisors. In this, they can see the entire ‘landscape’ at one glance, covering:.

  • Which conversations are currently active
  • The queue that the conversation has come through
  • The channel that the conversation has come through
  • Which agent is currently handing the interaction
  • The sentiment of the customer experience (more on this below)

Through this, there’s a wealth of knowledge that the supervisor can use. If a conversation doesn’t appear to be going well, they can reach out to the agent who’s handling it, and ask if they need assistance. They can be ready to offer escalation resolution should it be needed.

Supervisors are also able to allocate any conversation that’s an in ‘Open’ state (ie it hasn’t yet started) to a specific agent, or to a specific queue.. They would do this by selecting the conversation in the window, clicking the Assign button (which appears when the conversation is selected), & selecting either Agent or Queue. Depending on which option is selected, they can then select the agent or queue that they wish to.

Furthermore, supervisors are also able to monitor any conversation that is happening (as long as it’s in the Active or Wrap Up stage). When doing this, the customer & the agent don’t know that the supervisor is monitoring the conversation (unless the agent requests it, of course). Through this, they can keep an eye on how things are going, and if they feel it’s necessary, they can join it (without needing to be invited to it). Of course when they join the conversation as an active party, the customer is then notified about it.

To do this, a supervisor would select the conversation (providing it is in the ‘Active’ or Wrap Up’ state) and then can click ‘Monitor’. This action triggers a new session for the supervisor to be pulled into the conversation.

Sentiment Analysis for Supervisors

So one of the really cool features (in my opinion) that’s recently appeared is the ability to use sentiment analysis to automatically alert supervisors.

You’re able to choose the level of sentiment that you want supervisors to be alerted on. When a conversation reaches the predefined level, the supervisor will get a prompt like this:

Sentiment analysis notification

They can then click through to either monitor the conversation (& help out if necessary), or to ignore it. This can be really helpful as it’s allowing the supervisor to be proactive, rather then needing to keep a close eye all the time on the supervisor dashboards. Indeed for a large contact centre, there could be dozens or even hundreds of conversations happening at the same time, so this will immediately flag these conversations to them.

Intraday Insights Dashboard

The Intraday Insights dashboard gives information around KPI’s that are in place for the company. This does need to be configured before supervisors are able to access it – I’d recommend looking at the extensive guide on how to do this at https://docs.microsoft.com/en-us/dynamics365/omnichannel/administrator/configure-intraday-dashboard-supervisor.

There are two sections that are included:

  • Conversations insights
  • Agent insights

Conversation Insights

This section gives supervisors insights into conversations that have occurred over the last 24 hours, against a range of KPI’s. This is therefore a ‘rolling state’ dashboard, without the ability to go back further over time, or pick a specific date-range. If this ability is needed, then the Agent Insights dashboard will be used.

Conversations insights dashboard

As you can see from the image above, we’re looking at metrics across different sorts of KPI’s:

  • Average wait times
  • Average handling times
  • Conversations exceeding specified criteria

This can be very helpful on an on-going basis to see how the contact centre is performing overall, over the time period. Drilling down into these items can help identify bottlenecks & choke points, which can then be worked on to provide better service & efficiencies.

Agent Insights

This part of the dashboard gives information across various health & status items on any given day. Using this, supervisors can drill down into issues that may not be visible through the conversation insights dashboard.

From the screen above, we can see that things like conversation states, agent status & participation modes are available to view.

Because these are PowerBI dashboards, it’s possible to drill down further into them, filter by item (eg queue, agent, etc), and see very specific stats about items.

I hope that this proves to be helpful in understanding some of the tools that are available within Omnichannel for supervisors, and the help that they can give in running an efficient and productive contact centre!

Omnichannel – Pre Survey Responses & Routing

I’d like to start off here by admitting that in a previous blog post that I put up, I mentioned that it’s not possible to route customers to different queues through the chat itself. That was wrong – thankfully several very nice people at Microsoft reached out to let me know how it’s done (thanks BTW for reading my blog!). I therefore thought it would make a good article, as people do ask me about this from time to time.

So, how exactly does Omnichannel facilitate this? Well, there are two parts:

  • Pre chat surveys
  • Routing rule items

Pre chat surveys

These surveys are really quick & easy to set up (or even more complicated, if you so desire). To start getting to grips with them, open a Live Chat record, and go to the ‘Pre-chat survey’ tab

Here, you’ll be able to set up your questions, which is done by clicking the ‘Add Question’ button. When you do this, you’ll get the following prompt.

So, three of the four questions are really quite simple. You need to give it a name (as every system record needs), the actual question text, and whether it’s mandatory or not. The fourth question ask you what sort of question type you’re looking for. The options available are:

  • Single line of text
  • Multiple lines of text
  • Option set
  • User consent

If you select ‘Option set’, you’ll be prompted to enter the values. These should be separated by a semi-colon character:

With our pre-chat survey questions being set up, let’s see how we go ahead and use them for routing.

Workstreams

If you go ahead and open up any workstream record, you’ll see several tabs available. Two of these tabs are Context Variables, and Routing Rule Items. There’s usually one workstream per chat channel, with setting options within it as required. Opening up the workstream for the Live Chat, we can see them there:

Let’s take a closer look at the Context Variables first. Going to this tab shows us the following:

Woah. Where did those entries come from? I didn’t enter anything here – though I can create context variables if I want to.

Well, remember those pre-chat survey questions that we created? Each time one of these is created, it creates a context variable record for the workstream that the chat is associated to. So each of my questions (and I have four of these) now have a corresponding entry.

OK – so the system does that. But how does that help me when looking at trying to route things?

Simply put, these are the building blocks that we’ll set up in the Routing Rule Items to flow the customer chat through to an appropriate location. Let’s go and create one to see what happens.

We need to set the queue that this rule to apply to. Then we’ll go ahead and set the condition/s that we’re wanting to apply for this queue. There are several different possibilities to start with:

Selecting the entity that we want to use for the rule will then allow us to pick an attribute for that entity. So;

  • Account, Contact, Case & Live Chat Context will give an option to select one of the attributes from the entity
  • Context Variables will give the available context variables to choose from

You’ll then be prompted to select an Operator. These will vary depending on the type of field (eg a number field will have additional options such as Greater Than, Smaller Than, etc)

Finally, you’ll enter the value that you’re looking to match with for the condition. This is free text (it’s not auto-populated with values). So in summary, you’ll have something like the following:

And tadaa! it’s active. Brilliant!

We’re able to stack up multiple conditions to cover specific scenarios. An example could the following:

  • Customer has a Kawasaki motorbike (not a different make)
  • Customer’s annual spend falls into the ‘high spend’ bracket

There are plenty of other scenarios that can be covered, and the conditions allow this to cover quite complex situations.

So, some things to note around workstreams & routing rule items:

  • You can have multiple routing rule items per workstream, each one routing to a different queue. These are evaluated in the order that they’re saved in. Eg if there are 4 rules, an incoming chat will be evaluated against rule 1, then rule 2, etc
  • When a routing rule condition is met, the chat gets routed to the destination. No other evaluation against the remainder of the rules is carried out

I hope that this has come in useful, and put some interesting thoughts into your mind as to how you could implement this at your organisation or clients!

Omnichannel Install/Update Errors

I’ve had an interesting time over the last week or so. Several people have contacted me about trying to either install Omnichannel, or upgrading to the latest version. These differ based on what the user was trying to do.

When trying to install into a new environment, the error says ‘To add this channel, you must have an active subscription to Dynamics 365 for Customer Service Chat or Digital Marketing’. This is especially strange as a trial environment (for testing purposes) doesn’t actually require these licenses. It only requires a Customer Service Enterprise license.

When trying to upgrade an existing environment, there’s a different error. This one says ‘We are unable to check for upgrade as you don’t have the required permissions. You need to be either a global administrator or a Dynamics 365 service administrator to check for upgrade. Transaction Id: 0cc1f6be-32f1-476c-8071-acc4d8475e63’. However the user has the Global Administrator role (which obviously also includes the Dynamics 365 Administrator role as well!

image.png

Now I love being able to share my knowledge & help others. That’s one of the main reasons why I started this blog and why I share information that I feel is helpful & useful to the wider community. So I was more than happy to try to help the people who had reached out to me, and jumped on a screenshare session with them (using Microsoft Teams, I may add!).

They were indeed getting the errors mentioned. Nothing that I could suggest helped to rectify. To try to diagnose & compare, I jumped into my own environment. To my absolute surprise, I was greeted by the same issues!

Nanny Knows Best: Shock Horror Probe - People Take Responsibility ...

I knew that it hadn’t been occurring several weeks back, as I had carried out some maintenance work in my own tenant & everything was working fine. I double-checked everything on my end, and it all seemed to be set up correctly.

I therefore decided to go ahead and log a ticket with Microsoft Support. I had a sneaky feeling that it was something, somewhere, to do with the Wave 1 2020 release upgrade. This had happened 2 weeks back (since I had last been into the Omnichannel setup), and I was figuring that something could have gone wrong.

This feeling was boosted by hearing that someone else who was having the same issues had also logged a ticket with Microsoft Support, and they had resolved the issue for the affected tenant. In doing so, they had mentioned that the back-end hadn’t been configured correctly, and got it fixed.

My support agent was a lovely guy called Tomasz, based in Portugal. Emails initially exchanged, we then jumped onto a Teams screenshare session so that I could demonstrate the issues from my side. He was very helpful, and immediately got to work. Within 12 hours I had received an update from him on the situation. They had identified the problem, and were working on a fix.

I had mentioned to him that I knew it wasn’t isolated to my tenant, or even region, but that other people across the globe were also experiencing this. I suggested that whatever fix would be found should be rolled out on a global scale (if applicable).

The crux of the problem seemed to be that with the Wave 1 2020 Release, there had been a change in the architecture of the Omnichannel total solution. Everything still appeared the same through the interface, but under the hood there had been some changes (I have no idea of what actually had changed though).

For new instances (whether Trial or Production), the solution was installing with the new architecture. However all existing systems (whether Trial or Production) had the old architecture, and the Wave 1 2020 Release wasn’t upgrading it to the new one. It simply failed, giving the different error messages.

The fix that was needed was actually quite simple, and only took a few minutes. I had to spin up a new trial of Customer Service within my tenant (which would expire within 30 days). Doing this re-installed the Customer Service solution, & included the new Omnichannel architecture. As a result, after waiting around 5 minutes I was able to open the Omnichannel Administrative Settings, and upgrade my existing Omnichannel deployment. I was also able to deploy to another new environment without any issues. The problem had been solved!

Joyful Green Monster Saying Hurrah Vector Sticker Illustration ...

Overall, this support ticket was an example of how support should be/work. I’ve had times before when it’s unfortunately not gone like this, which makes me value this all the more so.

So, lessons to learn from this. Well, if there’s an issue with deploying Omnichannel to a new environment, or upgrading an existing deployment, fire up a trial of Customer Service, and that should fix it. Brill.

I do wonder how this managed to creep in. Obviously one of the main parts of deploying any new major solution is thorough testing. Perhaps it could be that due to the size of the actual Omnichannel solution, something was overlooked somewhere? It would be good if this sort of situation would be avoided for future releases, and functionality build in to automatically upgrade the Omnichannel solution if it has an old architecture.

Update. I’ve actually had feedback from the Omnichannel team around this. Essentially there’s something different about Trial environments, and this issue only affected them. Production environments (ie with paid-for licenses) wouldn’t have experience the issue. I don’t know why they’re different, but somewhere they are!

Omnichannel – Chat Setup

Looking back at the information that I’ve already posted on around Omnichannel for Microsoft Dynamics 365, I seriously can’t believe that I haven’t already done an article on how to set up a chat channel. I know I’ve talked about some of the functionality within chat itself, but it’s now time to sort this out.

This was the FIRST thing that I did when I got my first Omnichannel environment up & running. The feeling of satisfaction when it was all complete and worked was incredible. I think I may have bounded out of my chair, punching the air!

So, with that all being said, let’s see how to go about it. It’s not that difficult, and there are some helpful settings within it. The functionality has also increased with the Wave 1 2020 release, which is quite cool.

Now, you can create multiple chat channels, and position them where you want to. Each chat channel can point to a different workstream, and then feed into a different queue (more on that in another post).

To create a chat channel, go to the Omnichannel Administration Hub, select ‘Chat’ in the left hand menu, and click ‘New’

You’re then presented with a new Chat record window, to set it up. It’s actually quite simple to go through, with tabs providing different options. Don’t forget about these!

A few things to point out from the main page:

Chat Design

Once you’ve filled in the main information, switch to the Design tab. Here you’ll be able to configure the look & feel of things:

Now at this point in time, you’re only able to use the pre-defined theme colours for the Omnichannel chat widget. That’s not to say that you can’t work around this – if you use an Azure bot, or a custom bot (which needs to be using the Azure bot framework, admittedly), you could set a custom colour there.

You can change the logo displayed – this needs to be a publicly accessible online image. This can result in some fun looks!

You can also set Operating Hours for when the chat will be active (see https://thecrm.ninja/handling-company-hours/ for how to set this up).

Pre chat survey

Heading to the pre-chat survey tab, we can set up survey questions for the customer to answer before the chat actually starts with an agent.

There are some nice options here:

  • Being able to set questions as mandatory or not
  • Different answer types available. Eg text (single or multi-line), option-set, or user consent

Now at this point in time, it’s not possible to use the answers given (eg with using an option-set) to route a customer to a specific queue. It would be amazing if this would happen, but it’s not there yet. Instead the information from the pre-survey questions are displayed in the agent interface. This is aimed at being able to gather information upfront, rather than the agent needing to ask for this during the chat session

Location

The next tab allows the ability to tie the chat widget to a specific website. This means from a security point of view that if someone copies the source code from your webpage, it won’t work on a different website. If no domain is specified, the chat widget can be embedded on any website, without restrictions. It’s a useful concept that can be handy in certain scenarios.

We’re also able to capture the customer geo-location. This will prompt the customer to allow their location to be shared with the agent. If the customer doesn’t consent, then it won’t be shared. Note that this does require Bing Maps to work

Conversation Options

Part of the Wave 1 2020 release has been additional functionality for Omnichannel agents to use. This includes abilities to call, co-browse, and screen-share during customer chat sessions.

I’m going to going into detail around these options in a separate post. I’m also going to be looking into the current solution providers for this, and seeing what each one provides above & beyond Omnichannel integration

Custom Messages

The final tab gives the option to use custom messages for some of the system functionality. Essentially things like starting a chat, ending a chat, and chats timing out all have messages around them.

These are things like ‘An agent will be with you in a moment’:

What custom messages allows you to do is to change these. So for example, you could set up the following to be displayed:

I hope that this has been helpful in seeing how you can set up a chat channel. Stay posted for how to set up the other channels as well!

Omnichannel Desktop Notifications

I’m quite regularly asked various things about Omnichannel. One of the most regular questions goes along the following lines:

Are we able to show a desktop notification to our agents, when they’re not on the Omnichannel Customer Hub screen?

Let me explain what this is all about. When an agent is logged into the Omnichannel Agent Hub, and a new chat comes in, they get the following prompt on their screen:

They can then accept it (which will open up a new chat session), or reject it (which will send it back to the queue).

But if they’re not on the browser tab that Omnichannel Agent Hub is open in, they won’t see any notifications. At all! So they miss out on this, and the customer isn’t engaged with. This obviously is undesirable from a business perspective, as it could even result in losing the customer. So the answer, until now, has unfortunately been ‘No’.

Now in the past when this has come up, I’ve suggested that people take a look at either:

However in my experience these haven’t really been suitable for Omnichannel. This can be due to various reasons, including the client, the requirements, or the infrastructure itself. It’s always been a real annoyance to things, and something that I (& many others) wish would be in place. Several of us have given previous feedback to the product team that this would be really useful to have.

Companies want their agents to be as productive as possible, and this therefore results in a gap in their potential productivity.

Well, the amazing news is that the Product Team for Omnichannel have listened to the feedback given. Not only that, they’ve actually acted on it!

As part of Wave 1 2020 functionality, we now have Omnichannel desktop notifications! This can cover the following scenarios:

  • The Omnichannel agent has minimised the Omnichannel Agent Hub app
  • The Omnichannel agent is working on another tab of the browser
  • The Omnichannel agent is working in another browser window

So what does this actually look like? Well, it’s quite nice & neat to see:

Desktop notification

Very helpfully (in my opinion) it even tells you the browser that’s being used. Users can be running multiple browsers, and this helps as a reminder. If a user has multiple different browsers open, this can assist with working out which one has Omnichannel running in.

Now, there are several different actions that will happen, depending on the agent reaction to the notification:

  • If the agent clicks on the text (but not one of the buttons), it’ll open up the Omnichannel app, and show the agent the notification within the app. They can then choose to accept or reject it within the Omnichannel app
  • If the agent clicks the Accept button, the Omnichannel app will open up & be active, and the session with the customer will start
  • If the agent clicks the Reject button, the notification will go away, and the customer will be returned to the queue

Lets take a look again at the notification within the app itself:

There’s a ‘Wait time’ contained with it. If the wait time expires without the agent doing anything, the conversation is returned to the queue.

This value can be configured by the Omnichannel Administrator, to whichever setting fits the organisation. To do this, go to Notifications in the Omnichannel Administration Hub, open up the notification that you’re wanting to modify, and change the value shown below:

However, you’ll note on the desktop notification that there’s no ‘Wait time’ included on it. This is because the way that notification appears on the desktop doesn’t allow for it to be shown. That isn’t to say that it’s not applicable – the agent will still have the same amount of time to respond. If they don’t respond within this time, the desktop notification will disappear.

Now, there’s still something that the agent will need to do in order to have the desktop notifications to appear. They’ll need to give the browser permission to allow it to happen. The first time that it occurs, it’ll prompt the user as follows:

Allow desktop notification

When the user clicks ‘Accept’, it’ll save the setting, and the desktop notifications will be pushed through. Obviously if they don’t, the desktop notifications won’t appear!

There can be occasions when this still doesn’t work. The below items should help you troubleshoot any these, or similar situations:

One thing that’s also really useful to know is that all of this isn’t just for new customer conversations. The functionality for desktop notifications also covers:

  • Incoming chat conversation
  • Incoming SMS conversation
  • Conversation (work item) assignment
  • Conversation transfer
  • Conversation escalation
  • Conversation escalation from a bot

So really the whole gauntlet of agent interactions that they’d be doing on an on-going basis. Which of course is really helpful, and highly useful.

I’m really quite happy that this has come out as part of the Wave 1 2020 feature items. I’ll be continuing to go into depth around the other functionality that’s part of this release. For the moment, I’m also going to quietly wonder what the product team are going to include next – I’m sure it’ll be very helpful!