Defining "Emergency" For MSP Customers
-
In discussing this today, one thing that I said was that I felt that customers need the ability to be able to define pretty much anything as being mission critical, even if it feels trivial to us as an MSP (or to internal IT staff, if you aren't a service provider.) It's not our jobs to determine what the business feels is or isn't critical. But we also can't give carte blanche for the business to ignore proper planning and make their mistakes our problems.
I said that I felt that what is and isn't mission critical should be defined by the business' planning and behaviour. For example, if a desktop or laptop is considered mission critical and is expected to fail every ~8 years on average, then that is often enough that if it truly is an emergency if it fails that keeping a spare on hand, at least for hardware over two years old maybe, is necessary for IT to agree to calling that an emergency. If it's not worth having a space, then it can't be an emergency.
Same with skipping RAID or backups. If a workload doesn't get RAID, then downtime can't be an emergency. Or if there is no backup taken and there is data loss, that is "business as usual" data loss and cannot constitute an emergency after the fact.
Thoughts?
-
@scottalanmiller said in Defining "Emergency" For MSP Customers:
If a workload doesn't get RAID, then downtime can't be an emergency. Or if there is no backup taken and there is data loss, that is "business as usual" data loss and cannot constitute an emergency after the fact.
Sometimes, the customer is not even aware of this concept. For example, the last IT provider never stressed the value of RAID or Backups. The customer may not have invested in the key components we consider a requirement in order to call something mission critical, even though it truly is.
-
@JasGot said in Defining "Emergency" For MSP Customers:
For example, the last IT provider never stressed the value of RAID or Backups. The customer may not have invested in the key components we consider a requirement in order to call something mission critical, even though it truly is.
Sure, and that's fine. You just have a discussion and say "this is what acting like it matters looks like" and if they don't, then later you say "you explained it wasn't critical to you at the time necessary to make us be able to treat it as an emergency, and that can't be changed after the fact."
I wouldn't expect the customer to know (outside of backups, of course, even a five year old knows you need a copy of paper that is really important) how to treat it except that we ask them and tell them what needs to be done and they can choose to treat it as critical, or as trivial.
-
Of course if you simply charge for emergency support and don't have "included" emergency support, then this point is moot because you are happy to have everything treated as an emergency if that is what they want.
-
@scottalanmiller said in Defining "Emergency" For MSP Customers:
then later you say "you explained it wasn't critical to you at the time necessary to make us be able to treat it as an emergency, and that can't be changed after the fact."
I like this. I would make it part of the up front conversation. Letting them know that dismissing this today, will make it difficult to address later.
I think the root issue is that almost the whole world takes IT people and products for granted.
This this weekend fire cause you to start thinking about this? Did they provide push-back when they found out how much danger they were in, and the cost to fix it?
-
@scottalanmiller said in Defining "Emergency" For MSP Customers:
Of course if you simply charge for emergency support and don't have "included" emergency support, then this point is moot because you are happy to have everything treated as an emergency if that is what they want.
Mostly this^
Clearly defined emergency situations are a good start but there's no One Size Fits All approach. There has to be room/flexibility for emergencies that aren't caterd for in the initial documentation.With that in mind:
- What do they think constitutes an emergency?
- What are they doing about their critical/emergency level things right now?
- Do points 1 & 2 line up?
- If not, are they aware of it?
There's a lot of bad advice out there and also a lot of clueless "Whatever you say IT dude, I have no idea" management so the business may be in the dark over the specifics. Also, information provided by the business is unreliable at best until the discovery stage when you've got a clearer picture of the what, where, and how of their set up.
Going back to the defining of emergencies, don't forget about the two types of unknowns.
- Known unknowns: You and/or the business know that you don't know about something.
- Unknown unknowns: You and/or the business have no idea that you don't know about something or even of its existance.
-
@JasGot said in Defining "Emergency" For MSP Customers:
I think the root issue is that almost the whole world takes IT people and products for granted.
You then document that if they define something as "non-critical" prior to the disaster, that it cannot be changed during the disaster. It's all about getting it in writing.
-
@JasGot said in Defining "Emergency" For MSP Customers:
This this weekend fire cause you to start thinking about this? Did they provide push-back when they found out how much danger they were in, and the cost to fix it?
No, unrelated issues. This weekend's work was a true disaster. The issue that made us discuss this was in no way a disaster.
-
@nadnerB said in Defining "Emergency" For MSP Customers:
Unknown unknowns: You and/or the business have no idea that you don't know about something or even of its existance.
And these can be legit emergencies that both parties understand is really an emergency that just caught us. It's not about avoiding supporting emergencies, it's about not having the business see IT as a "relief valve" for bad decision making. MSPs have a tendency to get pressured to absorb risk that they are given no choice in holding onto.
-
I think emergency is going to be very subjective, vary widely between customers. I think it's best to write what constitutes an emergency in the contract with each customer.
Also, I understand that for example if the customer says:
Defined emergencies:
- Sudden data loss (some specifics such as downtime > X, data > X, etc.)
then if they decline suggested preventative measures such as RAID or backups, then it's up to the xSP if they want to exclude or specifically mention that "sudden data loss" is not considered emergency duo to customer opting out of suggested preventative actions.
However, charge outrageous fees for emergency work..... then everyone wins. They get you, and you get more $$.
-
@scottalanmiller said in Defining "Emergency" For MSP Customers:
Example: Customer refuses to take backups or to keep spare equipment on hand, and when things fail expect IT to panic and fix things off hours or whatever, while having put in no equivalent sense of criticality to the planning process.
How do people handle this? How do you define what is and isn't critical to customers?
Not ready to agree to the bolded part of this yet. For in house IT - are the expectations that IT will work past 5 PM or whatever closing time is?
If external support (MSP/ITSP, etc) is there an after hours rate?If the answer to either is yes, then I'd say the panicked call with expectations you will fix it is are exactly what they expect to happen and when work will commence nearly immediately - and in the case of MSP/etc, so will billing.
-
@Dashrender said in Defining "Emergency" For MSP Customers:
For in house IT - are the expectations that IT will work past 5 PM or whatever closing time is?
Absolutely, pretty much all critical departments have the expectation. Finance, legal, operations, IT, management.
-
@Dashrender said in Defining "Emergency" For MSP Customers:
If external support (MSP/ITSP, etc) is there an after hours rate?
That's what we are discussing. If there is, then there is zero need to define criticality, customers just pay for whatever they use. When the emergency support is included, then you have to define it.
-
@scottalanmiller said in Defining "Emergency" For MSP Customers:
@Dashrender said in Defining "Emergency" For MSP Customers:
If external support (MSP/ITSP, etc) is there an after hours rate?
That's what we are discussing. If there is, then there is zero need to define criticality, customers just pay for whatever they use. When the emergency support is included, then you have to define it.
That would be a new one on me - I haven't heard of anyone including emergency support before.
Is that for a setup like - MSP client buys 10 hours a month no matter what? and in the case of an emergency, they get free support on said emergency? and if so, for how many hours before the clock starts again? Seems crazy for an MSP to do, unless the contract is that huge.
-
@Dashrender said in Defining "Emergency" For MSP Customers:
That would be a new one on me - I haven't heard of anyone including emergency support before.
All of our contracts include emergency support; 24/7. This has been the way for 30 years. Our contracts are built to provide fixed monthly fees for IT services (for client budgeting), this includes all labor except for large departmental (planned) upgrades or capitol improvements (infrastructure).
-
@JasGot said in Defining "Emergency" For MSP Customers:
@Dashrender said in Defining "Emergency" For MSP Customers:
That would be a new one on me - I haven't heard of anyone including emergency support before.
All of our contracts include emergency support; 24/7. This has been the way for 30 years. Our contracts are built to provide fixed monthly fees for IT services (for client budgeting), this includes all labor except for large departmental (planned) upgrades or capitol improvements (infrastructure).
I'm guessing those are some pretty huge contracts though, that have more than enough slush fund time to makeup for the emergency hours spent by your staff. Is your staff hourly or salary? If they are salary, then you possibly don't have any additional costs to your company (depends - salary exempt or not?) in the case of non normal business hour support.
-
@JasGot said in Defining "Emergency" For MSP Customers:
@Dashrender said in Defining "Emergency" For MSP Customers:
That would be a new one on me - I haven't heard of anyone including emergency support before.
All of our contracts include emergency support; 24/7. This has been the way for 30 years. Our contracts are built to provide fixed monthly fees for IT services (for client budgeting), this includes all labor except for large departmental (planned) upgrades or capitol improvements (infrastructure).
This is how we work, too. So defining what is an emergency matters, otherwise customers are encouraged to call everything an emergency.
-
@Dashrender said in Defining "Emergency" For MSP Customers:
That would be a new one on me - I haven't heard of anyone including emergency support before.
Totally common. Most companies that we work with do it. Certainly not all, and I doubt it is the most common, but common certainly.
-
@Dashrender said in Defining "Emergency" For MSP Customers:
Is that for a setup like - MSP client buys 10 hours a month no matter what? and in the case of an emergency, they get free support on said emergency? and if so, for how many hours before the clock starts again? Seems crazy for an MSP to do, unless the contract is that huge.
If you are buying hours, that's a different mechanism. It's normally only included in situations where hours are not involved. Both for us, and everyone that we know.
Not crazy at all, all internal IT does this, no different really for an MSP.
-
This is what we currently do for hourly phone system jobs.
Basically as long as you schedule it, you get the normal rate. Time of day doesn't matter.
