Omnichannel for Customer Service allows us to connect with a Virtual Agent. It is then possible to trigger a transfer to a human agent from within our topics / authoring canvas. But what if your customers are getting frustrated with a BOT that doesn’t understand them? In this post I will explain how we can use the “system fallback” setting to help with that scenario.

It may be common to construct a topic that allows the virtual agent to transfer the customer to a human. Maybe they enter an answer of “unsure” to a question and this could trigger the BOT to transfer to a human. (As I have shown below.) Or maybe you can have a topic of “human” that will transfer to a human if the customer enters certain key phrases. Like “I’d like to speak to a person” or “Can a human help me” etc etc.

But what if your BOT repeatedly does not understand what the customer is saying. (Or the customer doesn’t understand what the virtual agent is asking!) If you have ever experienced a BOT repeatedly saying “I don’t understand” you might know how frustrating this can be!

Imagine your virtual agent is asking the customer which colour they want. If the only options are “Red” and “Green” …. a customer asking for “Black” isn’t going to work. As an example I created exactly that scenario. Below you can see I am prompting for a colour and I have only added options of “Green” and “Red”.

Below is an example of the frustrating type of conversation which can occur. This is horrible as for the customer the loop will go on and on. Resulting in an upset customer. By the time they finally call to talk to a real agent they will already be annoyed. The BOT wants the customer to enter “Green” or “Red”. But this customer wants “Black”. The BOT tries hard by repeatedly offering an option it thinks is ok. But Red just isn’t want I want!

Note: This is just one example of many situations which could cause this type of problem. We could (and should) argue that your customers shouldn’t get stuck like this with a well-designed BOT! But in the real world we all know dead ends like this can (and will) occur.

Enable System Fallback

Luckily we do have a solution available to us! That being that we can enable a fallback topic which will be triggered if the BOT repeatedly asks the same question!

Below you can see that I can access the “System fallback” option from the settings cog on my virtual agent.

No we can add a fallback that will be triggered if the customer’s intent is unclear after two attempts.

You can see below that having clicked “+Add” a fallback topic has been created. I can now use the “Go to fallback topic” option to tailor it if required.

Below you can see the default fallback topic. Which you may want to tailor!

Now when I run the same test again you can see that eventually the virtual agent will transfer the customer to a human. Maybe that is still slightly frustrating but at least the customer isn’t stuck in a deadend.

I do advise you to try and avoid these “dead ends” in the first place. A design which avoids the situation in the first place has got to be the best option. But having a fallback for when everything fails also seems sensible to me. Enjoy!

Omnichannel for Customer Service and the Customer Service Workspace provide us an API where we can use JavaScript to control the behaviour of the multi-session experience for out customer service agent.

Below you will find a link to a video which explains the concept behind this API and gives one example of how we might use it.

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 review entitlements.

Below you can see an extract from the current skills measured statement that mentions entitlements.

Note: Microsoft do update these exams on a fairly frequent basis. Therefore I do encourage you to check the current skills measured statement to ensure you are aware of the latest information!

Entitlements are a “tool” to help companies manage the services they provide, this post will explain entitlements and how they are used to support service management within Microsoft Dynamics 365. Entitlements are effectively a definition of agreements between the customer and supplier for services to be provided.

Entitlements are used to define the amount of service to be provided (in terms of hours or numbers of cases), the service level to be applied and even what channels the service can be offered upon. It is possible to create a template for your entitlements, so let’s first look at those.

You will find two options connected with entitlements and entitlement templates in the service management area of the customer service hub.

Entitlement Templates

The first thing to note is that the use of templates is optional but they are available to help speed the process of creating entitlements. Using entitlement templates also enforces consistency.

When you create a new entitlement you can opt to create it from scratch or base the new record on an entitlement template.

There are several fields that are important to understand with regard to entitlements (and entitlement templates) as these govern how the entitlements behave;

Allocation Type– determines if the entitlement is based on number of cases or hours consumed.

Decrease remain on– this determines if the balance of support remaining should be decrementing based on cases created or cases resolved.

Total Terms– this is the total number of allocations allowed. (For example 100 cases or 50 hours of support.)

Restrict based in entitlement terms– This options decides if new case creation will be prevented if the entitlement limit has been reached.

SLA– If this entitlement is linked to a specific SLA then this can be defined here.

Note:
An entitlement template can include a start and end date, although typically these wouldn’t be used. As each entitlement created from the template will cover a different period.

You can also optionally define channel and product details within the template if required. These can be used to restrict the entitlement terms depending on the origin (channel) of the case. Or make it specific to services you provide connected with specific products.

Create new entitlements

Entitlements can optionally be created from an entitlement template, as I have already mentioned. It will therefore come as no surprise that the entitlement itself actually resembles the template. Although there are some differences, firstly the actual entitlement will be associated with a customer.

Tip:
There is a third method to create entitlements! As it is possible to create a new entitlement by renewing a cancelled or expired entitlement.

When creating an entitlement, you enter a name, customer as well as a start and end date. (Typically an entitlement will have a start and end date as it forms the contract between the supplier and the customer.) Plus you can associate an entitlement to an SLA. You can also define if this entitlement is the customer’s default entitlement or not.

Note: I will cover the detail of creating an SLA in another post as there is a specific section in the skills measured which relates to these.

As with the template you can define the allocation type (ie number of cases or hours) and number of allotments.

Another option (not available in the template) is the ability to restrict which contacts can raise cases against this entitlement. Useful if you need to tightly control who at the customer is allowed to log cases. For example: maybe only someone from their IT team is allowed to log support requests.

In addition to restricting support based on channel it is possible to limit support to specific products. As your customer’s could have their level of support restricted based on the product or service they have purchased.

Entitlements start off in a draft state and need to be activated. Note, that the entitlement does need to be activated before it can be set as the customer’s default entitlement. The “Set As Default” button does not show in the command bar for draft entitlements! This does mean if the default entitlement is deactivated, maybe because some details need to be amended, when the entitlement is re-activated the default status will have been reset. So you will need to remember to repeat the process of setting it as default.

Entitlement Channels

Channels are optional restrictions on the entitlement, used to limit the amount of support that is provided on a particular channel. You may, for example, limit the number of hours of support provided on the telephone.

Channels are the mechanism the customer used to raise the case. So channels might include email, phone, web portal or web, social media and even IoT. The channel is based on the origin of the case.

It is possible for the total sum of cases allowed on each channel to exceed the total allowed on the agreement. This may seem strange at first but is logical. You might allow someone to log a maximum of 100 cases. With a maximum of 100 being from email, and a maximum of 100 from web and 50 from phone. This doesn’t mean a total of 250 is allowed! The total is the maximum on that channel. So I can log a maximum of 50 on the phone leaving a balance of 50 that could be logged by email or web. (Or I could log none on the phone and log 100 on the web etc.)

Whilst this logic sounds confusing, if you think about it, the purpose is to try to drive customers to have a preference for one channel over another. So in the example I gave we are trying to encourage customers to email requests (or use web) rather than telephoning. This encourages a channel shift that might be very desirable in some situations.

Apply Entitlement to cases

As cases are created the default customer entitlement will be automatically populated onto the case. However, it is also possible to select an entitlement as you may have multiple entitlements for one customer. Maybe reflecting the different service agreements, you have with that customer. It is important to understand that each entitlement is always tied to a specific customer.

Also whilst working with cases the user can optionally decide whether or not to decrement the number of allotments. It might be that a case is raised for a very simple question and the operator taking the call applies some discretion and decides to not reduce outstanding balance of support on the entitlement. Even though you might opt to not decrement the allotment the case would still be associated with the entitlement. As this works well for later reporting of service provided under the agreement and also you may still wish to apply the SLA defined on the entitlement.

If the entitlement is set to restrict cases should the balance remaining on the entitlement reach zero then you will not be able to create any additional cases. One behavior on this you should be aware of is what happens if the balance remaining to decremented on case resolution. In this scenario, if a case is re-opened (unresolved) then the entitlement balance would increment. Giving one extra case that can be resolved.

Entitlements Lifecycle

As already mentioned an entitlement will start off life in draft mode. Only entitlements in a draft state can be amended. You then need to activate the entitlement to be able to start to “consume” the allotment by associating it with cases.

If you activate a contract that has a start date in the future its status will be set to “waiting”. It will then be automatically set to active on the start date. You can only set the entitlement as default once it is active (or waiting).

Once an entitlement has been activated (or set to waiting) it can’t be changed but you can deactivate entitlements at any point. (You must remember to reset as default once re-activated!)

Entitlements that are active or waiting can be cancelled. Once cancelled they cannot be changed and also cannot be used on new cases. A cancelled entitlement can however be renewed.

After the end date of the entitlement has passed it will automatically change to expired.

Cancelled or expired entitlements can be renewed. By selecting the renew button in the command bar.

Renewing an entitlement creates a new draft entitlement based on the expired one. The date range will automatically increment on the new draft entitlement. The draft can be changed before activating the new contract.

To help make this lifecycle clear I have attempted to draw the possible states below!

Note:
We can also deactivate entitlements at any point. This reverts them back into a draft state. (This might be useful if we want to amend an active entitlement and then activate again!)

I hope this post has covered all of the points mentioned for entitlements in the skills measured statement of the MB 230 exam. But as always I really encourage you to get some quality hands-on experience as port of your exam preparation.

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 review service level agreements (SLAs).

Below you can see an extract from the current skills measured statement that mentions SLAs. In this post I will try and mention all of the topics referenced in this statement;

Note: If you have worked with earlier versions of Dynamics 365 you might need to be aware that the April 2020 release included an updated approach to SLAs. One which leverages Power Automate flow. Therefore a little extra revision maybe need here for some people!

What is an SLA?

A Service Level Agreement (SLA) is simply a way of defining and tracking what should happen when a case is created (Or changed). It reflects the agreement between the supplier and client and establishes expectations of service delivery times. For example: For a high priority case resolution must be completed within 8 working hours or first response for a low priority case must be completed within two days of receipt. SLAs act not only as the agreement between supplier and customer but also as a KPI for the supplier to monitor performance levels.

Note:
I am going to talk about SLAs in context of cases but you may need to be aware that we can apply them to other tables. (Such as leads or custom entities!)

The completion of an SLA and therefore performance against KPIs is achieved by a definition of success and failure conditions, plus (optionally) if a warning should be triggered as a failure state approaches. The actions that should be taken at each stage can be defined, for example sending an email to a line manager if a failure state is approached. (With the latest version of SLAs the actions to be completed are actually controls using a Power Automate Flow.)

SLAs might be based upon the type of customer, the agreement which is in place with the customer, or on attributes of a specific case. (Such as priority or channel.) The service level agreement may also be associated with an entitlement.

It is important to know that your ability to create an SLA is dependent on your security role. Not all users will be (or should be) able to design their own SLAs.

SLA Setup

You can maintain SLAs from within the customer service hub. In the service management area you will find options to main the SLA KPIs and SLA agreements.

The SLA KPIs are the metrics you want to use to manage your SLA. Commonly on cases we’d want to manage when first response has been completed and when the case has been resolved. I will explain how to define these metrics later soon!

Tip:
You can also maintain entitlements from the service management area of the customer service hub. I have described entitlements in a previous post. I mention this as you might need to be aware that we can associate an SLA with an entitlement. This approach allows us to have specific SLAs for specific customers.

There are some additional SLA related settings you may need to tailor before creating your SLA. These include defining your companies holiday schedule, and one or more calendars. (These will be your customer service schedule.) Additionally you may need to review the service configuration settings as some define how the SLAs operate.

Service Configuration Settings

Using the service configuration settings option you can access the system settings that influence the behavior of SLAs and entitlements. In particular you will need to decide which cases status values should pause the SLA timer. In my example I have selected to pause the SLA if the case is waiting for details. Therefore if set to “On Hold” or “Researching” then the clock will continue to tick.

Configure one or more calendars

You configure your normal working patterns using the “customer service schedule” option. Below you can see an example of a basic Monday to Friday 9am to 5pm calendar. You might need to define several calendars. For example, your standard SLA might run Monday to Friday 9am to 5pm but selected customers might have an enhanced SLA which works on a 24/7 basis. You’ll need to define each of your required working patterns ready to apply to appropriate SLAs.

