11 SLAs Every MSP Handles

Uncategorized
Written By

It has taken seven years working for an MSP who already had over 25 years of successful experience to identify the most common Service Delivery Workflows - or more importantly - the groups of Customer request types that need their own SOP and have a unique Service Level Agreement. Our goal in writing about our experiences is toguide you on how you can make the Service Delivery improvement changes in less than a year. Stay with us, because I know how much your MSP will benefit. The 11 MSP Service Delivery operational workflows are…

  1. Critical

  2. High

  3. High – Backup

  4. Medium

  5. Standard

  6. Quick Hit

  7. Minor Service Request

  8. Major Service Request

  9. Installations

  10. Projects

  11. Recurring Scheduled Events

sla contract

Note: as mentioned last week, Priority is the best Ticket field to communicate with which Workflow the Customer’s request has been Triaged. As we move into the SLA portion, we will present it in Priority order.We trust last week’s homework has been completed and there are now 11 Priorities in the Autotask Database. These are needed to configure the SLA Automation.So, if each of these Service Delivery workflows have their own unique SLA, what are they?

Workflows & Understanding Corresponding SLAs

Critical

It may surprise you, but we all have the same process for when a Critical Customer request comes in. Everyone drops everything, it is all hands-on deck, & we immediately collaborate on who is best to take the request.They then need to engage immediately and stay with it until the Customer is out of pain.Recommended SLA Configurations:Triage (First Response):within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): within 2 hours (but in reality, it is way less – almost ASAP. As a matter of fact, for a mature MSP Service Delivery operation, the designated Tech will be engaging before the Ticket has been created).Complete (Resolved): within a business day (and hopefully in much less time – but no guarantee or Customer commitment).To subscribe and download a Free copy of our Critical Request SOP click here.

High

Almost every Tech recognizes these are important and engages on these ASAP, which means as soon as all or most of the other High tickets in their name, queue, & widget have been engaged on and completed.  As a matter of fact, unless you take control of the Service Delivery operations, these are the only requests that will be engaged on and completed within Customers' expectations.Recommended SLA Configurations:Triage (First Response):within 1 hour (as it is the only way we know what we are dealing with)Tech Engagement (Resolution Plan): within 4 hours Complete (Resolved): within a business day and a half

High-Backup

This is a little-known workflow, but for the MSP providing daily or weekly backups, it is a very handy workflow. This workflow is necessary because Backups are a high priority & there is a high level of liability around not having a backup, should the Customer need them. However, the SLA is a totally different model than other workflows. If the backup fails, we are notified in the morning, but they are not scheduled to run until that night or next weekend. So, while they have a high liability, we do not need to engage within 4 hours, but we do need them up and running before we go home that night. Based on historical data, it takes less than 2 hours to adjust the schedules and fix the problem. This means we need to engage by 2 hours - before the end of the day, and it will be tomorrow morning before we know if they are fixed. Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): 2 hours before the end of today’s business day.Complete (Resolved): By noon tomorrow.

Medium: 

This remains the default Priority for new tickets. The challenge is to actually intake the Customer’s requests and Triage them for the benefit of the Customer, Service Delivery Team, and the MSP as a whole. In other words, stop mailing it in and actually provide great Service to the Customer.This starts with the intake process.Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): Within one business day.Complete (Resolved): Within two businesses days.

Standard:

I would never want to tell a Customer they are a “Low” priority, so we renamed it to “Standard.”  Unless the MSP expands the list of available Priorities, this is where Service Requests and all other Tickets no one wants to deal with go.Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): Within a business day and a half.Complete (Resolved): Within two and a half businesses days.

Quick Hits:

When the MSP I was working for first added a Service Desk in 2015, on the Service Desk Team were a few ITIL Police (ITIL: the governing body that defined what is an Incident and what is not).No matter how much I pleaded with them to take a Service Request, that would take them less than an hour to complete, they refused. (Yes, I know we were late to the party, but then again,I did not get a TV until I was 12…and it was Black & White and received only two channels.)It took the President of the Company to say “Yes, we know they are Service Requests, but in the best interest of our Customer, we are going to treat them like a high priority Incident. Without his (happened to be a “he”) declaration, there was a fear that anyone could send anything to the Service Desk for any reason, and then the optimization would fall apart – can you relate?Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): Within 4 hours.Complete (Resolved): Within one business day.

Minor Service Requests:

When I left this MSP in 2019, outside of Quick Hits, all Service Requests were scheduled with a Field Service Team. That is not to say they are all onsite visits, just that they were scheduled with the Field Engineer. The problem with scheduling is that the Service Call in the Calendar did not have a duration that matched what the historical data said was a reasonable amount of time for the Service Request. In other words, they were always scheduled with plenty of extra time. Since starting SDB-C in 2017, we have developed a way for Service Requests to live in the same worklists, queues, or widgets that the Techs were working from along with Incidents. From our experience, we have discovered that as long as the Service Request has less than 4 estimated hours, it would fit and play nicely. Thus, a Minor Service Request is a Service Request estimated to take between 1 and 4 hours to complete.Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): Within three businesses days.Complete (Resolved): Within 1 week.

