What does your Service Level Agreement look like?
-
There has been some recent discussion in the channel around SLAs... Joe Panettiere recently posted about the idea that it could be time for MSPs to abandon service level agreements, while Jaq Baldwin thinks that they just need to be adjusted.
So, what do your current service level agreements entail? Are you considering dropping/changing them?
-
Yet another reason I am happy to avoid being an MSP.
-
I'm a general disbeliever in SLAs across the board. There are cases for them, but it is not just MSPs where they do not work. The idea of an SLA is fundamentally foolish - it means that people are not trying to do their best and that people don't want to just work together.
Internal IT departments rarely have SLAs and we would think that that would be a dumb thing to have. Why would we have them for external IT departments?
-
We do MSP work but do not price the work on a per machine basis. Just doesn't make sense for us at all. If clients want high quality work then they pay for it. Most MSP models even if an MSP starts out with good intentions doesn't stay that way long term. Per machine means least amount of effort put into keeping things working correctly.
-
Hence the need for SLAs. When your base agreement is focused on doing as little work as possible, you need an additional agreement (the SLA) to fix the first one.
-
From what I have seen, it's to regulate the amount of boots on the ground you need.
Most MSPs want to be on premises as little as possible.
But clients want to know how quickly someone will be out to fix their issue.
The SLA is an equation to regulate both sides of that issue.
-
@Minion-Queen said:
We do MSP work but do not price the work on a per machine basis. Just doesn't make sense for us at all. If clients want high quality work then they pay for it. Most MSP models even if an MSP starts out with good intentions doesn't stay that way long term. Per machine means least amount of effort put into keeping things working correctly.
But the per machine is generally for "maintenance" type stuff. Updates, patching, etc.. Automation takes the effort out of that, which is why per machine pricing makes sense to a lot of MSPs.
-
@BRRABill said:
@Minion-Queen said:
We do MSP work but do not price the work on a per machine basis. Just doesn't make sense for us at all. If clients want high quality work then they pay for it. Most MSP models even if an MSP starts out with good intentions doesn't stay that way long term. Per machine means least amount of effort put into keeping things working correctly.
But the per machine is generally for "maintenance" type stuff. Updates, patching, etc.. Automation takes the effort out of that, which is why per machine pricing makes sense to a lot of MSPs.
Except it also encourages a lack of maintenance since pro-active work costs money and reactive makes money. So it is a model that is hard not to have contractually putting customers and suppliers at odds.
It's not the worst model, by any stretch, and I like it in some cases. But it has some major drawbacks that need to always be considered and addressed.
-
@BRRABill said:
The SLA is an equation to regulate both sides of that issue.
Sort of, but it assumes "as soon as possible" isn't going to happen. An SLA means that the vendor has no incentive to beat the SLA, it makes a target level of laziness. If the SLA says four hours, you can bet it will be four hours. Without an SLA, it might have been five minutes.
-
@scottalanmiller said:
@BRRABill said:
The SLA is an equation to regulate both sides of that issue.
Sort of, but it assumes "as soon as possible" isn't going to happen. An SLA means that the vendor has no incentive to beat the SLA, it makes a target level of laziness. If the SLA says four hours, you can bet it will be four hours. Without an SLA, it might have been five minutes.
Yes but on the flip side no SLA can mean 2 days from now.
Not saying you wouldn't lose the client, but they'd probably move to someone with an SLA offering.
-
@scottalanmiller said:
@BRRABill said:
The SLA is an equation to regulate both sides of that issue.
Sort of, but it assumes "as soon as possible" isn't going to happen. An SLA means that the vendor has no incentive to beat the SLA, it makes a target level of laziness. If the SLA says four hours, you can bet it will be four hours. Without an SLA, it might have been five minutes.
Plus it also protects your nights and weekends. Not in guaranteed time, but 9x5x5 vs 24x7x7.
-
@BRRABill said:
Yes but on the flip side no SLA can mean 2 days from now.
Then you get a different vendor that is working with you. You are thinking that an SLA fixes a bad vendor or bad relationship. That's a very bad way to think of an SLA. If the vendor could not get there before two days, the SLA becomes useless. If they could get there but didn't bother, why are they your vendor?
In no case does the SLA help, but it does break things.
-
@BRRABill said:
@scottalanmiller said:
@BRRABill said:
The SLA is an equation to regulate both sides of that issue.
Sort of, but it assumes "as soon as possible" isn't going to happen. An SLA means that the vendor has no incentive to beat the SLA, it makes a target level of laziness. If the SLA says four hours, you can bet it will be four hours. Without an SLA, it might have been five minutes.
Plus it also protects your nights and weekends. Not in guaranteed time, but 9x5x5 vs 24x7x7.
That's not an SLA that does that. That's just hours of coverage. You could argue that hours of coverage is a form of SLA, and I can see that, but generally I would think of them as different things. Do you look at the Taco Bell front door and refer to their hours of operation as their SLA? If not, I think it's a different thing.
-
Yeah, I consider them one in the same.
Again, not doing it ourselves but rather from looking at a lot of other MSPs, most of them bundle response time in with hours of operation. And it's just RESPONSE time, not resolution time.
Perhaps we are talking about different things.
-
@BRRABill said:
Yeah, I consider them one in the same.
Again, not doing it ourselves but rather from looking at a lot of other MSPs, most of them bundle response time in with hours of operation. And it's just RESPONSE time, not resolution time.
Perhaps we are talking about different things.
No, talking about the same things. And I can see why you would combine the two things, but everyone has hours of operation and no one calls them their SLA. I get that technically, pedantically we can consider everything from the list of skills and services, to regions supported, holiday schedules and hours of operation all being called SLAs, but that's not what people mean when they talk SLAs normally. Related, of course.
-
Resolution time should not generally be in an SLA, if you can guarantee a resolution time it implies knowledge of the issue and why would things be broken if we already knew what was wrong
-
I see it this way... you should be partners with your MSP. When there is an emergency and the world is falling apart, do you want your MSP pointing to an SLA showing that your outage and disaster is none of their concern? When your MSP is idle or bored and would be happy to do work to help, do you want them not doing it because you are outside of official hours?
You want your MSP being part of your team. SLAs mean you aren't looking at your MSP as a team member but an enemy you need to keep in line. It's fundamentally the wrong approach to a business relationship. Work together towards a common goal, don't start the relationship with the assumption that you are out to get each other.
-
OK, then how do you determine what they can call for?
Or do you not care since it is all billable?
-
@BRRABill said:
OK, then how do you determine what they can call for?
That's Scope, not SLA. That's rather different.
But in general we do billable hours so that, like you said, these kinds of issues do not exist at all. The can ask us to come over and make grilled cheese sandwiches for all that we care.
-
Or fix the coffee pot (yes I have done that before).
