What does your Service Level Agreement look like?
-
@BRRABill said:
Do do you bill the RMM SaaS service separately?
I will not say that we would bill separately in all cases, but we have in the past in all cases of which I know (I don't see those agreements but sometimes know about the details.)
But it would be okay to have SaaS and labour rolled into a single line item, it's that it is being powered by two different things that is important not how it appears in writing necessarily.
-
@dafyre said:
Provide them X hours of support at a flat rate every month.
If they go over X hours, then they get charged the hourly rate...And there are the issues. Either the vendor is encouraged to do less work since the billing is flat or to work more slowly or to inflate the number of hours needed. This is better than some agreement types for sure, but it is still not very good. It doesn't protect against big issues which is what companies tend to want insurance against and it wastes effort month to month making a service that is very expensive while not delivering on the desired need. All this really is is billable hours with a minimum.
-
@dafyre said:
"We will provide up to 20 support hours per month to your company for $1,200 per month. All work done will count against your 20 support hours per month. Any work done that exceeds the 20 support hours per month shall be billed at $75 per hour. Support hours refresh on the first day of every month."
Everyone that I know that bills hourly offers this, but it is just a way to up the guaranteed hours on one side while potentially getting a discount on the other. Doesn't cover what MSP customers are using the MSP model for, though.
-
I don't think it's black or white.
Like having a SLA or paying for X hours means you're getting screwed 100%. It's another reason to pick a good company to partner with.
It's no different than a warranty. Why get one? Just pay hourly. It's nice to have a budget item that I pay $X for IT, and know I am done with it, and covered.
-
@BRRABill said:
It's no different than a warranty. Why get one? Just pay hourly. It's nice to have a budget item that I pay $X for IT, and know I am done with it, and covered.
But as hardware shops know, warranties are the best way to dupe customers. Always sounds good, never is good for them. There are cases where they make sense... but almost never.
SLAs are, by their nature, adversarial.
-
@BRRABill said:
Like having a SLA or paying for X hours means you're getting screwed 100%. It's another reason to pick a good company to partner with.
No, but I know of no situation where an SLA is good. You can come up with unique cases where it didn't turn out to be bad, but can you come up with any where it is good?
-
@scottalanmiller said:
But as hardware shops know, warranties are the best way to dupe customers. Always sounds good, never is good for them. There are cases where they make sense... but almost never.
SLAs are, by their nature, adversarial.
Interestingly, when we wanted to get into the computer consulting space, we were planning to do what you wanted to do, just bill for hours, but it didn't seem to make any sense financially, because you can't guarantee yourself income. That's what drove us to the MSP/RMM space.
-
@BRRABill said:
@scottalanmiller said:
But as hardware shops know, warranties are the best way to dupe customers. Always sounds good, never is good for them. There are cases where they make sense... but almost never.
SLAs are, by their nature, adversarial.
Interestingly, when we wanted to get into the computer consulting space, we were planning to do what you wanted to do, just bill for hours, but it didn't seem to make any sense financially, because you can't guarantee yourself income. That's what drove us to the MSP/RMM space.
And this is what drives the business side of an IT Service Provider or MSP... Knowing what your income will be, and figuring out how to grow it by adding more clients (not hours to existing clients unless they ask for it).
-
@BRRABill said:
@scottalanmiller said:
But as hardware shops know, warranties are the best way to dupe customers. Always sounds good, never is good for them. There are cases where they make sense... but almost never.
SLAs are, by their nature, adversarial.
Interestingly, when we wanted to get into the computer consulting space, we were planning to do what you wanted to do, just bill for hours, but it didn't seem to make any sense financially, because you can't guarantee yourself income. That's what drove us to the MSP/RMM space.
That's the tough thing.... you need customers who look at you as a partner to make it really work. Flat rate where you make tons of money for not providing labour is the easy way to make it work - but it also means customers are paying for nothing most of the time and often all of the time making it very hard to justify the service.
-
@dafyre said:
@BRRABill said:
@scottalanmiller said:
But as hardware shops know, warranties are the best way to dupe customers. Always sounds good, never is good for them. There are cases where they make sense... but almost never.
SLAs are, by their nature, adversarial.
Interestingly, when we wanted to get into the computer consulting space, we were planning to do what you wanted to do, just bill for hours, but it didn't seem to make any sense financially, because you can't guarantee yourself income. That's what drove us to the MSP/RMM space.
And this is what drives the business side of an IT Service Provider or MSP... Knowing what your income will be, and figuring out how to grow it by adding more clients (not hours to existing clients unless they ask for it).
And why MSPs need to be very large to provide these kinds of service effectively - they need to do it at scale.
-
This is a surprisingly lively discussion of SLAs
-
So if i understand correctly, the best approach is to charge an hourly rate no matter if you do servicing for desktops or servers, based on calls from the customer. What i didn't really understand is what about the regular maintenance works you do for the clients? Like what mentioned previously, av scan, patch management, other maintenance tasks etc which we do as part of our ongoing management. Does it also covers under the hourly rate? If so how do we agree with the client on the billing, just calculate the hourly rates used for all these and send out a bill on monthly basis? The only difference on the bill would be when there is something broken, or new additions to the existing setup i believe?
-
@Ambarishrh said:
So if i understand correctly, the best approach is to charge an hourly rate no matter if you do servicing for desktops or servers, based on calls from the customer. What i didn't really understand is what about the regular maintenance works you do for the clients? Like what mentioned previously, av scan, patch management, other maintenance tasks etc which we do as part of our ongoing management. Does it also covers under the hourly rate? If so how do we agree with the client on the billing, just calculate the hourly rates used for all these and send out a bill on monthly basis? The only difference on the bill would be when there is something broken, or new additions to the existing setup i believe?
So I would say that best practice is to tailor to the situation. That being said... overall I believe that hourly is the best with options like minimums, pre-arranged work and estimates and similar. So having, say, a forty item maintenance task list and a pre-arranged minimum and range of hours and some flexibility for addressing issues or special items (we found something that needed special attention but was minor so escalation would be ridiculous) would often be ideal.
But this is "optimum for the best relationship" and still has caveats - the service provider still is encouraged to find extra work to do, for example, and is not incentivized to automate what can be done manually or to invest in tooling to reduce labour as labour means profit and tooling does not.
There is no singular best answer. Part of the goal of moving to an MSP or ITSP model is to improve over internal staff. Internal staff are paid on an hourly system with minimums (e.g. hourly) or flat rate like an MSP (salary.) The same issues exist internally but with slight differences.....
-
Internal staff when paid hourly are generally either incentivized to reduce workload so that it falls below their minimum hours so that they have "free time" to relax, increase productivity, deal with other issues, or whatever. If they get 40 hours a week, this makes them want to find ways to work less than that or, at least, to find ways to need to work less than that. It doesn't mean that they blow off the remaining time, it could mean using it for more fun projects or simply not pushing resources to the wall and having no buffer.
Or internal hourly staff is encouraged, if they desire more money, to have overruns as extra hours, especially extra hours with overtime, goes totally into their own pockets.
-
ITSP arrangements can mirror employee situations whenever necessary by moving to dedicated or one to one staffing options. So, for all intents and purposes, you can always have an ITSP arrangement meet or beet an employee one in this way as long as the relationship is a good one. You give up no options. But you gain others, as a company bringing in an ITSP.
The MSP flat rate model or a hybrid of the flat rate model plus hourly is not completely ideal, but it is also far from the worst model. But it requires very clear scoping and a good relationship to really make work.
-
The worst model that I have seen is the project model. That's where things really get bad. In the MSP model you general deal with very common and quite straight forward scope that is spread over all or nearly all customers keeping scoping overhead down considerably. With project work all scoping cost is done on a one time basis making overall cost skyrocket and introduces risk at an unbelievable scale.
-
@scottalanmiller said:
...So having, say, a forty item maintenance task list and a pre-arranged minimum and range of hours...
I have seen IT Shops that will automate the maintenance, and still bill for 30 minutes or an hour of their time per task. Things like Scheduled Snapshots and then automatic Windows Updates... It is good for the customer because their equipment is kept patched and up to date... Good for the ITSP when the updates don't cause issues as they get to bill the client for the task and they don't have to spend but a few minutes confirming that it completed correctly.
There is no singular best answer.
It is rare that is a single, always, absolutely correct answer... (to go with your best practice comment above)... Tailor it to the situation.
-
@dafyre well one way that that can make more sense is that the MSP or ITSP can, if the arrangement is a good one, invest time up front in automation as long as they know that the customer is going to stay around and bill for the automation work that was already done coupled with monitoring and maintenance of the automation rather than for "hours doing the work" or whatever.
-
One of the hardest things to do is to figure out how to get both parties, the vendor and the customer, to mutually benefit from the same things. You want automation to be good for the customer, of course, but it also needs to make sense for the ITSP. Getting the ITSP to make investment decisions and doing the investing is important, but if you don't do it right then the customer ends up paying way too much for things that they could have just paid to have had automated. So you have to balance it in a way that allows the ITSP to work to improve things while the customer still benefits to some degree.
-
@scottalanmiller said:
One of the hardest things to do is to figure out how to get both parties, the vendor and the customer, to mutually benefit from the same things. You want automation to be good for the customer, of course, but it also needs to make sense for the ITSP. Getting the ITSP to make investment decisions and doing the investing is important, but if you don't do it right then the customer ends up paying way too much for things that they could have just paid to have had automated. So you have to balance it in a way that allows the ITSP to work to improve things while the customer still benefits to some degree.
This could be a billable project for the ITSP to do for the customer as a trial run to help build the relationship with the customer. One of the first things an ITSP or MSP should do when they onboard a customer, IMO, is take an inventory of what the customer has, and a short list of simple things that relieve pain points for both the customer and the ITSP.
For instance, a client of mine had some issues with their servers randomly rebooting during the day. It turns out somebody had set windows updates to deploy every day at like 2pm instead of 2am. They also had issues with one of their workstations with a flaky hard drive that was throwing errors in the event viewer...etc.
As part of our initial walk through, I pointed out those issues and we talked about what to do and worked up a project that entailed fixing those issues and noting any new ones that we found. My Pops and I did the work, and the client brought us back a few more times for fixing other issues that came up.