Notice below how I have said “observe” holidays. This means any non-working time defined in our holiday schedule will impact the SLA. So next I’ll look at holiday patterns.

Define Holiday Schedule

Using the holiday schedule option I have created an example holiday schedule. Notice that in the grey ribbon bar you can see the year.

Note: One limitation here is that holiday shutdowns are always whole days. Part days are not possible using this option.

Again you might need several holiday schedules. For example: maybe one area of the business provides support on Christmas Day, whilst most people take this as a holiday.

First I create a holiday schedule … as shown below.

Now I can create my shutdown dates for each year. (Notice the year is shown in the grey bar!)

Define SLA KPIs
The next setup step is to define my SLA KPIs.

SLAs can be applied to entities other than case but obviously I’m going to stick with case for this example. I’m going to want two KPIs. One SLA will be measured against first response, so how fast do I acknowledge a customer’s query. And the next will be based on resolution, so how fast do I fix the issue.

Below you can see that I’ve opened the service management area within my customer service hub. I have then opened the “SLA KPIs” option. Within this option initially I have no active KPIs.

Tip: Don’t forget after you create your KPIs they must be activated to be ready for use!

I created two SLA KPIs and activated them. One for first response and one for resolution. Below you can see that I’ve given my KPI a name. I then select the entity this KPI applies to, when it applies (SLA KPI) and based on what date.

The applicable from date is often quite important. In my example I want the SLA to start from the date the case is created. That will be quite common. But what is the priority on my case changes? In my example the SLA is going to be recalculated from the date the case was created, that might be fine. But in some scenarios you might want to use the date the case was modified or maybe even a custom field.

Tip: In real world scenarios I have often used a custom date field. As the case created date is when your customer service advisory originally clicked save on the case. Yet your SLA might actually need to start from the time a customer sent an email, which depending on your business processes and levels of automation could be much earlier than the case creation date. So having a custom date field that can be set to a time prior to the created date on the case can be a benefit.

Having added and activated my two KPIs my view of active SLA KPIs looked like this.

Create an SLA

Having correctly configured our calendars and other options we are ready to create an SLA.

In real-world scenarios the definition of an SLA can be quite complex. As often companies will have multiple scenarios to reflect. Additionally the actions required when an SLA reaches a fail or warning state can vary quite significantly. In the notes below I will show just one example of how an SLA might operate ….. please keep in mind that many other variations maybe required. I encourage you to setup multiple differing SLAs as part of your revision.

In the service management area of my customer service hub I can maintain service level agreements. (Shown below.)

Importantly notice that the default view of “All Service Level Agreements from Unified Interface”. This is because you could have SLAs defined in the older style classic web interface and / or SLAs from the newer Unified Interface. As the old style SLAs are really now a legacy concept, I will concentrate on the latest version!

When I create a new SLA, I first enter a name for my SLA, select an entity and optionally add a description. If you have multiple SLAs the description might be really useful to be able to understand the purpose of this particular SLA. Once the SLA is saved you will be ready to add your SLA Items.

As I add my SLA items I give each one a name. I also select which KPI the SLA item is based on.

The allow pause and resume lets me optionally decide if this SLA will pause. I might, for example, want to pause my SLA if the case is put on hold because I am waiting for information from my customer. I define which status will pause SLA in the system configuration settings. (See note at the end of this section!)

Importantly I next select my business hours. If I don’t my SLA will apply 24/7 365 days per year. But If I want my SLA to follow my normal working week and to take business closures into account then I’ll need to define / select a calendar.

Next I will select when this SLA is applicable. In my example I have decided to have two SLAs. One for cases of normal priority and a shorter one for cases of a high priority. (Low priority cases will have no SLA!)

I also define the success condition. For “first response by” success might be that the field “first response sent” has been set to yes. For my “resolve by” SLA, then success might be that the case status has been changed to “Resolved”. (and maybe “Cancelled” as I’d also stop the SLA if the case was cancelled!)

You can see that I then define my warn and failure times. I might for example, have 8 hours to give first response on a normal case. But maybe only 2 hours on a high priority case.

Note: You may notice that the actions section doesn’t show! Actually after I save the SLA item I will get a configure actions button. That will allow me to maintain my Power Automate. (More on that in second!)

You can see below that I defined four SLA items. Two for first response and two for resolve by.

Note: A note here about my warn and failure times might be useful! They are easy to visualise if you work 24/7. As one day would literally mean I just resolve the case by tomorrow. What if I only work 8 hours per day and “just” 5 days per week. Then 24 hours (aka 1 day) would mean I have 3 working days to resolve the case.

Tip: I like to think of my SLAs always in terms of the number of working hours I’m allowed to complete the task. If you always enter them as hours the system will convert to days (and fractions of days) automatically.

Note:
Below you can see that in the service configuration option. In this I can define which case status values will pause my SLA. Along with some other SLA related system settings!

Amend Power Automate

On each of my SLA items I have a “Configure Actions” button.

Clicking the configure actions button will open Power Automate and drop me into a template Cloud Flow.

First of all you will click “continue” to connect this Power Automate with your Dataverse. Your Power Automate will then look something like mine below.

Importantly, notice that some elements of the Power Automate include “Do not delete or update” in their description. Guess what, you don’t edit these bits!

But you can expand the switch condition by clicking on it and then start to add actions for each status. (Below you can see that I have options for near noncompliance (aka warn), succeeded and non-compliance.)

Tip: The switch condition also includes a default option. This might be useful as would be triggered when a case is first created. You could additionally add actions to that!

The actions that you decide to add into your Power Automate Flow could do many things! Common examples would be to send an email to alert the case owner that the SLA was about to expire or had failed. For the purpose of this post I will have a simple example that just updates a field on the case.

In my simple example I want to update a field on the case to amber on warn and red on failure. So I have added an update record step. This is connected to my current environment, the entity is cases and the record identified has a dynamic value of “Regarding ID”. This is the ID of the record connected to this SLA instance, so in my example my case.

I have then scrolled down and set the desired field on my case. So for me that means my RAG field. (Note: This is a custom field I created, your SLA will no doubt have different steps to mine. This is just an example!)

Once I save this Power Automate, my cloud flow will be added into my default solution. You might need to be aware of this as you’ll probably need to add the Power Automate into your own solution, assuming you need to migrate them from say a dev instance into production.

Using the SLA
After I had created all of my SLA items and their associated Power Automates (aka Cloud Flows) I am ready to activate / test my SLA.

Keep in mind that this is a simple example! I have only two SLA items listed in the SLA Details section. It might be that each priority / type of case has a different first response and resolution timescale. Therefore, I hope you can see that SLAs could get quite complicated!

So first you need to activate my SLA and also then set it as default.

SLA’s can be applied to a case in one of three ways;

• When the SLA is the default SLA all new cases will have that SAL applied.
• When the user manually assigns the SLA on the case. Using an SLA lookup column we can add to the case form.
• By virtue of associating the case with an entitlement that is linked to an SLA.

I created a case and you can see that initially I have 2 hours to complete my first response.

On the SLA tab you can see the details for my first response and resolve by KPIs.

If my SLA conditions are met the status will change to succeeded, below you can see that I have sent my first response!

Alternatively if you do not complete the SLA in time you will see the status change into a warn and eventually fail state. Before you can see that I have a “SLA warning” as my SLA is nearing expiry.

I mentioned earlier that you could pause an SLA. Below you can see that my case has been set to waiting details. Doing this has paused the SLA timer. Setting the status back to “In Progress” would restart the timer, With the target failure / warning times adjusted to allow for the length of time the SLA was paused.

Hopefully this post will have given you a good overview of the capabilities of service level agreements. As part of your preparation for the MB 230 exam I encourage you to gain some hands on experience of using SLAs.

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 cover some of the concepts of setup needed before you can schedule your resources and services.

Below you can see an extract from the current skills measured statement for the MB 230 exam. You can hopefully see that scheduling is firstly a significant section of the exam and also that it covers numerous topics. Meaning this post is one of several that I will create to cover all aspects of scheduling. In this post I will cover the initial configuration and setup required.

Before you can start to schedule items using customer service scheduling there are several things you must first ensure are defined. As these are essential to be able to effectively schedule work.

When assisting an organisation to configure service scheduling asking loads of questions which may help define / refine the required setup. Some examples are below;

What services do we need to schedule?

    Do our services require multiple resources?

    So our service require different types of resources? (e.g. sub-contractors, equipment etc.)

What does an unscheduled item “look like”?

    Does the service activity need to go through multiple statuses or stages before it is scheduled?

What does a scheduled item look like?

    Is there a difference between the item being “just” schedules and when someone is actively working on it?

    Do the resources need to take breaks?

What factors can impact scheduling of a resource?

    Is out organization split into service areas? (e.g. North / South)

    Where will the service be executed?

    When will specific types of resources be required?

Organizational Units

Organizational units are used to group resources together. Often are organizational units will reflect the physical locations that the resources operate from. Maybe a company has regional service centres in the North and South. When this happens it will be common to schedule a particular requirement from just one organizational units.

Below you can see that I have used the “Organizational Units” option within the scheduling area to define my organizational unit.

Notice below that on the scheduling tab I have entered the latitude and longitude for this unit. This information is essential to be able to show the organizational unit on maps within the schedule board.

Tip: As there is no address input and automatic lookup of the lat/long information I used a website to help me find a suitable setting. https://www.latlong.net/

Business Closures

Each resource will have a calendar / working pattern. But you may also need to define a set of business closures that will aid scheduling. For example, if you company is shut on Christmas day and New Years day you may need to reflect these as business closures so that no bookings are accidently scheduled on these days.

Below you can see I have opened the business closures option from the settings area of scheduling. First of all notice the grey bar containing the year, you can sue this to scroll forward or backward as required.

We then use the “New” option to add closures as required.

For each closure we define several fields;

Name – a description of the closure reason.

All day event – Set to “yes” if the closure is all day. But you can enter “no” and define a closure of “n” hours if required.

Start time – The start of the closure.

End time – The end of the closure.

Below you can see that I have defined “an important” business closure date. Notice that this is a one day event but seems to start a day early! This is because the shutdown is actually running from midnight on one day until midnight on the next day.

Note: Later when you define resources we have an option to observe or not observe business closures. Say you have an engineer that provides 24/7 on call support, then that engineer will probably not observe business closures. Whilst other engineers who have a “normal” working pattern would observe closures.

Resource Categories

Resource categories allow us to group our resources by roles. These can be useful when scheduling as we can easily select a particular type of resource.

For example, I a software consultancy may have may different types of resources. Including developers, consultants and more.

Below you can see that I have used the resource categories option to define a number of resources.

Notice that for each resource category we can also associate the required skills and proficiency level resources holding this role will be expected to have.

Facilities and equipment

In addition to scheduling “people” it maybe common to need to use facilities and equipment. One classic example is an car repair company, as any service will require a free service bay (facility) or maybe a particular diagnostic tool (Equipment).

Facilities and equipment can be associated with resources and scheduled as part of services scheduling. When we create a facility/equipment record, we define the name, organizational unit and time zone of the facility / equipment. Additionall a description can be entered to describe this item.

The working hours tab allows us to define the working pattern of the facility to euqipment. It might be that a piece of euqipment is always available. But you will find examples when this isn’t always true. For example, a training room may only be available on certain days or times. A training room (for example) may also have a capacity.

In this post I hope I have covered some of the key setup items that need to be created before we begin to use service scheduling. As part of your MB 230 revision I suggest you experiment with these options creating some organization units, facilities etc. In later posts I will explore how these settings effect the definition and scheduling of our services. Enjoy.

Within Dynamics 365 we can use Omnichannel for Customer Service to present chat widgets to customers. The typical way of doing this is to “simply” have widget show when a customer visits a website / portal page. But what-if we want to proactively prompt the customer to start a chat? Maybe they have paused on a particular page for a long time … something like that might act as a good trigger to prompt them to engage with your agents over webchat.

Lucky for us …. Omnichannel for Customer Service does include a proactive chat option. In this post I will describe that feature.

