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 explain who to configure webchat.

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 plan 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 the configuration of webchat.

Tip:
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.

Webchat (Overview)

In this post I will try to explain the main considerations when setting up webchat. This is important as one of the most common channels will be webchat.

I will begin by describing the basic operation of chat. Below you can see that I am using a standard demo portal for my chats. (I will show you how to enable chat within a portal later in this post.) Once web chat is enabled a “Lets chat” widget is displayed.

When the customer starts a chat a dialog opens and they wait for an agent to respond.

Assuming the agent is logged into either the “Customer Service Workspace” or “Omnichannel for Customer Service” apps then they will receive a notification. Clicking “Accept” will commence the chat.

You can see below that the customer can now chat with the agent.

Note:
The above was based on a minimal setup of web chat. I have done that deliberately as I wanted to show you a simple initial setup of webchat. Later in this post I will expand on some of the configuration options available to us. Such as pre-chat surveys and more. You should however keep in mind that these are revision notes, I may not cover some options! I encourage you to experiment with as many features as possible as part of your revision.

Initial setup of webchat channel

As already mentioned I want to initially show you a very simple setup for webchat. So in this section I will show you the steps involved in creating your first chat widget.

Note:
I will be using the “Omnichannel admin center”. If you are using the older “Omnichannel Administration App” your experience will be different. I do encourage you to use the “Omnichannel Admin Center” as that is the newer admin app and has more features than the old app.

Below you can see that I have opened the Omnichannel admin center. I have then selected the workstreams option. And clicked “+ New” to create a new workstream.

To create my workstream, I gave it a name. Next I selected the type of workstream as being messaging. And selected my channel as chat. (Web chat channel is preconfigured so I didn’t need to define anything “special” for that. With Facebook, Twitter and other channels you may need to first create your channel.)

I accepted the default work distribution mode which is push. Push means the chats will be routed to a queue and assigned to an agent. Then a notification will popup for that agent. This is the typical way we’d handle webchats.

My chat method was also left at the default which is live chat.

Once my workstream has been created I can open it and begin to refine any settings. As already mentioned I wanted to create a minimal / basic setup. So you will option see that I am going to simply accept the defaults. This isn’t a problem as I can come back and edit my workstream later to enable any features I skip at this point.

My first task will be to click “Set up chat”!

Clicking setup chat starts a “wizard” which guides me through the steps involved. This makes the setup process really simple.

First of all I will need to name my chat channel and confirm my language. Then I click next.

My next task is to define the look of my chat widget. I just accepted the default but you could decide to pick a theme colour or change the title on the widget at this point.

Also notice that I can decide how to display the agent’s name to customers. The default is full name but you can change this to be just first name or even the agents nick name.

Another option you could set is the one to “only show widget during operation hours”. It will be common to only present the chat widget to customers when you organization is open for business. So you will probably want to enable this option and define your working hours. The initial default will show the chat widget all of the time!

The only show widget on the provided domains option might help make your implementation more secure. As initially the code snippet generated will work from any domain. (If someone copied the snippet it can be triggered from anywhere!) You might therefore want to list your domains here to prevent the widget being triggered from outside of your control.

I clicked next again! Then my next set of options relate to the behaviour of chat. I could (for example) enable a post or pre conversation survey.

Below you can see that scrolling the screen down will uncover additional options! You possibly want to review all of the behaviours before clicking next!

Other options include the ability to alert the customer of their expected wait time.

It is also possible to show the customer’s location in the conversation summary when a chat starts. If we enable this feature the customer will be prompted at the start of the chat so they are aware that their location is being requested by our chat service.

Authentication settings can be entered for your portal. You’d use this option if you want to only offer chat to authenticated customers. One advantage of doing this would be that when the chat starts the correct customer record will automatically be associated with the conversation.

After clicking “next” again. I get a chance to define any additional features I’d like to enable. (You can skip them all and only enable them later if you’d like!)

File attachments allows us to enable a feature to give the customer and / or agent the ability to send files from the chat widget.

Customer notifications gives an option for the customer to receive notifications for incoming messages. (e.g. by playing a sound each time a new message arrives.)

Conversation transcripts allows the customer to obtain a copy of the conversation. This can be via a simple download option which is added into the chat dialog. Or via an email. If you opt to use the email approach you will also need to select a template to be used for the messages and define which email account the messages should come “from”.

We can optionally also enable voice and video calls. This gives the agent the ability to escalate a chat into a call.

