Tag: installation

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 for Dynamics 365 – Chat Transcripts

We’ve all been there (well, at least I have). We’ve been having an online chat with a customer service person at a company, and we’re wanting to have a record of the actual chat that took place. Of course we could (hopefully) copy and paste the entire conversation into a document and save it, but that would be laborious, and also potentially not be legal proof of the actual conversation.

In some cases, companies may actually encourage customers to save a record of their chat history on their account (as an example, Amazon offers this at the end of each chat). Customers can then return at a later date to download the conversation to their own computer at their leisure, which can be more convenient at times (say you’re travelling on holiday, and don’t have your own computer with you!). It could even be possible to get it automatically emailed to your own email address, which would also allow a company to add additional information to it (for example a feedback survey request on your chat experience, some marketing information, etc)

Well, Omnichannel has the ability for this, in multiple ways! It can allow a user to:

  1. Download a full transcript at the end of the chat
  2. Email a full copy of the chat transcript

Both of these features are available from the chat window using icons, allowing a quick and easy experience for the users. You can decide if you want to allow one or the other, or both, quite easily.

Enabling this is quite simple, though there are some additional options to set for the auto-emailing feature (basically selecting the email template and user mailbox – you can set up a specific mailbox to use if you’re wanting it eg ‘customerservice@abc.xyz’).

In the Omnichannel Administration Hub, open the Chat channel that you’re wanting to enable this for. Under the ‘Chat Transcripts’ section, select the option/s that you’re wanting to enable:

Downloading the chat transcript

At any time during the chat conversation, users can click the download icon at the bottom left of the chat window, and the conversation will be downloaded to their default Downloads folder on their computer.

This saves as an HTML file, and when opened looks like this:

At the end of the chat, the person will be prompted and asked if they’d like to save the conversation, with quick instructions as to how to do so. Obviously this option will ensure that the customer has the complete conversation, rather than just a part of it, so this reminder is really nice and helpful in my opinion

Emailing the chat transcript

Customers can also get the chat transcript auto-emailed to their email address. Clicking the email icon will prompt the customer to enter their own email address (or whichever email they’d like the chat transcript to be sent to).

This option allows companies to be able to format the email template that’s used for this. Examples of things that a company might want to do could include:

  • Using company logo’s, images and fonts
  • Feedback survey information, to understand how the customer felt about the chat session
  • Marketing material for upcoming events

Note: When setting up the ability for chat transcripts to be emailed, don’t forget to approve and test the mailbox being used in the Email Configuration settings! If you don’t do this (or it hasn’t already been done), they won’t be emailed out!

There’s also one further piece of configuration that needs to be carried out for emailing chat transcripts. As all emails from that chat channel will be using the same email address to send out the emails, this means that the ‘Allow send on behalf of’ option must be selected on the mailbox user’s personal settings. You’ll therefore need to log into Dynamics as the mailbox user, open personal options, and set this manually

In summary, this is really helpful to customers, and a great little feature for Omnichannel.

Omnichannel for Dynamics 365 – Skills Part III

