Defining "Emergency" For MSP Customers
-
@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.
-
@JaredBusch said in Defining "Emergency" For MSP Customers:
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.
Do you charge differently for on site vs. remote support?
-
@CCWTech said in Defining "Emergency" For MSP Customers:
@JaredBusch said in Defining "Emergency" For MSP Customers:
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.
Do you charge differently for on site vs. remote support?
No, but as I’ve said many times. We are not really an MSP. Strictly consulting.