As mentioned, 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. This dialog popping up seems more compelling that just saying “Let’s Chat!”. And we can also tailor the messaging as maybe we’d want it to be in context with the page the customer is viewing.

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.)

Note:
I am using the “Omnichannel Admin Center”. If you are using the older Omnichannel administration app then a similar setting does exist. The screens will just look a little different from the ones shown below!

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 code samples here here.

Below you can see that in my portal management I made a change to the web template for my portal’s support page. I simply pasted in some sample code from Microsoft and tweaked the time to wait before the message showed.

I could have (and maybe should have) also amended the message that will be shown to the customer.

I hope you agree that altering your chat widgets to be proactive may prove a useful way to better engage with customers. Despite not being a coder I found implementing this feature was pretty straight forward. And I’m sure some who really understands portals / code would be able to implement some really creative ways to proactively offer chats to customers. Enjoy.

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 cover concepts around creating resources and services.

Below you can see an extract from the current skills measured statement for the MB 230 exam. You can hopefully see that scheduling is firstly a significant section of the exam and also that it covers numerous topics. Meaning this post is one of several that I will create to cover all aspects of scheduling. In this post I will cover the important topics around defining your resources and services.

Before you can schedule anything you are going to need to define the services your organization offers. And also define the resources needed to execute those services.

Bookable Resources

Bookable resources are the people, facilities or equipment that are needed to execute a service.

Unified Resource Scheduling (URS) handles scheduling across all of the Dynamics 365 applications that may include elements of scheduling. Meaning any defined resources will be available in customer service and also other applications such as Field Service. We have the following resource types;

User – a resource is mapped to an internal Dynamics 365 user record. This is a common type of resource as these are the people who will deliver the services.

Generic – used as a place holder to define the type of resource needed. A specific named resource would then replace a generic resource at a later date. (Typically I have used this type of resource in connection with the Project Service App. A project management application!)

Contact / Account – very similar to a user resource but instead of mapping to a system user record these resources can map to user or account records. (Possibly useful when planning work for sub-contractors who are external to your organisation.)

Equipment – Defines the resource as a piece of equipment.

Facility – used to represent a building or room.

Below you can see I have created a resource of type user and associated this with my user record.

Note: Ensuring the corrorect time zone and location is entered on the general tab maybe significant as these can influence how the resource shows on the schedule board.

Depending on the additional applications you have installed one or more tabs may show with additional parameters specific to that application. Below you can see that I have “Project Service”, “Field Service” and “Omnichannel” installed. All of which share this same bookable resource record.

The scheduling tab (shown below) contains some additional parameters which are common to all the applications using URS.

Start / end location – if locational data is significant we can define if the resource will start (or end) work from their address or their organizational unit.

Organizational unit – Each resource will be linked to one physical location via the organizational unit.

Display on schedule board – You can decide if this resource should be visible on the schedule board using this option.

Enable for availability search – this option lets us decide if this resource will be included in the availability searches which maybe completed using the scheduling assistant.

Tip:
We can set the resource start and end locations as “location agnostic”. Meaning the resources do not have a defined start / end location. Also, if locations aren’t important then the start and end location will probably be defaulted to organizational address.

We can use the related option to view the characteristics (skills) of this resource. In addition to defining the resource we can also define a rating value to demonstrate the resources proficiency.

Under resource category associations we can see any roles (aka resource categories) which have been associated with this resource.

The show work hours option can be used to define the working pattern for this resource. (For example, Monday to Friday 9am until 5pm.) We can also flag on off periods of non-working time or time off.

As we define a working pattern we can define the capacity of a resource. (Typically for people this will be “1” but a facility (e.g. a meeting room) could have a larger capacity.)

We can also flag if the resource will observe business closures or not.

Tip: You could also add break times, like an hour for lunch if required.

Note:
Facility resources are useful when you need to reserve a physical space, such as a room for an event. Or if you need to schedule an appointment with a person at a facility, for example an appointment an a health clinic. As facilities as physical locations their start / end locations must always be the organizational unit address.

Services

Services define the schedulable work that can be performed for a customer. Such as servicing a car or upgrading a PC, cutting someone’s hair etc.

As shown below we first end a name and description for the service. We can also define the state the booking will first show as on the schedule board. (As in, requested or tentative.)

Having saved the service we can use the resource requirements tab to define the resources needed to deliver the service. As each service may require different types of resources.

We can also group the required resources. This helps the dispatchers schedule an entire team (group) of resources for the single service activity. Groups can be useful if multiple technicians are required or maybe combinations of technicians and equipment.

It is also possible (if required) to define multiple groups of resources. This might be done when multiple combinations of resources would be an acceptable solution. When defining resource groups we can opt to specify that all or any of the resources are needed to fulfil the requirement. All, meaning all of the resources defined in the group will be required. Whilst any means that only one of any of the list resources will be required.

Below you can see that I have created a resource group that I have renamed to be called “My Group”. In my simple example I have then added a requirement. Once I have added my requirement I can add any requirements. Such as under resource categories I have shown the that the resource will need a “role” of developer.

Next to my group I have also defined a duration of 4 hours and flagged that all the resources must come from the same organizational unit.

Tip: I have shown a very simple example below. As part of your revision I suggest you start off simple. But once you have scheduling work I encourage you to experiment with more complex scenarios.

One option you should experiment with is the sort option! This gives me several options that will help decide how resources are presented in searches.

• None – no sorting is applies.
• Randomize – presents the available resources in a random order.
• Most busy – presents the resources with the most bookings first.
• Last busy – presents the resources with the least bookings first.

Tip:
You can deactivate services if they are no longer required. This will make it unavailable for future bookings. B UT … you can only deactivate the service if there are no open or schedules service activities associated with the service.

Hopefully this post has given you an introduction into some of the concepts around creating resources and services. You will no doubt (hopefully) now understand that we have quite a few options! You may need to create multiple resources and services as part of your revision to experiment with the many scheduling concepts. My tip is, start off simple and once you have scheduling operating gradually add more resource / services to experiment with more and more features. Enjoy.

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 cover the schedule board.

Below you can see an extract from the current skills measured statement for the MB 230 exam. You can hopefully see that scheduling is firstly a significant section of the exam and also that it covers numerous topics. Meaning this post is one of several that I will create to cover all aspects of scheduling. In this post I will cover concepts connected with the schedule board.

Note: The schedule board is graphical in nature! Meaning I strongly encourage you to get plenty of hands on usage with the schedule board as part of your revision. Reading theory alone will probably not give you an adequate appreciation of its operation.

The schedule board is the tool we use to display details of all our resources and their associated bookings. We can also view unscheduled service activities and schedule them directly from the schedule board.

In addition to seeing the bookings for a resource I can also open their resource card. This allows me to see additional information about their skills and roles. Plus I contact the resource directly from here, I can (for example) click the mail icon to send them an email directly from the schedule board.

A percentage shows against each resource as bookings are assigned. The is based on the resources capacity for the date range being used on the board.

At this point I will flag that we currently have two versions of the schedule board. Something that could be different by the time you are reading this post!! The old board will probably be the experience you first see. (And is shown in the screen shot above.) However we can switch to an improved schedule board. At the time of writing this post I do favour the new board but it has not yet reached feature parity with the old board. You may therefore find you need to use the old experience in some circumstances. The new style board is shown below.

Regardless of which board you use I encourage you to become familiar with the various view and filtering options. Often we will plan at a detailed level working on an hour by hour basis. But you can change this to see the board in terms of days, weeks or even months.

The default will be to show the resource horizontally. But you can change this to a vertical view. Or use the map view to see your bookings on a map. (Assuming they are location aware, not all bookings will be completed onsite!)

We can also advance the date range shown on the schedule board as required. (You may need to review historic bookings, who went to that job last week? Or maybe you need to move forward in time to create an advanced booking.)

The actions menu provides a list of useful actions. The actions include;

• Get driving directions
• Move booking to a different day
• Print schedule board
• Create booking alert

Making a Booking

We can use the book option to book an service activity.

Below you can see that I have selected an unscheduled service activity from my requirements panel. I can now click the book option and enter the details as required.

Note: In my example I am only showing unscheduled service activities. But if you have other Dynamics 365 applications installed you may see additional tabs for other types of work items. For example, when using Field Service you will also see a tab for unscheduled work orders.

Note: You may also need to be aware that you can tailor the views displayed in the requirements panel.

Scheduling Assistant

We can also access the scheduling assistant directly from the schedule board. This might be useful as the scheduling assistant will use out fulfilment preferences to suggest possible bookings.

We load the assistant by using the “Find Availability” option, shown below.

Once the find availability option has been selected possible booking options will be presented. Selecting one of the options will open a side panel that will allow us to complete the booking as suggested.

Filters

The filters pane allows us to filter the displayed resources. This can be on many fields including territory, organizational units, roles and more.

Having entered the required filter options the dispatcher will click search and the results on the schedule board will adjust.

It will be common that each dispatcher will define a set of default filters that will become their initial view. As it will be common for each dispatcher to work with a given set of technicians, territory or maybe role. The “Options” button allows the dispatcher to save the current filters as their default. They can also use the select resources option to “tag” specific resources they would like to include in their view.

Details Pane

You may use the details pane to view additional information about the selected booking. Including its status and also links are provided to the originating service activity.

Multiple Boards

In complex scenarios each dispatcher may want to create multiple schedule boards. Maybe, for example, they look after multiple organizational units and benefit from seeing these in separate views.

Below you can see that I have used the “+” icon to add a second schedule board. Each board could then be filtered differently as required.

Also notice that as I create the board (or afterwards from the settings cog) I can define many settings. For example, within these settings I can define what views are shown in the requirements panel. Meaning I could create a view specific to each board if required.

I suggest you experiment with creating additional boards and tailoring which views are shown.

I hope I have described the key elements in the schedule board. But as I mentioned at the start …. Using the schedule board is a graphical experience so I encourage you to experiment and spend plenty of hands on time becoming comfortable using and tailoring the boards. Enjoy.

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 give an overview of service scheduling.

Below you can see an extract from the current skills measured statement for the MB 230 exam. You can hopefully see that scheduling is firstly a significant section of the exam and also that it covers numerous topics. Because of this I will not cover the full detail of scheduling in one post! This post will be an introduction covering the key concepts, later posts will dive deeper into the themes raised.

Overview

It will be a common requirement to schedule service based activities, for example scheduling the repair or installation of equipment. Sometimes this will involve scheduling work that will be completed at a customers location. Other times the scheduling will be for services to be performed at service locations. (Such as booking your car in for a service at a garage.)

Dynamics 365 includes a feature called Universal Resource Scheduling (URS) which provides an ability to schedule resources in many circumstances.

URS concepts are actually shared between other Dynamics 365 apps beyond customer service. For example, scheduling of work orders in the Field Service app leverages URS. Meaning we have the same schedule board capabilities in Field Service and Customer service.

Whenever we want to schedule something it is important to understand want needs to be done, what is needed to accomplish “it” plus who is capable of and available to complete the task.

Scheduling within customer service involves two components which allow us to define what is to be scheduled and also what resources are required to completed it;

• Service– these define what an organization is offering to their customers. A service might be a definition of a car service or maybe treatment at a beauty salon. The service record defines how many resources are needed to complete the task. Importantly you may need to be aware that a resource can be a person but also equipment. For example, a car service will need a mechanic to complete the service but other physical resources such as a service bay would also need to be available.
• Service activities– each service activity represents the delivery of a service to a customer.

Services and service activities are used together to define what needs to be done, how it needs to be completed and when will to be done. When we schedule a service activity Dynamics 365 will use URS to look at the resourtce requirements associated with the service and identify which people, facilities and equipment are available to complete the activity.

Scheduling Overview

URS provides the solution that allows companies to schedule service activities. (and other entities.) It provides the core scheduling functionality, which can be leveraged in Customer Service scenarios and other Dynamics 365 apps. (Such as Field Service.)

Three core tables are creates as we schedule items;

1. The item to be scheduled. This could be a service activity in customer service, a work order in Field Service or other entities.
2. Resource requirements. based on the service these define what need to be completed for the item to be scheduled.
3. Bookable resource booking. A bookable resource booking (catchy name!) is a booking against a resource requirement for a suitable resource. The bookable resource requirements will be defined based on the selected service.

