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!

Benedikt Bergmann on The Oops Factor

Chatting about Benedikt’s love of bouldering & rock climbing, as well as why ALM is so important. We also discussed a project of his single client that had 9 Dynamics 365 organisations that needed to be deployed to, with nothing in place to automate this at all.

If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!

Click here to take a look at the other videos that are available to watch.

Thoughts around the Connection entity

I decided to write this post due to currently looking at the Connections entity. This is for a current project with a very specific purpose. When this came up, my thoughts went back to a previous project some years back when we also looked to use the Connections entity. I therefore thought that it would be good to recap & share my experience.

What are Connections?

Now, the Connections entity truly is a wonderful piece of work. It’s one of the core features that doesn’t actually get much time or effort devoted to it! However, it underpins a lot of the way that Dynamics 365 has been built to work over time.

The best way to summarise Connections is:

Connections are a very easy way to connections records without needing to have to create a custom relationship in the system. Connections can be used between records from the same entity, or from different entities.

See, you are able to connect one record to another record within the system. This could be account to account, account to contact, or contact to a custom entity. There are practically no limits, apart from the extent of your mind! All of this is done by leveraging the functionality that Connections brings to the table.

Note that I’m not talking about lookup fields here, which are also great, but work differently, and require creating a relationship between entities (or even within the same entity).

Just a quick reminder here that custom entities need to be enabled for connections – it doesn’t happen as standard when creating them. You can either do this when creating it, or you can edit the settings for it later:

How to use Connections

In order to connect one record to another, you need to open the first record & click the Connect button on the toolbar:

You’ll then be presented with the New Connection screen, where you’ll select the record that you want. Click the ‘All Records’ item at the top & then ‘Change View’ to select the actual entity that you’re wanting to look for:

You then select the record that you’re wanting, and save. Hey presto, the two records are now connected! To see the connected records, look at the associated ‘Connections’ setting from either record:

OK, so this is really all brilliant. For the absolute majority of situations, it works, and works well. There’s nothing better for it. There are a few small issues, such as the fact that you can’t use Business Process Flows or Business Rules for custom logic, but instead need to use Javascript, but for the most part they work well.

Edge case scenarios & issues

However, there are some edge case scenarios that I’ve come up against, which is the whole purpose for writing this blog post.

What happens if you’re trying to use Connections to establish a hierarchy of records. Eg one record is a parent of another record. Well, you could use a lookup field instead, but if you wanted to define specific attributes for the actual relationship, that wouldn’t work.

Here’s the scenario. You’re needing to capture the relationship between different people, along with certain attributes (eg if they’re a legal guardian, or a trustee, or have power of attorney, etc). You’d think that Connections would work brilliantly for this. After all, you can modify the actual Connections entity to add custom fields onto it. So for example, you could have something like the following:

Note: I’m not referencing Connection Roles, as you can only have a single connection role per connection. In the scenarios I’m handling, I’m needing to have multiple attributes per connection.

So you create the connection between the two records, and you set the attributes that you require. All good. What’s also good to remember is that Connections are bi-directional. You can view them from either ‘side’ of the connection. Eg:

Record 1

Record 2

That’s actually really helpful & useful in the normal scheme of things. You can easily see connections from either side.

But there’s a catch, or even (in our case above), an issue. If we open up each of the two Connection records, we’ll see the following data.

Joe Bloggs connecting to Helen Sommers:

Helen Sommers connecting to Joe Bloggs:

Can you spot the issue? Of course you can! On BOTH of the connection records, the custom fields that we set have the same values. We originally connected Joe Bloggs to Helen Sommers as the Legal Guardian, Power of Attorney & Trustee. Well, if we open up the connection record from Helen Sommers, we’re seeing the same values set, just in the opposite direction!

This is actually due to how Connections work. When you create a connection Record A to Record B, the system automatically creates a mirror Connection record from Record B to Record A. When it does this, it copies all of the values that you’ve set over to this mirror record.

So when you look at the data, you can’t actually see how the structure should work. It’s an issue. Especially if you’re passing the data to other system/s that may need to evaluate it. They just can’t understand this properly, and you’ll get some VERY unwanted results out of this.

Now, there is actually a field within Connections that shows which record is the ‘master’ (ie the one you actually created), and which one is the ‘mirror’ that the system created:

However even with this in place, we’ve found issues when using it:

  • If you’re relying on people looking at the record to see the information, they’re going to make mistakes (ie not checking this value). With the fact that the values are also displayed on the mirror record, this is very prone to user error, and isn’t a good way to do things
  • If passing information to another system (ie the record & the values), you need to program it to only allow it to pass records with this flag set correctly. If the other system is writing back data, it also needs to be configured to write back to the same record.

