MB2-714 (Microsoft Dynamics CRM 2016 Customer Service): Service Level Agreements

This post will be the next in my series aimed at people who are preparing for the MB2-714 exam. (Microsoft Dynamics CRM 2016 Customer Service.)

Microsoft Dynamics CRM 2016 provides lots of features to help manage service, this post will describe service level agreements (SLAs) and how to use them to enhance service. I’ll describe how to create and manage an SLA, how to describe types of SLA (standard and enhanced) and explain several SLA actions.

I have actually already written a couple of posts specifically about enhanced SLAs and entitlements. You might find it useful to review both of these as part of your exam preparation.

A service level agreement

An SLA is simple 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.

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.) The service level agreement may also be associated with an entitlement. (A concept I’ll cover later.)

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

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.

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

Enhanced service level agreements

Firstly, let me remind you that I have documents enhanced SLAs in an earlier post, so reviewing that might be beneficial.

Within an enhanced SLA it is 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 also 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 organisation. (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 has a 24 by 7 SLA. By defining differing working calendars this 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.

Note: I am not going to describe the process for creating a enhanced SLA in great detail here! Simply because I have published posts on this subject before.

Hopefully by reading this post and my earlier posts you should have gained the basic understanding of SLAs needed for the MB2-714 exam. J

In my next post I will continue this series by looking at entitlements. (A concept which fits nicely with the SLA capabilities I have described here.)

2 thoughts on “MB2-714 (Microsoft Dynamics CRM 2016 Customer Service): Service Level Agreements

  1. Pingback: MB2-714 (Microsoft Dynamics CRM 2016 Customer Service) | Microsoft Dynamics CRM and Unified Service Desk

  2. Pingback: MB2-714 Certification (Microsoft Dynamics CRM 2016 Customer Service) – Revision Guide | Microsoft Dynamics CRM and Unified Service Desk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s