Microsoft Dynamics 365 Customer Service) – Manage SLAs

                         The skills measured statement that mentioned SLAs is shown below;

Microsoft Dynamics 365 provides loads of features to help manage service, this post will describe service level agreements (SLAs) and how to use them to enhance service.

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 entities. I provide an example of how to use an SLA with leads in this post.

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.

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.

Be aware that when an SLA is activated a corresponding workflow is automatically created behind the scenes.

Service Level agreement types

Microsoft Dynamics CRM has two types of service level agreement. Standard and enhanced. They are both quite similar expect the enhanced SLA has some additional capabilities. The following sections will describe each type of SLA and highlight the key differences.

Standard Service Level agreement

The first type of SLA is standard SLA.

When designing SLAs it is important to consider not only what happens if successful but also what will occur if we fail. Also when to trigger a warning and what to do at each stage.

With a standard SLA you may require some form customizations! Customizations are outside the scope of the MB2-718 exam but it is important to know that this is needed to make a standard SLA to work. Technically speaking the SLA actions and elements will still “fire” without adding the corresponding fields to the case form but users will not be to see exactly where they are against the target. Therefore, fields such as an SLA look up, first response date, resolve by date and SLA timer should ideally be added to the case form.

It is important to understand that functionally the standard and enhanced SLA differ only slightly but behind the scenes more automation happens with an enhanced SLA. More records are created automatically resulting in additional functionality with enhanced SLAs that simply doesn’t exist for a standard SLA. Including;

• A standard SLA doesn’t have the success actions available on the enhanced SLA.
• A standard SLA is also only based on date created, whilst an enhanced SLA can also operate from date modified.

Tip:
For the reasons mentioned above, I tend to always use the enhanced SLA! (But you will need to be aware of both options for the MB2-718 exam!)

Having mentioned several benefits of enhances SLA already, let’s look at them next ….

Enhanced service level agreements

Within an enhanced SLA it is also possible to pause the “clock” when the case is on hold. So that this time isn’t considered in the SLA calculation. This might be done, for example, when a case is put on hold waiting for the customer to respond to a question. The on hold reasons that will pause an SLA can be defined in the system settings area of CRM.

You can add success actions to an enhanced SLA. For example, you might want to send a specific message to a customer when their case is resolved within SLA.

The customizations needed to implement SLAs with the standard SLA aren’t required, as by default it is possible to see SLA KPI data directly on the case form.

Although two types of SLA exist, Microsoft do recommend using only one type of SLA within a single organization. (As this promotes a consistent approach.) Based on this, as enhanced SLAs have more features than standard SLAs it is recommended that enhanced SLAs are used. You could consider standard SLAs to be largely redundant.

Enhanced SLAs can work from created on date or modified on date. The significance of this comes into play if the fields used to derive the SLA target change. For example, consider an SLA based on priority, what happens if the priority of the case changes? Say it starts with a low priority and gets escalated to high. Assuming the SLA for a high priority case has a much shorter the target resolution date is going to change. But how it changes will vary depending on your agreement with the customer. It might be that the SLA is recalculated from when the case was first logged. (Created on date) Or it might be that the SLA is recalculated based on when the case was escalated. (Modified on date)

When creating the SLA you also define the calendar that applies. For example: A standard SLA might apply Monday to Friday 9am till 5pm. But you might also have a “Premium service” which might be in effect 24 by 7. By defining differing working calendars this sort of requirement can be met.

If you have defined which case statuses will trigger a pause in the SLA in the system settings, when you create the SLA you can set if these pauses should apply.

When an SLA is first created it will be in a draft state. Don’t forget that you’ll need to activate the SLA before it takes effect.

Creating / Maintaining an SLA

Some organizations have quite complex service level agreements, I once had to develop an SLA solution for a company offering services to the ministry of defense their contractual service levels (and associated penalties) were quite challenging. Which is why I understand an important first step is clearly documenting detailed requirement for the management of service levels. Not forgetting to consider what should happen if a case is paused or if the priority changes part, or fails the stated thresholds etc.

Also consider if you need to use entitlements! You can only have one default SLA, so if you operate different SLAs for different customers then entitlements will probably be needed. You will also need entitlements if you want to restrict the amount of service offered to someone. For example, you might want to allow creation of cases for telephone support for up to a maximum of 20 hours in the first three months after buying a new product.