Item to be scheduled

We may begin with a service activity. This is the item to be scheduled and include a definition of the service to be provided, what customer needs the work to be done and any scheduling preferences. (Including delivery time windows, preferred technician and more.)

Resource Requirement

When the service activity is created, a resource requirement is also created. This defines the details required to schedule the activity. URS uses the requirement record to identify suitable qualified resources. Requirements for a service activity might define the type or resource required, the service centre, any resource preferences and additional scheduling constraints.

Bookable Resource Booking

Bookable resource booking records are created as a resource requirement is scheduled. This provides specific details of the resource responsible for delivering the service activity. This could be the person responsible for completing a work order in Field Service. But it could also refer to a booking for the physical equipment required to complete the task. The resource booking will reflect the estimated (or actual) time to complete the task.

Scheduling Components

As part of your revision you need to become familiar with the components / terms relating to the various components involved in scheduling.

The items can be split into three groups.

Scheduling components– these are the components required to complete the scheduling process

Tools – these are the features to be used to schedule the components. (e.g. the schedule board.)

Settings – these are the configuration options which support the process of scheduling the components.

Scheduling Components

Scheduling components include;

Tools

The schedule board is our primary tools for scheduling. It is an interactive calendar used to schedule specific items of work. The board can be filtered as required. Additionally scheduled items can be views on a map.

Settings

The settings area will define any additional parameters which impact scheduling. For example;

Organizational units – used to represent “containers” that group resources together. Often an organisational, unit might reflect a physical location that resources operate from. For example, a company with a Southern and Northern office may commonly have two organizational units defines. (One for each service location.)

Business Closures – These maybe used to define when the company is not open. For example, public holidays like Christmas day etc.

I hope this overview has given you an initial introduction into the key elements involved in the scheduling process. In future posts I will expand on these concepts in an attempt to cover all of the aspects you need to revised for the MB 230 exam. As always, please keep in mind that hands on usage of the system is essential. Meaning you should actually create resources, services and service activities. Plus then schedule these to appreciate how the schedule board operates. Enjoy.

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 cover some of the concepts of setup needed before you can schedule your resources and services.

Below you can see an extract from the current skills measured statement for the MB 230 exam. You can hopefully see that scheduling is firstly a significant section of the exam and also that it covers numerous topics. Meaning this post is one of several that I will create to cover all aspects of scheduling. In this post I will cover the initial configuration and setup required.

Before you can start to schedule items using customer service scheduling there are several things you must first ensure are defined. As these are essential to be able to effectively schedule work.

When assisting an organisation to configure service scheduling asking loads of questions which may help define / refine the required setup. Some examples are below;

What services do we need to schedule?

    Do our services require multiple resources?

    So our service require different types of resources? (e.g. sub-contractors, equipment etc.)

What does an unscheduled item “look like”?

    Does the service activity need to go through multiple statuses or stages before it is scheduled?

What does a scheduled item look like?

    Is there a difference between the item being “just” schedules and when someone is actively working on it?

    Do the resources need to take breaks?

What factors can impact scheduling of a resource?

    Is out organization split into service areas? (e.g. North / South)

    Where will the service be executed?

    When will specific types of resources be required?

Organizational Units

Organizational units are used to group resources together. Often are organizational units will reflect the physical locations that the resources operate from. Maybe a company has regional service centres in the North and South. When this happens it will be common to schedule a particular requirement from just one organizational units.

Below you can see that I have used the “Organizational Units” option within the scheduling area to define my organizational unit.

Notice below that on the scheduling tab I have entered the latitude and longitude for this unit. This information is essential to be able to show the organizational unit on maps within the schedule board.

Tip: As there is no address input and automatic lookup of the lat/long information I used a website to help me find a suitable setting. https://www.latlong.net/

Business Closures

Each resource will have a calendar / working pattern. But you may also need to define a set of business closures that will aid scheduling. For example, if you company is shut on Christmas day and New Years day you may need to reflect these as business closures so that no bookings are accidently scheduled on these days.

Below you can see I have opened the business closures option from the settings area of scheduling. First of all notice the grey bar containing the year, you can sue this to scroll forward or backward as required.

We then use the “New” option to add closures as required.

For each closure we define several fields;

Name – a description of the closure reason.

All day event – Set to “yes” if the closure is all day. But you can enter “no” and define a closure of “n” hours if required.

Start time – The start of the closure.

End time – The end of the closure.

Below you can see that I have defined “an important” business closure date. Notice that this is a one day event but seems to start a day early! This is because the shutdown is actually running from midnight on one day until midnight on the next day.

Note: Later when you define resources we have an option to observe or not observe business closures. Say you have an engineer that provides 24/7 on call support, then that engineer will probably not observe business closures. Whilst other engineers who have a “normal” working pattern would observe closures.

Resource Categories

Resource categories allow us to group our resources by roles. These can be useful when scheduling as we can easily select a particular type of resource.

For example, I a software consultancy may have may different types of resources. Including developers, consultants and more.

Below you can see that I have used the resource categories option to define a number of resources.

Notice that for each resource category we can also associate the required skills and proficiency level resources holding this role will be expected to have.

Facilities and equipment

In addition to scheduling “people” it maybe common to need to use facilities and equipment. One classic example is an car repair company, as any service will require a free service bay (facility) or maybe a particular diagnostic tool (Equipment).

Facilities and equipment can be associated with resources and scheduled as part of services scheduling. When we create a facility/equipment record, we define the name, organizational unit and time zone of the facility / equipment. Additionall a description can be entered to describe this item.

The working hours tab allows us to define the working pattern of the facility to euqipment. It might be that a piece of euqipment is always available. But you will find examples when this isn’t always true. For example, a training room may only be available on certain days or times. A training room (for example) may also have a capacity.

In this post I hope I have covered some of the key setup items that need to be created before we begin to use service scheduling. As part of your MB 230 revision I suggest you experiment with these options creating some organization units, facilities etc. In later posts I will explore how these settings effect the definition and scheduling of our services. Enjoy.

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 cover advanced scheduling concepts.

Below you can see an extract from the current skills measured statement for the MB 230 exam. You can hopefully see that scheduling is firstly a significant section of the exam and also that it covers numerous topics. Meaning this post is one of several that I will create to cover all aspects of scheduling. In this post I will discuss some of the advanced scheduling concepts such as fulfilment preferences, rescheduling service activities and more.

Fulfilment preferences

We can use the schedule assistant to find availability from the schedule board or via the book option directly on service activities. Without any fulfilment preferences the schedule assistant will “simply” display results based on resource schedules and their earliest availability.

Often a booking will be suggested exactly at the next available time. Meaning if the assistant is run at 9:37am, then a time slots starting exactly at 9:37 maybe suggested. Often time slots using “rounded” time values would be preferrable. It may be easy for the customer and the dispatcher if a job was booked for 9:45am or 10am, rather than 9:37am.

Also, we may often want to limit the number of appointments per time slot (or interval). As booking back to back appointments might seem efficient but it gives no margin to allow for overruns, late running, longer than expected travel times etc. Therefore booking in intervals can help to create a plan which is more achievable.

URS includes fulfilment preferences that allow us to choose how the schedule assistant results will be displayed. This can include two features;

• Intervals – intervals display schedule assistant results in time slots that dictate the start time of subsequent jobs.
• Time groups
  – allow schedulers to search / view options as blocks of time. Often this could include morning / afternoon bookings or 2 hour windows etc.

Intervals

Below you can see that if I try and book a 30 minute service activity, the schedule assistant is offering appointments literally every 30 minutes.

This might be find but what if I only wanted to book one appointment per 2 hour interval. Then this approach would not be correct!

Below you can see that I have created a “2 hour interval” using fulfilment preferences. Now for the same 30 minute job slots in blocks of 2 hours are offered.

To define a fulfilment preference to achieve this I used the fulfilment option. Below you can see that I have given my preference a name of “2 hour intervals”.

Next on the intervals tab I have stated that I want to have a 2 hour interval. And that my intervals will begin from 9am in the morning. I can also optionally restrict the number of results per interval that are offered to the dispatcher. If you have a large number of resources this might be a useful way to help the dispatcher work with a shorter suggested list.

Tip:
If you limit the results you might want to think about the sorting logic applied on the service’s requirements. As suggesting the least busy resources first (for example) might become a useful tool to ensure you achieve the desired resource loading.

We can now edit the service definition. In the resource requirements tab you can add your fulfilment preference to the requirements.

In addition to editing the definition of our service we can edit any requirements record associated with a service activity and change the fulfilment preferences from there. Below you can see that I have navigated to the resource requirement record from my service activity. And that on the scheduling tab I can edit the fulfilment preference. (And other fields which might influence the scheduling of this requirement.)

Time Groups

Time groups do not dictate the start time of subsequent bookings! Time groups organize results but leave the start time/arrival time as is, based on the particular resource’s schedule. Before I can define my time groups I must enter a name and saved the record. Then on the details tab I can add my time groups. To do this I need to provide a name, start time and end time for my time group.

Important: The end time defines the last time that an appointment can start within the window. For example, if the time window is 8:00 AM to 12:00 PM, it is possible that an item that has a duration could be booked at 11:30 AM or 12:00 PM even though in both instances, the end time would be beyond the time window.

Intervals and time groups together!

You may want to use a combination of intervals and time groups together. It is possible to define a fulfilment preference that uses both intervals and time groups, but you cannot add a value for interval begins. (As the interval will begin at the time of the earliest time group.) Also, if the reset interval per time group detail option is set to yes, the intervals will reset once a new time group detail overlaps with an interval

Rebooking

Nothings always runs as expected! At some point you are going to need to reschedule a booking.

I can select a single booking and use the “Rebook Group” option to re-run the scheduling assistant.

Tip:
This approach will allow me to change both the resource and booking time slot if required.

Having selected a new booking a new booking will be created. The old booking will be cancelled. You can see this on the schedule board as its colour will change to red due to having a cancelled status.

Another scenario is that you want to move all of the booking for a given day to another day. For that we can use the actions menu. (See the “move bookings to different day” option below.)

Having select the “move bookings to different day” option, a dialog will open asking me to enter a new day and also define what status I want these bookings to have. One limitation is that with this approach I can only move bookings forward in time!

Substituting Resources

From time to time you may need to change a resource on a booking. Maybe the current resource is ill or needed elsewhere urgently!

One option I have would be to use the rebook option described above. Although that will also be potentially suggesting alternative time slots.

Another option is to use the “substitute resource” option shown below. Here I can pick an alternative resource for the booking.

Tip: If I am unsure on which resource to pick I can use the “Find substitute” option which will suggest an alternative.

In this post I have covered quite a few concepts! You will need to understand all of these for your MB 230 exam …. So I recommend you experiment with these features to become confident in their use. Enjoy.

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!

I am currently revising for the MB-230 exam. This exam is for Microsoft Dynamics 365 and covers all aspects of customer service. As I revise I plan to publish blog posts that collectively will become a complete revision guide for anyone embarking on the same journey as me. In this post I will begin to discuss Omnichannel for Customer Service.

You can see an extract from the current skills measured statement below. What we can immediately see is that Omnichannel for Customer Service covers a large section of the exam! And also that this topic includes numerous subjects for us to revise. I will attempt to cover as much information as possible in a collection of blog posts that should aid your understanding of Omnichannel. In this post I will concentrate on an overview of Omnichannel and I’ll expand on any topics raised in future posts.

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.

What is Omnichannel?

I guess I should set the scene by explaining what Omnichannel is and why we might need it!

We live in a digital age where empowered customers can (and will) contact service-focused organisations in a multitude of ways. The customers will typically reach out using whatever communication method works best for them. And regardless of the channel selected by the customer the agent will need to have the customer’s details close at hand to be able to quickly and effectively handle queries.

Organizations therefore have to offer a variety of support channels including; phone, email, live chat, SMS, virtual agents, social channels and more. And regardless of the channel being used the agents will need consistent access to knowledge base articles, agent scripts and other productively tools to help them resolve the queries.