Screen sharing and co-browse allow you to define a 3^rd party add-in to support screen sharing or chat. For example, ScreenMeet provide a co-browse add-in for Dynamics 365. I describe the process of enabling this advanced feature here.

Finally you will accept your settings and the chat widget will be ready to use. A code snippet is generated that will need to be copied and inserted into your website or Microsoft portal. I will explain the process for a Microsoft portal later in this post.

Code snippet (Portal Setup)

Once you have a code snippet for your chat widget you’ll want to embed this into the pages you’d like to enable for chat.

I’d already created a portal simply based on the customer service portal template. I did this as a trial portal just to test Omnichannel, you may already have a customized portal but the process would be the same!

So I opened “make.powerapps.com” found my portal under apps. Then in the portal settings I selected the “site settings” option.

Below you can see that within the portal management app I have then located a content snippet called “Chat Widget Code”. To enable web chat on all the pages in my portal I will simply need to add my code snippet to this.

Tip: You may want to enable chat on just specific pages or maybe you need different widgets for different pages in your portal. If this is the case instead of using the “chat widget code” content snippet you’d want to edit the web templates for each page individually.

Below you can see that I have simply added my code snipper into the “chat widget code” content snippet.

Tip: After you save this content snippet your widget should just start to show. If it doesn’t you may need to open your portal administration and restart your portal.

Pre-conversation survey

Having created your widget you may want to amend some of the behaviours or features. Such as adding a pre-conversation survey.

Below you can see that I have opened my workstream in the Omnichannel admin center. I can then see a summary of the currently defined behaviours and user features. To amend any of these click edit.

Below you can see that I have then found and enabled the pre-conversation survey option on my behaviours tab. Once enabled I can build my survey questions.

Each question has a type, with possible options including single line of text, multiple lines of text and option sets (drop downs).

I can also decide if a question is mandatory or optional.

The responses from customers in the pre-conversation survey maybe used to help identify customers. As when a conversation starts the system will search for contacts, accounts or even cases which match the answers. To enable this type of searching you’d need to add one or more questions with the following names. CaseNumber, Name, Email or Phone. Any of these fields would need to have an answer type of “single line text”.

Tip: Name, Email and Phone work with unauthenticated chat. Whilst CaseNumber could be applied to authenticated or unauthenticated chats.

After saving my changes my customers will now be presented with a pre-conversation survey.

Tip: Often when you makes changes in Omnichannel you will need to wait for up to 15 minutes for the change to take effect. So you might need to take a coffee break before your pre-conversation survey shows.

The information entered will help locate customer records and will also be visible to my agents from the conversation summary. You may also want to consider using the responses from customers in your routing logic. You can see below that my contact record was automatically linked to the conversation. Also the agent can see that I need help with a sales enquiry!

Note:
Post conversation surveys follow a different approach! As they use a survey created via Dynamics 365 customer voice. (Previously known as FormsPro.) I describe how a post conversation survey can be created in this post.

Proactive Chat

Typically the chat widget is presented to the user as soon as they arrive on a page. But we can also proactively offer chats to a customer. Common scenarios for this might be if a customer has waited on a page for longer than a certain amount of time or maybe they repeatedly visit the same page. We could even offer a chat if someone opens an existing case on the support portal!

Below you can see that I have offered a proactive chat when the customer has paused on a particular page for a long time.

Once “Chat Now” is clicked a chat will begin as normal. You can see below that my agents can see that the “proactive chat” value in the conversation summary is true. Meaning the agents can tell is the customer responded to a proactive chat prompt.

Enabling proactive chat is two step process. Firstly you need to enable it in your chat workstream and then make code changes to the webpage(s) that require proactive prompts. Below you can see that I have enabled the proactive chat option in my workstream. (On the chat widget tab.)

Once done I needed to add code into any webpages that required proactive chat. Lucky for me Microsoft supply some code samples that you can copy. (As anyone will tell you I am not a great coder!) You can check out their link here.

Below you can see that in my portal management I made a change to the web template for my portal’s support page.

Routing?

I have configured my chat workstream in the simplest way possible! You can see on my workstream that I have not defined any routing rules.

Routing rules can be used to ensure the correct chats are assigned to the correct agents.

For example work classification might show which skills an agent must have to answer conversations initiated from this chat widget. Or the route to queues option might define which groups of users should answer which chats.

As I haven’t defined any routing rules all chats will simply be directed to the default messaging queue. That might actually be fine for initial testing but you will probably want to define some routing logic.

I will cover how we can use Unified Routing to help effectively route our conversations to the correct agents in another post. For now I hope you have enough information around the creation of chats!