Major Service Requests:

Based on our experience, if the estimated hours to complete the engagement are over 4 hours, the Customer’s request will not fit in a worklist, queue or widget. It must be scheduled in the Autotask calendars with a Service Call that has enough time to complete the engagement… or two to three separate Service Calls as in the case of a new laptop (received, decompressed, added to the domain onsite).By scheduling in the Autotask calendars, you block out enough time to complete the assignment, and notify everyone inside and outside of the Company that during this time frame – leave the Tech alone. He is focused on this one Customer request (or one Customer’s requests if you tuck more tickets and leave time to complete all of them).Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): Within one week.Complete (Resolved): Within two weeks.

Installations:

What sets Installations apart from other Service Requests is the recommended benefit of Planning (insert Wikipediadefinition here as I know it is not in the MSPs vocabulary). One Tech was very quick to say that all engagements take planning. I pointed out, “Yes, but this is planning time outside of, and in advance of, the scheduled engagement.”  So, when the Tech says (or the Service Coordinator knows) that planning time is needed, schedule a few hours a week before the start of the engagement. P.S.From our experience, the Quality of Service will vastly increase, and the Hours Worked will decrease, enough to cover the planning time.Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): Within two weeks.Note: Planning:Within one week.Complete (Resolved): Within three weeks.

Projects: 

Someone really should write a book on “Project Management for MSPs.” Until that happens, we will touch on a few of the key points here:

  • A clear definition of what is and is not a project – Recommended definition: any non-incident Customer request with more than 16 hours of estimated labor.

  • A clear Sales to Sales Engineering to Project Management workflow, including:

  1. Scope of Work

  2. Build of Materials

  3. Estimated hours

  4. Scheduling Pattern

  • An Internal and Customer communication plan

  • Meetings

  1. What Was Sold (WWS) – Internal

  2. Kick-Off – Customer Facing

  3. Weekly Updates – Customer Facing

  4. Close Out – Customer Facing

  5. Support Sign-Off and Acceptance – Internal

Recommended SLA Configurations:Triage (First Response):Within 1 hour (as it is the only way we know what we are dealing with).Tech Engagement (Resolution Plan): None - it is all negotiated.Complete (Resolved): None - it is all negotiated.Note: while there are no SLA Configurations or Automation for projects, there are some base level expectations:

  • Estimated hours plus a 10% buffer to be scheduled for the project.

  • Planning time will be scheduled a week in advance of the start of the project engagement.

  • A weekly PM meeting will be held to make sure the project is On Time and On Budget – or adjustments need to be made and communicated to the Customer.

Recurring Scheduled Events:

SLA clocks start at the time the ticket is created. Recurring Tickets are created a year in advance. Therefore, the SLA Automation does not function with these types of tickets.The solution: schedule them with a Service Call so they are in the calendar and time is blocked out for them as needed.

I hope this has been helpful!!

One last note:  This article covers the Standard Relationship with the Managed Service Customer - in other words, the Standard SLA. We find that Premier Managed Service Customers have the same SLA configurations, but with extended or 24/7/365 coverage for some Priorities (Critical and High). Non-Contract T&M Customers do not have Managed Service Agreements and therefore a Non-Contract SLA is needed at 2 times the Standard Contract SLA response times, and a Non-Contract workflow rule to apply the SLA when the Contract Category is empty.Feel free to adjust the numbers for your situation, but please do not feel free to adjust the concept in that there are:

  • At least 11 Workflows

  • All represented by a Priority

  • Each Priority has its own SLA configuration

So, what is your homework? Here’s what to do next…

  • Continue to make sure that when a new ticket is Triaged, all priorities are used, and Tickets do not retain a medium priority for no reason.

  • Download the Proposed SLA by Priority document.

  • Configure the SLAs for Standard Agreements, Premium Agreements, and Non-Contract SLA.

  • Download the guide and Build the Non-Contract Workflow Rule.

  • Check-in next week, as we continue guiding you through how you can optimize the Service Delivery journey of Customers' requests from Intake to Completion.

…Or as one MSP put it: “Remove the Service Delivery Issues that are a barrier to growth.”P.S. While the SLAs will be activated, they are not yet ready for prime time. There are some other Autotask Configuration tweaks that need to be made to be sure that all non-project and non-recurring scheduled events have an SLA applied to them. Standby, more info is coming…but please do not pause, keep going, we have a ways to go…For help with the journey, simply download the FREE PSA Self-Evaluation Here

Previous

How to Fix SLA’s for Service Delivery Workflows
Next

Service Managers' Job Challenges & Solutions