Summary

With all of this in mind (& especially considering that users may create connections from the ‘wrong direction’, which is quite possible to happen), it’s important to think of the best way to architect systems for regulatory purposes. Financial, legal & other judicatory requirements need to have a system that can handle them properly & accordingly, and not leave room for error.

Therefore, if you’re looking to handle these sorts of scenarios, I’d recommend to look at implementing a custom entity for those specific connections.

Another benefit of this is to separate out these connections from the general connections entity. That way, you’ll also be able to handle security appropriately, which is usually applicable in these sorts of situations. It will allow you to easily allow only a subset of users access (read and/or write) to this data, rather than trying to apply it to Connections (which is going to be a major headache!)

Canvas Apps & renaming field labels

Today I want to share with you something that I’ve realised. Changing field labels can have unintended consequences!

Let’s cast our minds back to the days of ‘traditional’ Microsoft CRM, or as it’s so lovingly referred to nowadays, ‘model-driven’ apps. What you had were a number of entities (eg Accounts, Contacts, etc), all of which contained fields. Fields could be different types (text, integer, boolean etc), and have varying properties on them. You could set them to be required (or not), searchable (or not), and have so much fun.

At the heart of a field is the name that it has. Well, technically there are two names. One is the actual database name. Once a field was created & saved, this was effectively written in stone. The only way to handle a situation where you spelled this incorrectly was to delete it, and then recreate it. Even then, it could still be floating around in the back-end database in its original form.

The second name is the Display name (or Display label). This was the text used on the entity form itself, & could be changed as desired. This was actually really useful – many a time a business unit would say something like ‘we don’t want the field to show as Zip/Postal Code’; we want it to say ‘Postcode’. Well, that was easy enough to address – simply go ahead, load up customisations, & change the display name property for the field. Everyone was impressed & happy, and could get on with their work.

There were of course times that Business Unit A would say ‘I want ‘ABC’ as the display name’, and then Business Unit B would say ‘Ah, but I want ‘XYZ’ as the display name!’. To handle this, it was very possible to customise the label on the form itself, which would then override the display name value. This, of course, would only be valid for that specific form, so it was then imperative to have different forms for the different business units.

Now, in the good old days we use to create SQL queries against the database, SSRS reports, etc. In order to do this, we needed to know the actual underlying (database) field name. We could of course open up customisations, & start trawling through, but there are better methods for doing this. One of these is Level Up by Natraj Yegnaraman. This can be found at https://github.com/rajyraman/Levelup-for-Dynamics-CRM, and is an extension which can be run on Chrome, Edge on Chromium, & FireFox).

Using this amazing tool, it was possible to merely load an entity form up in an existing system, and then TADA! At the click of a button (well, two clicks actually), the underlying database name was revealed. This was an absolute lifesaver, so many times.

So there we’ve been, toddling along for many years like this. It worked, and worked well. All was good.

Then came along canvas apps. Now I’m not a canvas app guru by any means – I’m quite new to them, and still trying to wrap my head around the ‘special’ way in which they operate. Thankfully there are quite a few gurus in the community who have given me help in one way or another to learn how to carry out various functions, and I think that I may JUST be starting to get the hang of it.

With the current COVID-19 situation, I’ve been working on a series of apps for work, to help local authorities. One of these is a canvas app for call centres, to record information easily & quickly. We chose to go down the canvas route due to being able to have a clean layout, as well as being able to display information for the operators to read. This would have been much more difficult in a traditional model-driven app, especially as such things as dialogues have been deprecated.