The previous post in this mini series looked at how we go about enabling skill-based routing (https://thecrm.ninja/omnichannel-for-dynamics-365-skills-part-ii/).

What we’re now going to do is understand how we go about attaching skills (which we’ve already learned how to set up) to conversations. The premise behind this is that when a customer will access Chat on a website interface, they’ll be presented with one (or more) pre-chat survey questions. The answer/s that are given are then used as skills, and the chat session will be automatically routed to the user who is best placed to help the customer. This is done based on the skill-attachment rules, which we’re now looking at.

There are two types of options available for skill matching:

  1. Exact skill matching. The skill attachment logic looks for the exact skill/s and proficiency level that an agent should have to work on the conversation (and uses this as the minimum criteria). Then it searches for an available agent with these, to route the conversation to. If the minimum criteria aren’t met, then it searches for a higher proficient level. If no agent with a higher proficient level is found, then the conversation remains in the queue
  2. Closest skill matching. This initially works the same as the exact skill matching. The system will identify the skill/s and minimum proficiency levels, and see if there’s an agent available. If not, it’ll search for a higher proficiency level. All the same so far. But if there are no agents matching (or having a higher) proficiency level, it will look for any agents that are available with a lower proficiency level, and route the conversation to them

To create a new skill attachment rule, you’ll need to create (or modify an existing) workstream (we’re going to look at workstreams in another post)

Go to Skill Attachment Rules, select the type of matching logic that you’re wanting, and create a new rule (assuming you’re not modifying an existing one)

In the new rule window that opens, fill in the necessary information on the left hand side. You can then start to set up your rule conditions (and oh boy can these be complicated!) in the Condition box on the right.

Once done, hit the Save button, and the Skills section box will become active. Clicking the ‘New Attach Skill’ button in this box will allow you to select the skill/s and proficiency levels that you’re wanting to use.

Click the ‘Save and Close’ button, and it’ll appear in the Skills box. If you’re wanting to add more than one skill at a time, click the arrow on the Save & Close button, and click the ‘Save and New’ option.

If you then go back to the Workstream record, you’ll need see this appearing in the Skills Attachment Rules section.

Omnichannel for Dynamics 365 – Skills Part II

In the previous post, we started to learn how we go about setting up Skills for Omnichannel within Dynamics 365 (https://thecrm.ninja/omnichannel-for-dynamics-365-skills-part-i/).

In this post, we’re going to see how we enable Skill-Based routing within Omnichannel, as in order to use skills, we need to enable it! (seems obvious, right?).

To do this, we need to be signed into the Omnichannel Administration app, and we then go to ‘Skill Based Routing’, which is under the Settings area in the left-hand side navigation bar:

Clicking here brings up the skill-based routing settings. At the time of writing, this feature is still in preview, and shows an information window declaring this (this will disappear once it goes GA)

Clicking on the toggle slider will change the value to ‘Yes’, and will enable it. It’s also shown nicely in green, which is something that I’m really liking!

Select a Rating Model to use, from the right hand grid. As touched upon in the previous article, rating models are used to set how proficient a user is with a specific skill. You can have multiple rating models saved, and use them for specific scenarios.

Rating Models are made up of two parts:

  1. Rating Model (being the name of the rating model, and the minimum/maximum rating values allowed)
  2. Rating Values (the actual values being used – the number of rating values should be the same as the range for the Rating Model minimum/maximum that you’ve set)

In the next article (https://thecrm.ninja/omnichannel-for-dynamics-365-skills-part-iii/) we look at how we go about attaching skills to conversations

Omnichannel for Dynamics 365 – Skills Part I

We’ve already gone through and taken a look as to how we set up Queues (https://thecrm.ninja/omnichannel-for-dynamics-365-queues/) and Users (https://thecrm.ninja/omnichannel-for-dynamics-365-users/). The final part of this trio is looking at how we set up Skills in Omnichannel, and apply them (which is going to be in several parts, due to the complexity of this one item!)

As we’ve previously covered (https://thecrm.ninja/omnichannel-for-dynamics-365-queues-users-skills/), skills are used within Omnichannel to enable Skill-Based Routing.

There are several parts to getting this working:

  1. Setting up the actual skill entries
  2. Enabling/configuring skill-based routing
  3. Enabling/configuring the ability for chats to utilise skill-based routing

Yup – it’s somewhat more complex than just saying ‘I want skills!’

So this post is going to cover how to actually set up the skill record entries, which thankfully isn’t too difficult (especially if you’ve been bearing with me, and following the other setup instructions that we’ve been through so far).

To create skills, it’s necessary to have a skill type. Think of it as a hierarchy – if you’re wanting to provide customer services in multiple languages for technical issues, you’re going to want a Language skill type, and Technical skill type. Under each skill type, you’re going to have the applicable entries. So for Language, you’ll have English, Spanish, Chinese, etc.

At the time of writing, creating Skill Types are done from the Systems Customisation (this will likely move to the new Admin Centre at some point, but hasn’t yet). So make sure that you’re logged in as a Dynamics system Administrator, and open Advanced Settings:

Note: The process below is taking place in the default solution. It’s of course possible to deploy this as part of a custom solution – if you’re wanting to do this, then open the custom solution from the Power Platform admin centre, and continue with the steps shown below.

Hover over ‘Settings’ in the ribbon menu bar, and choose Customisations

Now select ‘Customise the System’

Select ‘Option Sets’ in the left hand navigation, then scroll down to ‘Bookable Resource Characteristic Type’ in the main window

Open up, and you’ll see the following window

Using our scenario, I’ve added Language and Technical Area as skill types. Now very importantly, ensure that you SAVE the record, and then PUBLISH it. If you don’t, the skill types won’t show to be used!

Right, now that we’ve done all of that prep work, we can get on with actually entering the skills that we want to use…

So, go back to the Omnichannel Administration section, scroll down in the left hand menu to Skills, and click it to open it. It’ll show all of the skills that we’ve entered (well, it won’t show any entries here yet, as none have been put in yet!). Click ‘New’ on the menu ribbon to create a new entry

You’ll be presented with the following screen, which after all of the above is thankfully quite simple.

The fields are as follows:

  • Name. What it says on the field – nothing complicated. It does need to be unique though, so have a careful think about your needs. You can always use multiple skills together to create a blend that you need across skills
  • Type. This is the Skill type (which we’ve just set up beforehand). If you don’t see the values that you’ve set up in here, make sure that you saved and published the customisations!
  • Description. Put something user-friendly in here to describe what the skill is (if you think it’s necessary…)

Then click ‘Save’ on the menu bar. Once the entry saves, the form will update, and now show a User (Agent) section:

You can now add users (agents, as they’re referred to) to the skill. Click the ellipse on the right hand side of the Users (Agents) grid, and then select the ‘New Bookable Resource Characteristic’ option (the names of these things just keep on getting longer and longer, don’t they!)

A nice simple window will open on the right of the screen, where you can enter the details:

This is done as follows:

  • Skill Value – this is the skill that you’re wanting to assign a user to
  • User (Agent) – this is the actual user. You can type to search through the available users. Very important to note that if you didn’t follow the steps to set up the user as a Bookable Resource, you won’t see them in this list (see https://thecrm.ninja/omnichannel-for-dynamics-365-users/ for instructions on how to do this)
  • Rating Value – this is used to rate the proficiency of the user at the skill. We’ll cover setting this up in a later post, but essentially think of using a 5 star scale. 1 would mean the user has basic ability at the skill, 3 would mean they’re alright with the skill, and 5 means that they’re at the top of their game with it

You can then click the ‘Save and Close’ button at the bottom of the window, and it’ll add them.

However if you have multiple users that you’re wanting to add, I’d HIGHLY recommend clicking the arrow next to this button, and selecting the ‘Save and Create New’ option. It’s not just to create with the same skill – you can change the Skill Value as well, and it’ll save you more clicks!

Hopefully you’re still following along, and managing to get the setup done correctly – well done!

Up next – enabling skill based routing( https://thecrm.ninja/omnichannel-for-dynamics-365-skills-part-ii/)

Omnichannel for Dynamics 365 – Users

Now that we’ve set up and assigned Omnichannel security role/s for the users in the system who need access to Omnichannel (https://thecrm.ninja/omnichannel-for-dynamics-365-security/), and seen how queues work (https://thecrm.ninja/omnichannel-for-dynamics-365-queues/), we’re going to look at how we manage users and the various pieces of information for them.

To do this, we need to be in the Omnichannel Administration application (accessed through the Dynamics 365 navigation bar), and select the ‘Users’ option under ‘Queues & Users’

If you hover over a user, you get a quite useful little window, showing their status and some details

Double clicking on the user will open up the system user record. The important thing to note is that there’s now an ‘Omnichannel’ tab available.

From here, it’s possible to set the users default presence (such as Available, DND, Busy, etc – you’re able to add new entries to this list) and capacity.

Capacity is a sort of loose term. Essentially (as we’ll cover in another post) it’s possible to set up different enquiry types. Each enquiry type will have a capacity against it, based on how complex you think it’ll be. So for example checking an order may have a lower capacity set against it than someone dealing with a damaged item.

Capacity is used with routing rules (which will also be covered in another post). When a communication channel is opened up, the system will check to see which agent/s are showing as available, and of those agent/s, which one/s have available capacity for the session (as they may be already dealing with other sessions at the same time).

You’ll also be able to see a list of the Queues that the user has been assigned to.

What you’ll now do is add a Bookable Resource record for the user. What is this exactly?

A bookable resource is anything that can be scheduled. Field Service uses this as well, usually covering people, equipment, and physical spaces (facilities). Each resource can have different attributes that distinguish it from others, including but not limited to:

  • Characteristics (eg Accounting)
  • Categories (eg Manager)
  • Territories (eg United Kingdom)
  • Organisational Unit (eg Customer Service)
  • Location (eg London)
  • Resource Type (eg User)

Omnichannel uses scheduling to know which users are available, assigned to specific queues, etc. Due to this, we need to create this ‘Bookable Resource’ record (which is unique – you can only have one of these for each user!).

To create this, scroll down the page, until you get to the ‘Skills Configuration’ section. Here you should click the menu ellipse, and select ‘New Bookable Resource’.

This will open the ‘New Bookable Resource’ window. Leave everything as it is, and just fill in the ‘Name’ field with the name of the user

Click the save button on the menu bar, and it’ll then take you back to the user record. Well done! You’ve now created the Bookable Resource record for the user.

In the next section, we look at how to start setting up Skills – https://thecrm.ninja/omnichannel-for-dynamics-365-skills-part-i/

Omnichannel for Dynamics 365 – Queues

In the previous article, we’ve taken a look at what Queues, Users and Skills are actually all about (https://thecrm.ninja/omnichannel-for-dynamics-365-queues-users-skills/)

We’re now going to look as to how we go about configuring these. In this post, we’re going to look at Queues.

Please note that there is a default Omnichannel queue that is created for each organisation.

This image has an empty alt attribute; its file name is image.png

This default queue can’t be deleted, not even by an admin! By default, all Omnichannel users are members of the default queue. Therefore, the membership of this queue can’t be changed

Amusingly the priority of this default queue is set to 2147483647! This is, of course, the maximum value that the field can hold.

The way that queue priorities work is that the lower the number, the higher the priority. So 1 is higher than 2, etc. Thankfully Microsoft realised that there could be situations where everything just went to the default queue even when custom queues had been created, and therefore did the extremely intelligent move of setting the default queue to be the lowest possible priority!

Creating a new queue is quite simple! Navigate to the ‘Queues’ option in the left hand navigation, click on it, and then click the ‘New’ button on the menu ribbon bar

This image has an empty alt attribute; its file name is image-1.png

You’ll be prompted to give the new queue a name, and set a priority. Fill these in, and then click the ‘Save’ button on the menu ribbon bar

This image has an empty alt attribute; its file name is image-2.png

Once the queue has been saved, the form layout changes to allow users to be added to the queue, by using the ‘Add Existing User’ button in the Users grid.

This image has an empty alt attribute; its file name is image-3.png

Adding one or more users here will mean that when queries come into this queue that’s just been set up, these specific users will be able to see and respond (other users will not be able to).

In this manner, it’s possible to easily control which users have access to specific queues, which can benefit the efficiency of the engagement

Please note that only users who have been enabled for Omnichannel (ie had the necessary security role/s given to them) will be available to be added here.

So if you’re trying to add a user who isn’t coming up in the search here, please check that they have the security roles given to them, as we’ve covered in the post at https://thecrm.ninja/omnichannel-for-dynamics-365-security/ (and of course that they’re correctly licensed!)

In the next post, we’ll be looking at how to set up and assign Skills.

Omnichannel for Dynamics 365 – Queues, Users & Skills

At the heart of Omnichannel for Dynamics 365 (apart from the actual communication channels, of course), are Queues and Users, with Skills alongside them. Lets take a look at what these actually are, and how they work.

Queues

Queues are really exactly what they sound like – they’re used to collect and distribute the (communication) workload amongst agents (users). All items coming in, such as Chats, SMS’s, Facebook conversations etc are automatically added to a queue (see more below about using queues to specialise). Agents (being the system users) are added as Queue Members to the queue, and then the workload within the queue is distributed amongst them (based on availability, capacity, etc).

It’s possible to use Omnichannel queues as proxies for specific skills or domains. For example, you can create separate queues for billing issues, investment issues, and so on. When a customer query comes for these issue types, it is automatically routed to its designated queue (as customer would select what they’ve wanting to communicate about).

With the new features of Power Virtual Agents, bots should be able to pick up on the type of query that’s being raised, and route it to the appropriate queue as well.

It’s also possible to assign priorities to queues. All conversations in a queue take the priority of the queue and higher priority conversations are allocated first. For example, if there are two chat conversations coming from two queues with priorities assigned as Priority 1 and Priority 2 respectively, the chat conversation with Priority 1 will be allocated to an agent first.

Users

Users are the actual people that handle and deal with the communications, through the various channels and methods that will have been set up within Omnichannel for Dynamics 365.

There’s a separate post that’ll be around how to set up users, assign security to them, and other necessary information.

Users can have skills set against them (see the Skills section below), and be assigned to be a part of one or more queues. Based on their availability status, workloads from the queues will be assigned to them, that they can then pick up and work with.

Skills

In a customer service centre, or across an organisation, agents (the users) will usually have different skills and abilities that they’ll use in dealing with customers. For examples, these could be language based (ie agents can converse in different languages), technical based (eg for a computer company, these could be desktop knowledge, laptop knowledge, server knowledge, etc), or service based (eg for a local council, this could be around council taxes, rubbish collections, voter registration, etc).

Customers reaching out to the company will have different needs, which will usually be identified in the initial reach-out.

Skill-based routing allows the distribution of the workload (ie the conversation) to agent/s who are skilled in the necessary area, and who are best qualified to handle and answer the situation. This in turn will improve the quality of the customer service, resulting in a better customer experience, which in turn will drive customer retention and loyalty.

It’s also possible to use skill-based routing for multiple required items. Using an example of a computer company, it’s possible to set up skill-based routing that will allow a customer to communicate to an agent who’s a subject-matter expert on servers that are running Server 2016.

Skill-based routing allows you to easily match the conversation to the agent most proficient in dealing with it while maintaining the workload of the agent. You can associate distinct skills with each agent on a team and create rules to make sure that conversations matching those skills are always assigned to them.

The next post (https://thecrm.ninja/omnichannel-for-dynamics-365-queues/) will take a look at how to set up Queues for Omnichannel.

Omnichannel for Dynamics 365 – Tenants & Environments

Well, to start off with, I wasn’t actually planning on writing this blog post – I was going to continue looking at the setup for Queues, but that’s going to have to wait until later on this week!

The subject of this post has come out of several conversations that I’ve been having with the lovely Tricia Sinclair on Omnichannel, who’s also extremely knowledgeable about Customer Service and DevOps.

This situation was regarding a company based in Australia. Their main tenant was set in the North America region (when you set up your tenant, you choose where the default should be).

They had also set up one of their organisations within the Australian region (ie not in their default tenant region), and were trying to install Omnichannel for it. However, they were running into an interesting error, and couldn’t get it to work, no matter what they tried to do.

In the end, the decision was taken to reach out to the Microsoft Product Team for Omnichannel, in order to try to solve the issue. Thankfully the product team identified the sticking point, which is actually a VERY important lesson to keep in mind when setting up Omnichannel.

The answer was that the organisation (environment) HAS TO BE in the same region as the tenant itself. Ie it MUST be in the default region. If it’s not, then it won’t be possible to set up Omnichannel!

Additionally the client also hadn’t followed the correct steps in granting consent (see https://thecrm.ninja/installing-omnichannel-for-dynamics-365-trial-part-i/ on how to do this), and hadn’t followed the proper procedure for installing Customer Service (see https://thecrm.ninja/installing-omnichannel-for-dynamics-365-trial-part-ii/ for how to do this correctly).

This hadn’t helped with troubleshooting the issue, as these needed to be carried out as well.

So in summary:

  • It’s vitally important to ensure that the Organisation is set up in the same region as the tenant default region
  • It’s also vitally important to carry out all of the installation/configuration steps correctly (as per the above links) to ensure a successful Omnichannel for Dynamics 365 installation