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.
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.
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.
- Enhanced service level agreements and entitlements – part 1
- Enhanced service level agreements and entitlements – part 2
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.- Enhanced service level agreements and entitlements – part 1
- Enhanced service level agreements and entitlements – part 2
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.
No comments:
Post a Comment
if you have any doubts, please tell me