Setup

Before actually creating your SLA rules, you’ll need to do some configuration. The Service Management area in Dynamics 365 settings will give you access to all of the required components.

Service Configuration Settings

Using the service configuration settings option you can access the system settings that influence the enhanced SLA. 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 put on hold or waiting for details. But if set to in progress 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 SLA rules.

Notice below how I have said “do not observe” holidays. This might not be what is required! 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 add the holidays for each year into my schedule. Notice the grey barf, this lets me move between years.

Having created the company holiday pattern you’ll need to tweak the calendar you created to use this pattern. Below you can see that I have altered my customer service calendar to observe the holiday schedule and then associated it with my example holiday schedule.

Create an SLA

Having correctly configured our calendars and other options we are ready to create a SLA. Firstly I navigate to the Service Level Agreements area and select new to create a new agreement. The first dialog allows me to select the entity applicable for this SLA. Generally this will be case, but as mentioned earlier you can enable other entities for service level agreements as required.

Next I start to define the details of the SLA. In this example I am going to create an enhanced SLA. (But you will find the process for a standard SLA quite similar.)

Tip:
Experiment with standard and enhanced SLAs as part of your revision preparation.

There are quite a few significant fields on this first form! So before we look at how to define the SLA items lets review them;

Field	Details
Status Reason	All SLAs will start off in a draft mode. Before they take effect you must activate them. Once active you can not change the SLA. (Unless you deactivate it.)
Name	This is simply the name we use to refer to this SLA.
Entity	You will have set this in the first dialog when creating the SLA, it can not be changed.
Applicable From	We need to define what date the SLA will be applicable from. Options include created on, modified on, follow up by, record created on, resolved by and first response by.
Business Hours	Here we select the calendar to use. In my example I have selected “Neil’s Company Calendar”. Which I have ste to be Monday to Friday, 9am to 5pm. Notice that we can change the business hours but many of the other fields on the SLA are fixed.
SLA Type	Here we select enhanced or standard SLA.
Allow Pause and Resume	Allow or do not allow pause. This will decide if the status values we set in the system settings will pause the SLA or not.
Description	Simply a free text description of the SLA. This might be useful when creating a complicated SLA that might warrant some explanation.

Having saves our SLA we can then define the SLA items. These are a definition of what SLAs to apply and when.

Below you can see that I have first created an SLA item for my first KPI. Which is “First Response By”. This allows me to say that for high and normal priority cases we must respond to the customer within 8 hours.

The definition of responded is shown in the success criteria section. In my example a first response has been successful when the field called “First Response Sent” has been set to Yes.

In addition to defining a failure state I can also define a warning state.

Once the failure and warning states have been applied I can list what actions I would like to happen. In my example for a failure and warning I simply send an email. The warning email might be a reminder for the owner of the case. The failure reminder might be an email that is sent to their line manager!

Having defined my first response SLA item, next I added my “Resolve By KPI” item. This is actually a very similar concept. Although notice that this time success is when the case is canceled or solved. Also notice that in my failure actions I have shown that we can have multiple actions. In my example I am sending an email, maybe to the support manager to warn of this failure. I am also updating the case. You might do this for several reasons, one example might be to automatically increase the priority of the case.

My completed SLA is shown below. Notice that my status has been set to active, as I have activated the completed SLA. Also notice that I have a “Set as Default” option.

Tip:
If you deactivate then change the SLA you may need to set it as default again. As you can only make an active SLA the default SLA.

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

1. When the SLA is the default SLA.
2. When the user manually assigns the SLA on the case. Using an SLA lookup we can add to the case form.
3. By virtue of associating the case with an entitlement that is linked to an SLA.

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

Once an enhanced SLA has been applied to a case you can see details of performance against the SLA directly on the case form. Below you can see the Enhance SLA Details tab from my case form. Notice that both my first response and resolve by SLAs are still in progress. As I have 23 hours to give a first response and 21 days to resolve the case.

Below you can see that sending the first response automatically changes the status to Succeeded. (And it would obviously have gone to failed if the first response hadn’t been completed in time!)

I mentioned earlier that you can enable certain statuses to allow the SLA to be paused. Below I have set my case status to “On Hold”. 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.