A Many-Sided Abbreviation
An MSP company may find an increase or decrease in clients based on the pedigree of their SLA, or Service Level Agreement. The better the service you can provide, the more satisfied your customers will be. Satisfied clientele leads to an increase in clientele over time. There’s likely a numerical relationship involved, and if you keep close records, you may even be able to derive a formula from the data to plot a curve.
To that end, you want metrics which you can additionally monitor and improve on. This is especially true with MTTR, which actually is defined in multiple SLAs differently.
MTTR can refer to:
- Mean Time To Recovery
- Mean Time To Repair
- Mean Time To Response
- Mean Time To Restore
These have differences and similarities between them. You want to provide comprehensive solutions which over-reach client expectations regularly. To that end, the first thing you need to define is the word “mean”.
Average, Or Target?
Your MSP company can, define “mean” multiple ways. It can be used in the mathematical sense as an average. In this way, if your SLA seems slightly ambitious, you can couch that between averages and future projections. I.E., even though the SLA had a mean MTTR (call it “repair” this time) of four hours, it took you eight. The client complains but you know that’s an average and there will be thirty little problems throughout the year that takes much less for you to repair. If at the end of the year when everything is averaged out, you’re able to hit the average as specified by your SLA, then you won’t have under-served the client.
However, if you really want to impress clients and attain organic word-of-mouth referrals, a better strategy would be to make the term “mean” represent the maximum upper limit of your MTTR metrics. For example, if you’ve got a four-hour MTTR, then you have the problem resolved as much as possible in under four hours.
This works several ways, for both clients and vendors. As an MSP, you’ll have to provide clients with MTTR services of some calibre eventually. But the digital world has changed operational landscapes that this could look totally different than even just a few years ago. For example, if you’re helping your client run a cloud-based network, you’re likely working with a cloud vendor. This means you’ve signed an SLA with them, so now you need to know: does “mean” define an “average”, or an upper limit? In this case, it benefits you to work with an organization where “mean” means “upper limit”.
MTTR In Detail
Mean Time To Recovery is the next transition of Mean Time To Repair. Where before, a technician fixing an issue was very likely coming on site and acting as a sort of computer mechanic, today the digital realm has made fixes primarily software related; which is why the “repair” has changed to “recovery”. There is still on-site repair, but it’s usually going to be on something like a printer.
When it comes to cloud-based MTTR metrics, really you should be able to see results nigh-instantaneously. Usually, there are redundant cloud systems in place to ensure backup solutions as necessary. As a result, when one system fails, the other one boots up automatically and users don’t experience a lag in service–if this is managed correctly, of course. The right vendor will define “mean” as “upper limit”, and you’ll be able to see a metric of essentially “zero” between system compromise and recovery.
MTTR, as refers to “response”, is going to pertain to on-site technicians coming to fix something like the aforementioned printer. MTTR of the “restorative” variety basically means the same thing as “recovery”.
Your MSP company should both provide clients with diminished MTTR times, and find vendors for digital services who likewise are able to help you save time and money by defining “mean” as “upper limit” rather than “average”. The more succinct and dependable your metrics, the more operational data you can acquire, and you’ll likely see a positive spike in clients, too.