Additionally agents may need to juggle multiple customer conversations simultaneously. In my experience it has been common for one agent to be required to handle between 3 to 5 web chat conversations simultaneously. This can only be achieved when the applications they use support contextual sessions which enable them to seamlessly swap from conversation to conversation.

Microsoft’s Omnichannel for Customer service app can support multiple channels and has numerous features to help organizations provide first class service in this omnichannel / digital world.

Note:
In recent months Microsoft have made a massive push to make continuous improvements to their Omnichannel offering. It is therefore very likely that some of the concepts I show in these posts could evolve quite quickly. I encourage you to ensure your revision doesn’t rely purely on my posts but you also seek out additional information on the latest features. Plus Omnichannel is a large subject, so don’t assume I will have covered every last detail!

Customer Service Workspace and Omnichannel for Customer Service Apps

Microsoft provide two customer service apps which support a multi-session interface and can be used by agents to manage Omnichannel conversations.

The first of these is the “Omnichannel for Customer Service” app. This is their original multi-session app that shipped with Omnichannel for Customer service. You may therefore commonly notice it being used in any examples you see for Omnichannel.

We now also have the “Customer Service Workspace” app. In many respects this offers exactly the same agent experience as the original omnichannel app. In the Customer Service Workspace the default dashboard (typically) isn’t the agent dashboard we see in the Omnichannel for Customer Service app. But the agents can easily open that dashboard or the default can be changed.

I guess the key difference (in my opinion) is that you can opt to use the “Customer Service Workspace” app without enabling Omnichannel. Therefore maybe its usage could become wider than the original Omnichannel for Customer Service app.

I personally normally favour using the “Customer Service Workspace” app. But any of the agent or supervisor experiences I describe in these posts will work pretty much exactly the same in either application. (At this point in time I think your only “take-away” needs to be an understanding that we have two multi-session apps available!)

Regardless of which app you use there are several components to the agent experience you need to be aware of. I have shown a screen shot of a live conversation below. Then below the screen shot I will highlight the purpose of each part of the screen.

1. Sessions
   

As agents accept the notifications from incoming conversations sessions will automatically open. They can swap from session to session by clicking on the session names in the left panel. Also notice that the agent always has access to their “Home session”. It is here that they will view any global tabs. Typically that will be their agent dashboard showing the status of conversations.

Agent can start sessions automatically by clicking on notifications agents. In addition they can also open cases (and other records) from their home dashboards by clicking the mouse whilst holding down shift.

Tip: If you find holding shift to start sessions “clicky” then checkout this blog post. As I describe how we can enable a simplified method of navigation. Also … I think I recently read that the second release wave in 2021 will enable this simplified navigation by default!

1. Session tabs
   

Inside each session we will have one or more session tabs. Each tab will include a Dynamics 365 form or other web resource. Administrators can actually enhance the session starts to open multiple tabs if required! Or holding “ctrl” when you click a link will open a new tab in the session. You can also use the “+” icon to open new tabs in the session. (Yes, the simplified navigation mentioned above does remove the need to hold “ctrl”.)

It is these concepts of sessions and session tabs which give us the multi-session interface within our Omnichannel apps.

1. Conversation panel
   

During conversations we also have a conversation panel. It is from this panel that the agent can swap messages with the customer or even other agents. Additional capabilities transferring the conversation to another agent. Plus quick replies can be used from the conversation panel, these are a great way to quickly and consistently send commonly used phrases.

Agents can also quickly take notes, access the knowledge base and even turn on real-time language translations from the conversation panel. Plus if enabled the agent can escalate a web chat into a voice or video call.

Importantly agents can also see a real-time analysis on the customer’s satisfaction level or sentiment. As I will describe in later posts the sentiment ranking is also visible to supervisors when they are monitoring ongoing conversations.

1. Presence control
   

The agent’s presence is an important concept! If you have ever used Microsoft Teams you will already be familiar with the idea that each person can be green (available) or red (busy). We can also define custom presence values if the agent wants to flag they are on a break etc.

The agents presence will default and change from available to busy automatically as they start / end conversations. But in addition to this agents can manually change their presence as required.

1. Customer summary
   

The customer summary tab or conversation tab if you prefer contains details of the incoming conversation. This is the “anchor tab” for the session. As you open customer records or create cases these will be linked to the conversation.

Also on this tab the agents can see the conversation summary control. It is here they can see all sorts of useful information about the conversation. Including any pre-chat survey responses, wait times, customer location, language and more.

1. Productivity panel / agent scripts
   

The productivity panel can include three things. Smart assist, agent scripts and knowledge base. All of these are designed to help the agent research and resolve customer queries.

The smart assist panel uses AI to give suggestions on knowledge articles, similar cases and other suggestions which may be useful.

The agent scripts are guided processes to help the agent resolve queries. In their simplest form they give prompts to the agent to help them decide what messages to convey to the customer. But beyond that they can also trigger macros which can automate processes, such as opening a new case and much more.

Omnichannel Admin Center (and NOT Omnichannel Admin app)

As I am sure you can appreciate administrators have loads of configuration options connected with Omnichannel for Customer Service. Therefore we have an administration app called “Omnichannel admin center”. This is used to define the channels, routing rules and other settings that make up our Omnichannel solution. As I progress with these blog posts we will cover many options within the admin center

At this point I should mention the “Omnichannel Administration” app! Yes we have two admin apps at the moment. (Confusing I know!!) As mentioned earlier Microsoft have been continuously improving their Omnichannel capabilities …. When Omnichannel first launched all of the administration was completed in the “Omnichannel Administration” app. That app does still exist and does still operate.

BUT IMPORTANTLY. Once you have started to maintain settings in the newer “Omnichannel Admin Center” you can no longer maintain your channels in the older experience. Therefore in all of these blog posts I will be showing screen shots from the newer Omnichannel Admin Center. This does mean you may still find some information published which shows the old app. (My older blog posts for example!) In most cases the concepts from the old app can be applied in the new one. Often it is just the navigation which is different. But the new app will also include new features not present in the old app. (Intelligent machine learning for routing of cases being one of many examples!)

Channels / Workstreams / Queues

The admin center allows us to configure Omnichannel settings. So this might be a good point to introduce a few new concepts / terms.

Channels can be created. These can be for web chat or social channels such as Facebook or Twitter. Each channel is linked to a workstream. Workstreams are the key definition of how we want conversations on the associated channel to operate. The workstream will include a definition of the behaviours and user features applicable to the channel. For example, it will include a definition of the pre-conversation survey or enable certain features like conversation transcripts.

Workstreams can also include classification rules. These may include details of what skills we expect agents to have to be able to answer customer queries.

Next the workstream will include routing rules to define which conversations will be routed to which conversation queues. Queues in Omnichannel are pretty similar to other queues in Dynamics 365! In that we have a queue and it can be associated with a number of members. (or agents.)

Other settings on the workstream define the work distribution logic. For example, how much capacity of the agent will be consumed for each conversation on this workstream. Or when we are using skills based matching if an exact match is required or if a closest match logic can be applied.

I will no doubt return several times in future posts to explaining concepts connected with workstreams! As they are the core component in the definition of our Omnichannel behaviour.

Agent Dashboard

As already mentioned … in both Omnichannel apps agents will use the Omnichannel Agent Dashboard. This is their starting point for managing conversations.

Generally speaking the agent will get a notification that a conversation has been assigned to them. They will accept that conversation and therefore trigger a session to open. Commonly they will complete the conversation and then exit the session. At least that will be a common process when we are talking about a web chat conversation!

Not all conversations will operate in the same way. Consider an SMS conversation … these tend to be long running. As customers will probably not give the instant responses we’d expect with a web chat. It that scenario it may be quite likely that the agent closed the session prior to the conversation ending. And then re-open the conversation later.

Another scenario is the pick distribution method. Often we will “send” the conversation directly to an agent with a notification. This is called the push distribution method. But we have another approach called “pick”. With the pick approach the conversation is routed to the queue but the agents would then manually pick the conversation when they are ready. I have used the pick approach when routing cases created from a web-portal to agents, as the cases didn’t need the same instance response as we’d expect with the push method.

These scenarios and more are where the agent dashboard comes into play. It contains three panels that automatically refresh every few seconds. (Although the agent can also click the “Refresh All” button to force a refresh if required.)

• My work items – this panel contains a list of all the conversations currently active with the agent. These maybe already open in sessions. But the agent may have closed the sessions. So they can use the “…” option on the conversation card to open a session when required.
• Open work items– This central panel will show any conversations (or records) which have been routed into a queue the agent is a member of. The items here are available for picking. When this happens the agent can use the “…” option to pick the conversation. Doing so would effectively assign them to the conversation and move it from the “Open work items” panel into the “My work items” panel.
• Closed work items– Recently completed work items will show in the closed work items panel. As conversations are closed in the “my work items” panel we will see their status changes to “wrap up”. And then they become completed as they progress into the closed work items area. This panel might be useful if an agent needs to review the details of a recently finished conversation.

Agent Presence / Capacity Concepts

Earlier I mentioned the concept of agent presence … and how this will change automatically as conversations are started. I also mentioned how conversations are routed in the workstream to queues.

Each queue contains a number of agents and the system needs to decide which agent to push the conversations to. (Assuming you are using the push distribution method!) This is when the concept of capacity can come into play.

Firstly the agent presence will be evaluated. As any agents who are off line or in a do not disturb mode would be excluded. (Actually the presences that are considered for routing can be tailored on your workstream!)

Next we will typically allocate the conversation to the agent who has the most capacity. Each agent’s system user record includes some additional fields specific to Omnichannel. You can see my record below! I have a capacity of 300. This means I can handle up to 300 “workstream conversation points” at one time. Each workstream has a capacity setting that will be applied to conversations arriving on that workstream. So, say I have a chat workstream and that has been set to 100 points. This would mean I could handle up to 3 chats concurrently as my capacity is 300. But say SMS conversations are rated at 50 points. Then I could handle up to 6 SMS conversations at once. And any combination …. So I could handle 4 SMS conversations and still complete one web chat. Etc etc.

It might also be worth noticing that our agents also get a default presence. This is actually really useful. As I often set my default presence to “Do not disturb”. Meaning when I first log into Omnichannel I will not start getting any notifications until I manually make myself available.

You can also see that within the Omnichannel tab you can see which conversation queues I’m a member of and also access my skills profile as well.

WOW that’s a lot of concepts for one blog post! I hope you are still with me. Future posts will build on these concepts and more to hopefully give you an overview of the key information you’ll need to be aware of for your MB 230 exam. Enjoy.

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 cover advanced scheduling concepts.

Below you can see an extract from the current skills measured statement for the MB 230 exam. You can hopefully see that scheduling is firstly a significant section of the exam and also that it covers numerous topics. Meaning this post is one of several that I will create to cover all aspects of scheduling. In this post I will discuss some of the advanced scheduling concepts such as fulfilment preferences, rescheduling service activities and more.

Fulfilment preferences

We can use the schedule assistant to find availability from the schedule board or via the book option directly on service activities. Without any fulfilment preferences the schedule assistant will “simply” display results based on resource schedules and their earliest availability.

Often a booking will be suggested exactly at the next available time. Meaning if the assistant is run at 9:37am, then a time slots starting exactly at 9:37 maybe suggested. Often time slots using “rounded” time values would be preferrable. It may be easy for the customer and the dispatcher if a job was booked for 9:45am or 10am, rather than 9:37am.

Also, we may often want to limit the number of appointments per time slot (or interval). As booking back to back appointments might seem efficient but it gives no margin to allow for overruns, late running, longer than expected travel times etc. Therefore booking in intervals can help to create a plan which is more achievable.

URS includes fulfilment preferences that allow us to choose how the schedule assistant results will be displayed. This can include two features;

• Intervals – intervals display schedule assistant results in time slots that dictate the start time of subsequent jobs.
• Time groups
  – allow schedulers to search / view options as blocks of time. Often this could include morning / afternoon bookings or 2 hour windows etc.

Intervals

Below you can see that if I try and book a 30 minute service activity, the schedule assistant is offering appointments literally every 30 minutes.

This might be find but what if I only wanted to book one appointment per 2 hour interval. Then this approach would not be correct!