One of the functions that I’ve had to learn to do this has been to use the ‘Patch’ function (see https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-patch for more information on this. The following is an example of one of the Patch statements that I was using:

This was working remarkably well – it was creating the task record, and setting all of the different values that I needed. For those who are curious as to why I was using a Patch statement, rather than submitting the form, it was due to needing to set the ‘Regarding’ field, which has some very special behaviour!

Then someone on the team said ‘Hold on – we’re only storing one address. Let’s change the field display names to remove the ‘Address 1′ part, so that we don’t confuse users’. OK – I didn’t INITIALLY see any issue with this. I bet that you can see what’s coming through…

Yes – you’re right. The patch statement isn’t referring to the field database name. It’s referring to the field display name! The reason for this is that this is the syntax that Canvas Apps use – there doesn’t seem to be a way to refer to the actual underlying field database name

Of course, I only actually discovered this when I ran through the canvas app again. And indeed, it was whilst demonstrating it to other people! Oh joys – what a wonderful time for it to happen.

So, I then had to figure out what had happened – thankfully that didn’t take too much time. What DID take time was going through every single place in the canvas app that had code referring to the specific fields, and update them to the new (correct) values. This therefore ended up looking like:

So, the vitally important lesson to learn here is be VERY careful when changing field display names, especially if you have one (or more) canvas apps that are referencing them. The last thing that you want is a major headache in having to go back through every place that refers to them, and changing/updating the values.

The only workaround that I’d suggest, is that if you’re wanting to change how fields display in the canvas app itself, change the ‘Text’ value for the field:

That way, HOPEFULLY, nothing will break moving forward.

I hope that you’ve found this useful. If you have a different way in which you’ve handled this situation, feel free to leave a comment below!

Mark Christie on The Oops Factor

Finding out about Mark getting Jon Levesque dressed in a kilt at Scottish Summit, and how that went. Also discussing how Mark’s first foray into consulting occurred, and how he learned all about project time projects for clients.

If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!

Click here to take a look at the other videos that are available to watch.

Farewell to the Outlook Add-In

From the first time that I used Microsoft Dynamics CRM (all the way back in the day), I remember the Outlook add-in. Or rather, I should say that I remember the PAIN that the Outlook add-in was!

You remember what I’m talking about, I hope. Here’s a screenshot of the ‘fabled’ toolbar:

The installation of this was a nightmare, to be honest. From the pre-requisites that it needed to install (and download – even if the machine already had them installed), to just hanging there, it wasn’t ever something that I looked forward to putting on machines.

It was a memory hog, slowed performance, and occasionally crashed Outlook, seemingly just because it felt like it! In addition, trying to carry out a mass roll-out of it (through SCCM, or Group Policy, or even other methods) never seemed to work properly at all.

In one of my roles we had to install this for dozens of users. Randomly, even on brand new machines (with nothing else installed), it would fail to install or initialise. Long hours were spent poring through logs, trying to work out error messages, and frantically get it working. Users were VERY used to seeing the following error happen:

In short, it’s been around for a VERY long time, as the following diagram shows (I’m loving how they compress 12 years into just a short space):

In late 2017, Microsoft announced that they were going to deprecate the Outlook add-in. There were several other options around, such as proper server-side sync, and the Dynamics 365 app for users. These were supposed to be being used instead.

The response from clients was crazy – so crazy in fact, that Microsoft did something that it very rarely does. They reversed the decision to deprecate it, and instead confirmed that it would still be sticking around. They realised that the other options weren’t at parity with the Outlook add-in for desktop, and didn’t want to deprive users of the essential functionality that they were needing.

In 2018, I was at Summit EMEA in Dublin. One of the more interesting conversations that I had with one of the senior Microsoft people was around the Outlook add-in. They told me that from the moment that Microsoft had announced that it was deprecated, every client had asked them about it. Even to non-technical people (eg sales, etc). It was due to this, in part, that they decided to un-deprecate it!

Moving on several years, the landscape has now matured. A lot of users are using Outlook through browsers, rather than the desktop version. They natively plug-into Dynamics 365 through the web as well. The Dynamics 365 App for Outlook has gotten better, along with the way that it works:

Users, on the whole, seem to have generally adopted the latest technology, and have therefore moved on from relying on the Outlook add-in for desktop. There’s also the new Unified Interface, which the Outlook add-in doesn’t support (and which will be being rolled out to all users on Dynamics 365 during 2020!).

Microsoft has therefore announced that as of March 2020 (which has just passed), the Outlook add-in has now been deprecated (once again). Support, security & other critical updates will be continue to be provided until October 1st 202, but customers will need to transition to the Dynamics 365 App for Outlook by then.

Very nicely, they’ve provided a playbook (which can be found at https://aka.ms/OutlookCOMPlaybook). This details the upgrade path, and has some good information in it for customers who will need to upgrade from it.

So if you’re still on the old version, take a look now, and work out the best way for you & your organisation to upgrade. It’ll give you newer & better functionality, work easier, and above all, shouldn’t crash your machine!

Let me know in the comments if you have any questions around this, and I’ll do my best to help you out.

Canvas App record set Regarding field

For the last few days, I’ve been working on an app. Not just any app – it’s a canvas app! (It actually happens to be a COVID-19 related app, for local authorities to use to contact vulnerable people & check they’re OK etc).

Now, my background isn’t canvas apps – it’s the model-driven app approach. I’ve been doing this for years – after all, my experience goes back to Microsoft CRM 3.0! So that’s all really nice & easy for me (even with some of the more modern ‘tweaks’ that have been brought in). Canvas apps, on the other hand, are very different from what I’m used to, and are taking quite a bit of getting used to.

See, the following example is easy in a traditional model-driven app:

Create a contact, save various attributes to the contact record. Then create a task, and set the Task Regarding field to the contact that you’ve just created

Looking at that, my mind says ‘easy-peasy’!. I create the fields required for the contact entity (& task entity as well, if needed). I then add them to the entity form/s (creating or modifying the form view/s as well). Finally, I create a Business Process Flow for users on the contact entity, and append the task creation to it. Simple, and done – not much time needed to be spent.

But when needing to do this as a canvas app, things change around QUITE a bit. I can’t create that business process flow, and I have multiple screens to have all of the information on.

Now, if I could add the ‘Regarding’ field to the edit form grid, and apply formatting to it, I could hopefully then just submit & save the grid. However, that unfortunately doesn’t work. I can add the field, but when I do so, I get the following:

So that doesn’t work. Hmmm – how then should I go around doing it?

I did (obviously!!) take a look online. Here I came across this wonderful article all about polymorphic lookups (https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/working-with-references). Having read, & re-read through it, I’m STILL not understanding what exactly I should be doing by this!

So I was stumped. Thankfully we have an amazing community, and on reaching out to someone within it (thanks Eric!), I was helped out. I therefore thought to write this post up, so that it can help others as well.

There are two parts to this, for my specific scenario:

  • Saving the contact record down. This is a matter of using (in my case) the command ‘SubmitForm.ContactInformation’ on my contact form screen. I can then also set a variable if I want to, to refer to the Contact record GUID (hey – I’m trying to be cool here & show that I can!)
  • Finding a different way to save my task record. I accomplished this using the Patch statement – this thankfully wasn’t too difficult for me to grasp how it worked.

So, how did I go about using the Patch statement? Well, the function is referenced here – https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-patch. With Eric’s help, I soon started to see how to do it.

What I did was add the following line in my Patch statement when I was wanting to save the task: ‘Regarding:ContactForm.LastSubmit’ (‘ContactForm was the name of the form for the contact information). What this did was write into the record the GUID for the contact record that I last saved.

An alternative to this would be to use a variable instead, and set it there.

Thankfully this all worked. I’m now able to create Task records and set their Regarding field value to the Contact that I set up before them – which is the exact thing that I was trying to do!

I hope that this has been helpful – leave a note in the comments if you’ve found another way of doing this.

Sara Lagerquist on The Oops Factor

Finding out how Sara decided to get a dog (no, she didn’t dog-nap someone else’s!), starting out as a Dynamics 365 customer, actually getting involved in customising the solution, and why things went so wrong when updates were released.

If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!

Click here to take a look at the other videos that are available to watch.

Uses for Omnichannel in times of crisis

I originally had a different article planned for today, but with the current situation that’s happening over the world, I decided to change what I was going to talk about.

The world has gone crazy, in so many ways. There’s plenty of information out there around what’s happening, and with best advice to people as to how to deal with things, cope, etc. I’m not going to cover that (besides, it’s likely that things will change over time, which means that anything I write could be out of date soon).

Instead, I’m going to address one of the specific issues that I’m seeing again and again. This is the bottleneck that people are facing when trying to contact companies, whether the company is their bank, their utility provider, their health provider, or even travel companies.

Image result for bottleneck

Regardless of whether people are trying to cancel an existing holiday & get a refund, speak to their bank to get a mortgage holiday, or get medical advice, they’re facing the same major issue – they’re not the only ones trying to get through. Phone lines are jammed (assuming that they’ve not been stopped due to agents being sick), static forms where you fill in information aren’t liked (as you don’t know what the actual status of things are), and online chat takes an absolute age. I had an online chat session with Amazon two days ago, and it took over an hour for one of their associates to join my session to help me.

Go to any major company website, and you’ll probably see something like the following (this is from British Airways):

I’d like to be clear – companies couldn’t really have forecast all of this happening, if you’d go back several months.

But what companies can, and should have in place, are clear communication protocols that actually enable them to handle a massive scale-up of customers contacting them. It’s not going to be perfect, but can help mitigate the bottleneck to certain degrees.

Having an efficient system can allow a single agent to handle multiple communication streams at the same time. Indeed, it’s not just about handling multiple web-chat sessions concurrently – it’s also about handling communication across different mediums. So agents can handle webchat, Facebook messages, Twitter DM’s, etc.

This is, I believe, where products such as Omnichannel for Dynamics 365 can really come into their own, and shine through. Using it, companies can ensure that their workforce (which is likely to be impacted as well by the situation) can be as best empowered as possible, and assist customers as speedily as they are able to.

Hopefully the current situation will resolve itself as soon as possible, and coming out from it, we should look to carry out any efficiencies that we are able to. This will allow companies to better serve their customers moving forward, and streamline communication channels.

I hope & pray that everyone stays safe & healthy through this crisis, and that we help each other out (to the best of our abilities) to get through it.