Below you can see that I have created a “2 hour interval” using fulfilment preferences. Now for the same 30 minute job slots in blocks of 2 hours are offered.

To define a fulfilment preference to achieve this I used the fulfilment option. Below you can see that I have given my preference a name of “2 hour intervals”.

Next on the intervals tab I have stated that I want to have a 2 hour interval. And that my intervals will begin from 9am in the morning. I can also optionally restrict the number of results per interval that are offered to the dispatcher. If you have a large number of resources this might be a useful way to help the dispatcher work with a shorter suggested list.

Tip:
If you limit the results you might want to think about the sorting logic applied on the service’s requirements. As suggesting the least busy resources first (for example) might become a useful tool to ensure you achieve the desired resource loading.

We can now edit the service definition. In the resource requirements tab you can add your fulfilment preference to the requirements.

In addition to editing the definition of our service we can edit any requirements record associated with a service activity and change the fulfilment preferences from there. Below you can see that I have navigated to the resource requirement record from my service activity. And that on the scheduling tab I can edit the fulfilment preference. (And other fields which might influence the scheduling of this requirement.)

Time Groups

Time groups do not dictate the start time of subsequent bookings! Time groups organize results but leave the start time/arrival time as is, based on the particular resource’s schedule. Before I can define my time groups I must enter a name and saved the record. Then on the details tab I can add my time groups. To do this I need to provide a name, start time and end time for my time group.

Important: The end time defines the last time that an appointment can start within the window. For example, if the time window is 8:00 AM to 12:00 PM, it is possible that an item that has a duration could be booked at 11:30 AM or 12:00 PM even though in both instances, the end time would be beyond the time window.

Intervals and time groups together!

You may want to use a combination of intervals and time groups together. It is possible to define a fulfilment preference that uses both intervals and time groups, but you cannot add a value for interval begins. (As the interval will begin at the time of the earliest time group.) Also, if the reset interval per time group detail option is set to yes, the intervals will reset once a new time group detail overlaps with an interval

Rebooking

Nothings always runs as expected! At some point you are going to need to reschedule a booking.

I can select a single booking and use the “Rebook Group” option to re-run the scheduling assistant.

Tip:
This approach will allow me to change both the resource and booking time slot if required.

Having selected a new booking a new booking will be created. The old booking will be cancelled. You can see this on the schedule board as its colour will change to red due to having a cancelled status.

Another scenario is that you want to move all of the booking for a given day to another day. For that we can use the actions menu. (See the “move bookings to different day” option below.)

Having select the “move bookings to different day” option, a dialog will open asking me to enter a new day and also define what status I want these bookings to have. One limitation is that with this approach I can only move bookings forward in time!

Substituting Resources

From time to time you may need to change a resource on a booking. Maybe the current resource is ill or needed elsewhere urgently!

One option I have would be to use the rebook option described above. Although that will also be potentially suggesting alternative time slots.

Another option is to use the “substitute resource” option shown below. Here I can pick an alternative resource for the booking.

Tip: If I am unsure on which resource to pick I can use the “Find substitute” option which will suggest an alternative.

In this post I have covered quite a few concepts! You will need to understand all of these for your MB 230 exam …. So I recommend you experiment with these features to become confident in their use. Enjoy.

I am currently revising for the MB-230 exam. This exam is for Microsoft Dynamics 365 and covers all aspects of customer service. As I revise I plan to publish blog posts that collectively will become a complete revision guide for anyone embarking on the same journey as me. In this post I will begin to describe the concept of queues.

Below you can see an extract from the skills measured statement of the MB-230 exam. Notice that we’ll need to know how to configure queues, add cases to queues, configure tables (entities) for queues and more.

What is a Queue?

Let’s begin with a simple question …. “what is a queue!“.

A queue is simply a list of “work items” including cases, activities or other entity types. Queues are a place to organize and store “jobs” waiting to be processed. Dynamics 365 includes queuing and workflow tools to efficiently manage incoming requests, this post will explain the concepts connected with this management.

From a customer service point of view queues can be a very important concept to allow teams of users to manage incoming requests for service, as they can be routed to suitable queues to ensure the right agents work on the correct pieces of work.

Note: In this post I will not be discussing additional concepts we have within Omnichannel for Customer Service. As with that there is a concept of a messaging queue which is used to route conversations to agents. (I will cover those concepts when I review Omnichannel!)

Queue Types

There are essentially two styles of queue, user queues and system queues.

User queues are tied to an individual user (or team), whilst system queues are available across the whole system. User queues can be used to route important activities to individual users. Each user will have a queue (local user queue) created automatically as their system user record is created. Other users do not have access to see the details of the queue. It is possible to configure Dynamics 365 to automatically move items to local user queues as they are assigned.

System queues are used for queues of work that need to be shared. (For example: A queue of newly arrived support cases.) System queues are a container for work items that a group of people might work on. Queues can be configured for any record type in the system but by default queues are enabled to work with cases and activities.

With system queues agents can indicate what queue items they are working on, providing managers the ability to see who is working on what. (And importantly what items are not being worked on.)

System queues can be given a type of Public or Private. Public meaning that the queue is available to all users in the system. Private indicating that it is available to a list of members which can be defined on the queue. With a private queue you must be a member of the queue to see the queue items.

Queues can have an email alias, meaning you can create an email address such as support@mycompany.com and have emails to this address automatically routed to the support queue. (We may then also use an automatic record creation rule to create cases as emails arrive on this queue.)

As one example, below you can see an example queue definition. Notice that in this example the queue type is “private” and therefore the queue has a number of members.

Maintain Queues

Whenever a user or a team is created a default queue is automatically created, this is their “local user queue”. This shouldn’t be maintained! But system queues can be maintained in the queues option which can be found in the service management area of the customer service hub. (As shown below.)

Additionally queues can be created from the Service Management area of the advanced settings. Or in business management option within advanced settings.

It is worth understanding that the “queues” option within the customer service hub’s service area actually displays the “queue items”. So when you view a queue from here you see its contents not the definition of the queue.

Below you can see an example of a public queue I have created to handle any incoming support calls. Notice that I have assigned an incoming email address. When you do this an associated mailbox will be automatically created.

Note: Prior to creating this queue I created a suitable shared mailbox in Exchange, thus giving me a generic support email address without needing to create a Dynamics 365 user and consume a license!

When queues are created they are immediately active, they don’t need to be published to enable them. Active queues can be deactivated and reactivated. Queues can be deleted but ONLY if there are no queue items associated with the queue. Meaning that before you can delete a queue you must re-route the items to another queue or remove them before attempting the delete of the queue.

Note: Deleting the queue items removes them from the queue it does not delete the associated record.

The process for creating a private queue is pretty much the same as creating a public queue, except with a private queue you define a list of members for the queue.

Once the queue has been created you are ready to add queue items to the queue. With emails this could be automatically handled on the receipt of a new message, with cases you can use routing rules to automatically route cases to the queue. (Such as automatically move high priority cases to an escalation queue.) These options will be covered later in this post.

Or you can manually route items directly to the queue as required!

Add Cases / Activities to Queues

Now we’ll look at how to manually route a case (or other activities / entities) to a queue. From the case form you can access the “Add to Queue” option. Once selected you and chose the queue you’d like to move the case onto. In my example I have selected the “Urgent Cases” Queue.

Now the case is allocated to the queue, I can see it by looking to the list of active items in the “Urgent Cases” queue. You can also see the details of the queue the case is on by using the “Queue Item Details” button from the case. This will present a screen something like the one below. Notice that this allows the user to see (and change) which user is working on the case. (aka the “Worked by” field.) This field is set as users are assigned to the case or they pick the case from the queue.

Note:
If the case is already assigned to a queue the “Add to Queue” button still shows, in this situation the “Add to Queue” button would effectively remove the case from the first queue and move it to the new queue. A record can only exist one queue at any moment in time.

When we add a case to a queue, behind the scenes nothing is really happening to the case entity. But a new queue item is created on the required queue to show that this case is in the “list” of items to be processed from the queue. You can also move one (or more) items to a queue from an active case view. See below that you can select one (or more) cases and then select the “Add to Queue” option from the command bar above the view. This approach is useful when allocating several items in one go or when you want to quickly move something to a queue without opening the record.

The process for adding activities (or any entity enabled for queues) to a queue is pretty much the same. Although I suggest you experiment with a few entities to become familiar with this process. Below you can see I have added a phone call, case and task to the same queue. This also demonstrates that you shouldn’t think of a queue in terms of one entity type. It would be quite common to have a “support” queue that includes multiple entity types all of which need attention from someone in the support team.

Tip: This does mean I named my example queue badly! As I called my queue “Urgent Cases”. This queue could actually include entities other than just cases, so a better name might have been something like “Urgent Support Enquiries”.

Queue Items

Having routed one or more items, next we’ll look at how to work with the items on a queue.

A queue is simply a list of queue item records. Therefore, a queue is not a collection of records but a collection of queue items. What is routed to the queue is not the record itself but the queue item record. Meaning the queue item is a go-between record sitting between the record and the queue. When a queue is selected from a view the system is actually filtering the queue items by the queue selected. If you inspect a queue item you see no details about the actual case / activity associated, the queue item will simply state who is working on the case and when it entered the queue.

The drop down of queues will contain a list of all available queues, you also have their other options that might be useful to filter queue items. Including looking in all queues, all public queues or all queues the operator is a member of. These options are useful if a single person needs to monitor multiple queues.

Having selected an appropriate queue(s), you can then change the view to show;

• all items,
• just items you are working on,
• items that are available
• etc.

Using these views enables an operator to see work they have “to do” and work they “could” do.

The items someone is working on or items that are available is governed by the “worked by” field on the queue items. Meaning you’d either be looking at all queue items with the worked by set to the current user (your to-do list) or all items with a blank worked by (your “could do” list). The worked by field will remain set to the current user until the queue item is completed or the queue item is “released”, which effectively wipes the worked by field and puts the queue item back into the “pot”.

Pick Queue Items

From the queue you use the “pick” option to show when you are working on a case. (or other queue item.) Highlight one or more available queue items then select the pick option, this will present a dialogue similar to the one below. Picking the queue item will assign you as the owner. You then have an option to remove the item from the queue or not. If the item remains in the queue the “worked by” field is also set to show that you are now managing the case.

See below that I left the items in the queue so the “Worked By” field has been set to me.

You can also use the route option to move a queue item from one queue to another. Or in the route dialog select a user (or team) to allocate to the queue item. And again an option is presented to remove the queue item (or not). The owner and worked by fields are then set in the same manner as someone picking the queue item, except the selected user is used instead of the current user. This approach is typically used when a team leader “dishes out” the queue items rather than the operator picking them.

Release / Remove Queue Items

Let’s say you are allocated some cases you can’t do, maybe your about to take a holiday and need to release current activities to ensure that someone else processes these items whilst you are away. This is done by using the release option from the queue. Simply select the item(s) you wish to release and select the release option. This approach leaves the queue items in the queue, “waiting” for someone else to pick them up.

An alternative approach would be to use the “Remove” option. This however would remove the items from the queue. When considering the remove option it is important to understand that only the queue item is removed not the associated case / activity.

Note:
Directly from the case you can add the case or route the case to the queue. But to pick and release the queue items you are required to do this from the queue views.

Case Routing

Another important aspect of managing queues is the concept of case routing. Within a service management environment the use of queues is very common. The ability to automatically route cases is a really effective way to help with the management of queues. The automatic routing might be based on a characteristic(s) if a case, for example all new installation requests to be sent to the installation team’s queue or all high priority requests to be sent to a “High Priority” queue.

Auto-routing can be applied when a new case is saved or whenever a user uses the “save & route” option on the case.

Note:
If you are using auto-save, it is important to understand that the case is not routed when the auto save kicks in! The routing happens when the use selects the “Save & Route” option.

Routing rule sets are defined in the service management area of the customer service hub.

Below you can see an example of a routing rule set, one that hopefully illustrates the concept. I have created a rule set that will assign new IoT cases to my cat! And any high priority cases to my urgent cases queue.

Each routing rule set can have one or more rule items. Below you can see I have opened an example rule item. In this example I am assigning the case to a queue but I hope you can see that I also have an option to route cases to a user. The logic is simple enough, whenever the condition is met the case will be assigned to a team / user or routed to a queue as required.

Tip:
You cannot amend an active Routing rule set, So you will need to deactivate it to make changes. But don’t forget to activate again as only activate rules will be applied when you apply the routing rule.

Enabling Other Tables for Routing

I’m describing queues in the context of service management but it is important to understand that queues could be used by other parts of the business, for example, all fresh leads might be assigned to a new leads new leads queue.

Which tables are enabled for queues can be customized.

Below you can see that I have opened Power Apps (make.powerapps.com) and then opened my invoice table. Here I can access the settings option to control how this table (aka entity) will behave. You will find the options relating to queues under the “Collaboration” heading.

Below you can see I can now use the “Enable Queues” option to allow me to route records in this table to queues. One thing you should be aware of is that if you make this change it can not be reversed. Once a table is enabled for queues it cannot be disabled!

Also notice that we can also opt to add newly created records to the owners local user queue.

In this post I hope I’ve given you enough background information on queues to support your preparation for the MB 230 exam. Queues are actually a simple enough concept but I have found some Dynamics 365 consultants can become confused about how queues operated and when to use them. So as always I strongly encourage you to gain as much hands-on experience as possible. Enjoy!

I have recently moved from using the original Omnichannel Administration app to the newer Omnichannel Admin Centre. If like me you want to use the newer admin experience you will need to migrate your current workstreams. In this post I will explain the process I followed.

As I have configured numerous channels I actually have quite a few workstreams, all of which needed to be migrated to the new admin experience. Lucky me Microsoft provide a tool to help migrate your workstreams to the new unified routing approach. You can find details about this here.

Once I’d download the migration tool I could begin!

Having extracted the tool I simply ran the “URMigrationConsolApp.exe” application. (As shown below.)

Nobody will describe this application as modern looking! In fact it reminded me of something I might have used on a Wyse terminal in the 1980s. (Gosh I am old!!)

Anyway, on running the application I needed to enter the URL of my Dynamics 365 instance and enter my user name. After a short pause I got some lovely green screen style text message telling me I’d connected successfully.

Cool … we have an old school menu! With 4 “real” options and one to exit the application. With a feeling of nostalgia I continued to experiment with each option!

Option One

Option “1” gave me a list of all the workstreams I needed to convert.

Option Two

And option “2” gave me a list of the new style workstreams. Below you can see that I have already migrated one workstream called “BOT Chat”. (The demo live chat workstream came out of the box with the new admin centre!)

Option Three

Option “3”performs a dry run. The description of this option seemed to suggest that it was going to simulate a migration of just one specified workstream. But it actually did a simulation for all workstreams. My simulation didn’t report any errors. Meaning (honestly) this option didn’t give me any real useful information. But still you might want to run it before doing an actual migration. As you may get a different result to me!

Option Four

So option “4” is the one we use to actually migrate the workstreams. You do this one by one. Having selected the option I needed to enter the ID of the workstream.

Tip: I copied and pasted this from the list I got in option 1.

Importantly notice that you are told that after the migration you should only maintain the workstream in the “Omnichannel Admin Center” App. I call the out as you will still see the workstream in the old app. But you should no longer maintain it using the old interface!

I continued repeating this process until all my workstreams had been migrated! As you can see below I was supposed to have no old workstreams remaining!

Conclusion

After the process I tested my various workstreams. So far they have all continued to work as I’d expected. Which is “really nice”!

Afterwards I also double checked that everything had migrated. It hadn’t! I found three workstreams that remained in the old Omnichannel Administration app but didn’t exist in the new Omnichannel admin center.

These three were all connected with my entity channels. These had been created to route cases and leads to omnichannel agents. None of these were available in the migration tool. I guess that means I will need to recreate those at some point. (Although for now they do still work.)

Note: It looks like my entity routing has continued to work after migrating to the newer Omnichannel Admin Center. But as this means I’ll need to maintain my entity channels in the old app and everything else in the new app I will probably want to manually recreate these very soon!

Apart from my entity routing workstreams (which you might not have) …. I am now ready to start using the newer Omnichannel Admin Center. I guess I’m going to need to use the new “Record routing” option to manually re-create my entity workstreams at some point.

In summary the conversion of my workstreams was pretty straight forward. (Except my entity workstreams!) And I am now ready to start to explore what additional features are available in the newer “Omnichannel Admin Center”. Enjoy!

Omnichannel for Customer Service allows us to connect with a Virtual Agent. It is then possible to trigger a transfer to a human agent from within our topics / authoring canvas. But what if your customers are getting frustrated with a BOT that doesn’t understand them? In this post I will explain how we can use the “system fallback” setting to help with that scenario.

It may be common to construct a topic that allows the virtual agent to transfer the customer to a human. Maybe they enter an answer of “unsure” to a question and this could trigger the BOT to transfer to a human. (As I have shown below.) Or maybe you can have a topic of “human” that will transfer to a human if the customer enters certain key phrases. Like “I’d like to speak to a person” or “Can a human help me” etc etc.

But what if your BOT repeatedly does not understand what the customer is saying. (Or the customer doesn’t understand what the virtual agent is asking!) If you have ever experienced a BOT repeatedly saying “I don’t understand” you might know how frustrating this can be!

Imagine your virtual agent is asking the customer which colour they want. If the only options are “Red” and “Green” …. a customer asking for “Black” isn’t going to work. As an example I created exactly that scenario. Below you can see I am prompting for a colour and I have only added options of “Green” and “Red”.

Below is an example of the frustrating type of conversation which can occur. This is horrible as for the customer the loop will go on and on. Resulting in an upset customer. By the time they finally call to talk to a real agent they will already be annoyed. The BOT wants the customer to enter “Green” or “Red”. But this customer wants “Black”. The BOT tries hard by repeatedly offering an option it thinks is ok. But Red just isn’t want I want!

Note: This is just one example of many situations which could cause this type of problem. We could (and should) argue that your customers shouldn’t get stuck like this with a well-designed BOT! But in the real world we all know dead ends like this can (and will) occur.

Enable System Fallback

Luckily we do have a solution available to us! That being that we can enable a fallback topic which will be triggered if the BOT repeatedly asks the same question!

Below you can see that I can access the “System fallback” option from the settings cog on my virtual agent.

No we can add a fallback that will be triggered if the customer’s intent is unclear after two attempts.

You can see below that having clicked “+Add” a fallback topic has been created. I can now use the “Go to fallback topic” option to tailor it if required.

Below you can see the default fallback topic. Which you may want to tailor!

Now when I run the same test again you can see that eventually the virtual agent will transfer the customer to a human. Maybe that is still slightly frustrating but at least the customer isn’t stuck in a deadend.

I do advise you to try and avoid these “dead ends” in the first place. A design which avoids the situation in the first place has got to be the best option. But having a fallback for when everything fails also seems sensible to me. Enjoy!

Omnichannel for Customer Service and the Customer Service Workspace provide us an API where we can use JavaScript to control the behaviour of the multi-session experience for out customer service agent.

Below you will find a link to a video which explains the concept behind this API and gives one example of how we might use it.

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 review entitlements.

Below you can see an extract from the current skills measured statement that mentions entitlements.

Note: Microsoft do update these exams on a fairly frequent basis. Therefore I do encourage you to check the current skills measured statement to ensure you are aware of the latest information!

Entitlements are a “tool” to help companies manage the services they provide, this post will explain entitlements and how they are used to support service management within Microsoft Dynamics 365. Entitlements are effectively a definition of agreements between the customer and supplier for services to be provided.

Entitlements are used to define the amount of service to be provided (in terms of hours or numbers of cases), the service level to be applied and even what channels the service can be offered upon. It is possible to create a template for your entitlements, so let’s first look at those.

You will find two options connected with entitlements and entitlement templates in the service management area of the customer service hub.

Entitlement Templates

The first thing to note is that the use of templates is optional but they are available to help speed the process of creating entitlements. Using entitlement templates also enforces consistency.

When you create a new entitlement you can opt to create it from scratch or base the new record on an entitlement template.

There are several fields that are important to understand with regard to entitlements (and entitlement templates) as these govern how the entitlements behave;

Allocation Type– determines if the entitlement is based on number of cases or hours consumed.

Decrease remain on– this determines if the balance of support remaining should be decrementing based on cases created or cases resolved.

Total Terms– this is the total number of allocations allowed. (For example 100 cases or 50 hours of support.)

Restrict based in entitlement terms– This options decides if new case creation will be prevented if the entitlement limit has been reached.

SLA– If this entitlement is linked to a specific SLA then this can be defined here.

Note:
An entitlement template can include a start and end date, although typically these wouldn’t be used. As each entitlement created from the template will cover a different period.

You can also optionally define channel and product details within the template if required. These can be used to restrict the entitlement terms depending on the origin (channel) of the case. Or make it specific to services you provide connected with specific products.

Create new entitlements

Entitlements can optionally be created from an entitlement template, as I have already mentioned. It will therefore come as no surprise that the entitlement itself actually resembles the template. Although there are some differences, firstly the actual entitlement will be associated with a customer.

Tip:
There is a third method to create entitlements! As it is possible to create a new entitlement by renewing a cancelled or expired entitlement.

When creating an entitlement, you enter a name, customer as well as a start and end date. (Typically an entitlement will have a start and end date as it forms the contract between the supplier and the customer.) Plus you can associate an entitlement to an SLA. You can also define if this entitlement is the customer’s default entitlement or not.

Note: I will cover the detail of creating an SLA in another post as there is a specific section in the skills measured which relates to these.

As with the template you can define the allocation type (ie number of cases or hours) and number of allotments.

Another option (not available in the template) is the ability to restrict which contacts can raise cases against this entitlement. Useful if you need to tightly control who at the customer is allowed to log cases. For example: maybe only someone from their IT team is allowed to log support requests.

In addition to restricting support based on channel it is possible to limit support to specific products. As your customer’s could have their level of support restricted based on the product or service they have purchased.

Entitlements start off in a draft state and need to be activated. Note, that the entitlement does need to be activated before it can be set as the customer’s default entitlement. The “Set As Default” button does not show in the command bar for draft entitlements! This does mean if the default entitlement is deactivated, maybe because some details need to be amended, when the entitlement is re-activated the default status will have been reset. So you will need to remember to repeat the process of setting it as default.

Entitlement Channels

Channels are optional restrictions on the entitlement, used to limit the amount of support that is provided on a particular channel. You may, for example, limit the number of hours of support provided on the telephone.

Channels are the mechanism the customer used to raise the case. So channels might include email, phone, web portal or web, social media and even IoT. The channel is based on the origin of the case.

It is possible for the total sum of cases allowed on each channel to exceed the total allowed on the agreement. This may seem strange at first but is logical. You might allow someone to log a maximum of 100 cases. With a maximum of 100 being from email, and a maximum of 100 from web and 50 from phone. This doesn’t mean a total of 250 is allowed! The total is the maximum on that channel. So I can log a maximum of 50 on the phone leaving a balance of 50 that could be logged by email or web. (Or I could log none on the phone and log 100 on the web etc.)

Whilst this logic sounds confusing, if you think about it, the purpose is to try to drive customers to have a preference for one channel over another. So in the example I gave we are trying to encourage customers to email requests (or use web) rather than telephoning. This encourages a channel shift that might be very desirable in some situations.

Apply Entitlement to cases

As cases are created the default customer entitlement will be automatically populated onto the case. However, it is also possible to select an entitlement as you may have multiple entitlements for one customer. Maybe reflecting the different service agreements, you have with that customer. It is important to understand that each entitlement is always tied to a specific customer.

Also whilst working with cases the user can optionally decide whether or not to decrement the number of allotments. It might be that a case is raised for a very simple question and the operator taking the call applies some discretion and decides to not reduce outstanding balance of support on the entitlement. Even though you might opt to not decrement the allotment the case would still be associated with the entitlement. As this works well for later reporting of service provided under the agreement and also you may still wish to apply the SLA defined on the entitlement.

If the entitlement is set to restrict cases should the balance remaining on the entitlement reach zero then you will not be able to create any additional cases. One behavior on this you should be aware of is what happens if the balance remaining to decremented on case resolution. In this scenario, if a case is re-opened (unresolved) then the entitlement balance would increment. Giving one extra case that can be resolved.

Entitlements Lifecycle

As already mentioned an entitlement will start off life in draft mode. Only entitlements in a draft state can be amended. You then need to activate the entitlement to be able to start to “consume” the allotment by associating it with cases.

If you activate a contract that has a start date in the future its status will be set to “waiting”. It will then be automatically set to active on the start date. You can only set the entitlement as default once it is active (or waiting).

Once an entitlement has been activated (or set to waiting) it can’t be changed but you can deactivate entitlements at any point. (You must remember to reset as default once re-activated!)

Entitlements that are active or waiting can be cancelled. Once cancelled they cannot be changed and also cannot be used on new cases. A cancelled entitlement can however be renewed.

After the end date of the entitlement has passed it will automatically change to expired.

Cancelled or expired entitlements can be renewed. By selecting the renew button in the command bar.

Renewing an entitlement creates a new draft entitlement based on the expired one. The date range will automatically increment on the new draft entitlement. The draft can be changed before activating the new contract.

To help make this lifecycle clear I have attempted to draw the possible states below!

Note:
We can also deactivate entitlements at any point. This reverts them back into a draft state. (This might be useful if we want to amend an active entitlement and then activate again!)

I hope this post has covered all of the points mentioned for entitlements in the skills measured statement of the MB 230 exam. But as always I really encourage you to get some quality hands-on experience as port of your exam preparation.

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 review service level agreements (SLAs).

Below you can see an extract from the current skills measured statement that mentions SLAs. In this post I will try and mention all of the topics referenced in this statement;

Note: If you have worked with earlier versions of Dynamics 365 you might need to be aware that the April 2020 release included an updated approach to SLAs. One which leverages Power Automate flow. Therefore a little extra revision maybe need here for some people!

What is an SLA?

A Service Level Agreement (SLA) is simply a way of defining and tracking what should happen when a case is created (Or changed). It reflects the agreement between the supplier and client and establishes expectations of service delivery times. For example: For a high priority case resolution must be completed within 8 working hours or first response for a low priority case must be completed within two days of receipt. SLAs act not only as the agreement between supplier and customer but also as a KPI for the supplier to monitor performance levels.

Note:
I am going to talk about SLAs in context of cases but you may need to be aware that we can apply them to other tables. (Such as leads or custom entities!)

The completion of an SLA and therefore performance against KPIs is achieved by a definition of success and failure conditions, plus (optionally) if a warning should be triggered as a failure state approaches. The actions that should be taken at each stage can be defined, for example sending an email to a line manager if a failure state is approached. (With the latest version of SLAs the actions to be completed are actually controls using a Power Automate Flow.)

SLAs might be based upon the type of customer, the agreement which is in place with the customer, or on attributes of a specific case. (Such as priority or channel.) The service level agreement may also be associated with an entitlement.

It is important to know that your ability to create an SLA is dependent on your security role. Not all users will be (or should be) able to design their own SLAs.

SLA Setup

You can maintain SLAs from within the customer service hub. In the service management area you will find options to main the SLA KPIs and SLA agreements.

The SLA KPIs are the metrics you want to use to manage your SLA. Commonly on cases we’d want to manage when first response has been completed and when the case has been resolved. I will explain how to define these metrics later soon!

Tip:
You can also maintain entitlements from the service management area of the customer service hub. I have described entitlements in a previous post. I mention this as you might need to be aware that we can associate an SLA with an entitlement. This approach allows us to have specific SLAs for specific customers.

There are some additional SLA related settings you may need to tailor before creating your SLA. These include defining your companies holiday schedule, and one or more calendars. (These will be your customer service schedule.) Additionally you may need to review the service configuration settings as some define how the SLAs operate.

Service Configuration Settings

Using the service configuration settings option you can access the system settings that influence the behavior of SLAs and entitlements. In particular you will need to decide which cases status values should pause the SLA timer. In my example I have selected to pause the SLA if the case is waiting for details. Therefore if set to “On Hold” or “Researching” then the clock will continue to tick.

Configure one or more calendars

You configure your normal working patterns using the “customer service schedule” option. Below you can see an example of a basic Monday to Friday 9am to 5pm calendar. You might need to define several calendars. For example, your standard SLA might run Monday to Friday 9am to 5pm but selected customers might have an enhanced SLA which works on a 24/7 basis. You’ll need to define each of your required working patterns ready to apply to appropriate SLAs.

Notice below how I have said “observe” holidays. This means any non-working time defined in our holiday schedule will impact the SLA. So next I’ll look at holiday patterns.

Define Holiday Schedule

Using the holiday schedule option I have created an example holiday schedule. Notice that in the grey ribbon bar you can see the year.

Note: One limitation here is that holiday shutdowns are always whole days. Part days are not possible using this option.

Again you might need several holiday schedules. For example: maybe one area of the business provides support on Christmas Day, whilst most people take this as a holiday.

First I create a holiday schedule … as shown below.

Now I can create my shutdown dates for each year. (Notice the year is shown in the grey bar!)

Define SLA KPIs
The next setup step is to define my SLA KPIs.

SLAs can be applied to entities other than case but obviously I’m going to stick with case for this example. I’m going to want two KPIs. One SLA will be measured against first response, so how fast do I acknowledge a customer’s query. And the next will be based on resolution, so how fast do I fix the issue.

Below you can see that I’ve opened the service management area within my customer service hub. I have then opened the “SLA KPIs” option. Within this option initially I have no active KPIs.

Tip: Don’t forget after you create your KPIs they must be activated to be ready for use!

I created two SLA KPIs and activated them. One for first response and one for resolution. Below you can see that I’ve given my KPI a name. I then select the entity this KPI applies to, when it applies (SLA KPI) and based on what date.

The applicable from date is often quite important. In my example I want the SLA to start from the date the case is created. That will be quite common. But what is the priority on my case changes? In my example the SLA is going to be recalculated from the date the case was created, that might be fine. But in some scenarios you might want to use the date the case was modified or maybe even a custom field.

Tip: In real world scenarios I have often used a custom date field. As the case created date is when your customer service advisory originally clicked save on the case. Yet your SLA might actually need to start from the time a customer sent an email, which depending on your business processes and levels of automation could be much earlier than the case creation date. So having a custom date field that can be set to a time prior to the created date on the case can be a benefit.

Having added and activated my two KPIs my view of active SLA KPIs looked like this.

Create an SLA

Having correctly configured our calendars and other options we are ready to create an SLA.

In real-world scenarios the definition of an SLA can be quite complex. As often companies will have multiple scenarios to reflect. Additionally the actions required when an SLA reaches a fail or warning state can vary quite significantly. In the notes below I will show just one example of how an SLA might operate ….. please keep in mind that many other variations maybe required. I encourage you to setup multiple differing SLAs as part of your revision.

In the service management area of my customer service hub I can maintain service level agreements. (Shown below.)

Importantly notice that the default view of “All Service Level Agreements from Unified Interface”. This is because you could have SLAs defined in the older style classic web interface and / or SLAs from the newer Unified Interface. As the old style SLAs are really now a legacy concept, I will concentrate on the latest version!

When I create a new SLA, I first enter a name for my SLA, select an entity and optionally add a description. If you have multiple SLAs the description might be really useful to be able to understand the purpose of this particular SLA. Once the SLA is saved you will be ready to add your SLA Items.

As I add my SLA items I give each one a name. I also select which KPI the SLA item is based on.

The allow pause and resume lets me optionally decide if this SLA will pause. I might, for example, want to pause my SLA if the case is put on hold because I am waiting for information from my customer. I define which status will pause SLA in the system configuration settings. (See note at the end of this section!)

Importantly I next select my business hours. If I don’t my SLA will apply 24/7 365 days per year. But If I want my SLA to follow my normal working week and to take business closures into account then I’ll need to define / select a calendar.

Next I will select when this SLA is applicable. In my example I have decided to have two SLAs. One for cases of normal priority and a shorter one for cases of a high priority. (Low priority cases will have no SLA!)

I also define the success condition. For “first response by” success might be that the field “first response sent” has been set to yes. For my “resolve by” SLA, then success might be that the case status has been changed to “Resolved”. (and maybe “Cancelled” as I’d also stop the SLA if the case was cancelled!)

You can see that I then define my warn and failure times. I might for example, have 8 hours to give first response on a normal case. But maybe only 2 hours on a high priority case.

Note: You may notice that the actions section doesn’t show! Actually after I save the SLA item I will get a configure actions button. That will allow me to maintain my Power Automate. (More on that in second!)

You can see below that I defined four SLA items. Two for first response and two for resolve by.

Note: A note here about my warn and failure times might be useful! They are easy to visualise if you work 24/7. As one day would literally mean I just resolve the case by tomorrow. What if I only work 8 hours per day and “just” 5 days per week. Then 24 hours (aka 1 day) would mean I have 3 working days to resolve the case.

Tip: I like to think of my SLAs always in terms of the number of working hours I’m allowed to complete the task. If you always enter them as hours the system will convert to days (and fractions of days) automatically.

Note:
Below you can see that in the service configuration option. In this I can define which case status values will pause my SLA. Along with some other SLA related system settings!

Amend Power Automate

On each of my SLA items I have a “Configure Actions” button.

Clicking the configure actions button will open Power Automate and drop me into a template Cloud Flow.

First of all you will click “continue” to connect this Power Automate with your Dataverse. Your Power Automate will then look something like mine below.

Importantly, notice that some elements of the Power Automate include “Do not delete or update” in their description. Guess what, you don’t edit these bits!

But you can expand the switch condition by clicking on it and then start to add actions for each status. (Below you can see that I have options for near noncompliance (aka warn), succeeded and non-compliance.)

Tip: The switch condition also includes a default option. This might be useful as would be triggered when a case is first created. You could additionally add actions to that!

The actions that you decide to add into your Power Automate Flow could do many things! Common examples would be to send an email to alert the case owner that the SLA was about to expire or had failed. For the purpose of this post I will have a simple example that just updates a field on the case.

In my simple example I want to update a field on the case to amber on warn and red on failure. So I have added an update record step. This is connected to my current environment, the entity is cases and the record identified has a dynamic value of “Regarding ID”. This is the ID of the record connected to this SLA instance, so in my example my case.

I have then scrolled down and set the desired field on my case. So for me that means my RAG field. (Note: This is a custom field I created, your SLA will no doubt have different steps to mine. This is just an example!)

Once I save this Power Automate, my cloud flow will be added into my default solution. You might need to be aware of this as you’ll probably need to add the Power Automate into your own solution, assuming you need to migrate them from say a dev instance into production.

Using the SLA
After I had created all of my SLA items and their associated Power Automates (aka Cloud Flows) I am ready to activate / test my SLA.

Keep in mind that this is a simple example! I have only two SLA items listed in the SLA Details section. It might be that each priority / type of case has a different first response and resolution timescale. Therefore, I hope you can see that SLAs could get quite complicated!

So first you need to activate my SLA and also then set it as default.

SLA’s can be applied to a case in one of three ways;

• When the SLA is the default SLA all new cases will have that SAL applied.
• When the user manually assigns the SLA on the case. Using an SLA lookup column we can add to the case form.
• By virtue of associating the case with an entitlement that is linked to an SLA.

I created a case and you can see that initially I have 2 hours to complete my first response.

On the SLA tab you can see the details for my first response and resolve by KPIs.

If my SLA conditions are met the status will change to succeeded, below you can see that I have sent my first response!

Alternatively if you do not complete the SLA in time you will see the status change into a warn and eventually fail state. Before you can see that I have a “SLA warning” as my SLA is nearing expiry.

I mentioned earlier that you could pause an SLA. Below you can see that my case has been set to waiting details. Doing this has paused the SLA timer. Setting the status back to “In Progress” would restart the timer, With the target failure / warning times adjusted to allow for the length of time the SLA was paused.

Hopefully this post will have given you a good overview of the capabilities of service level agreements. As part of your preparation for the MB 230 exam I encourage you to gain some hands on experience of using SLAs.