MSP Teams in the SMB
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
It seems unreasonable for them to have to call the MSP office, get their contact person, who then has to hang up (most likely) then call the tech, then call you back. Are there times when this needs to happen sure, but in SMB, it seems rare.
How is it unreasonable? How can it be unreasonable at all? You can't do this internally, how do you expect the MSP to get around the limits that any department would have? You can't, ever, unless told specifically, ever expect any tech to know the full status of anything. That's the nature of IT. I've never worked outside of a one man shop where that was reasonable at all. Internal IT included. When I worked for a cellular company doing on site tech work or a nursing agency... they were never allowed to ask us for status and we were not allowed to answer, and we were internal. The situation needed verification from remote, for example, just like an MSP would normally do. The on site guy might not know how the testing is going, what is being tested, if every step is done. If he's asked to plug in a monitor, yeah, it's reasonable to ask him how long that will take. But if he is fixing a two day long issue, not only is it generally unreasonable to ask IT for status (if we knew the issue, it would be fixed already) but to ask one cog in a machine for the status just isn't reasonable no matter how much he's the only visible cog. And why introduce the extra workflow when every other time you have one way to get status, why make a new one?
not asking for a status on things the tech standing in front of me isn't working on, only what they are working on.
-
@Dashrender said in MSP Teams in the SMB:
Now before you say - did they show the reasoning to another IT firm and see if they agreed with the reasoning? I say this doesn't matter. but if you say it does, why does it?
Because firing someone for doing a good job isn't good business and isn't good human behaviour. Let me ask you... when is it good (business, personal, whatever) to fire someone for having done a good job and helping you?
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
Now before you say - did they show the reasoning to another IT firm and see if they agreed with the reasoning? I say this doesn't matter. but if you say it does, why does it?
Because firing someone for doing a good job isn't good business and isn't good human behaviour. Let me ask you... when is it good (business, personal, whatever) to fire someone for having done a good job and helping you?
LOL of course it's probably never good - but who's to say if they are doing a good job or helping you? you or them? I suppose the only reasonable answer is a panel of experts...
-
@Dashrender said in MSP Teams in the SMB:
not asking for a status on things the tech standing in front of me isn't working on, only what they are working on.
- I can't state this enough, in a normal MSP that's inappropriate, completely. They are not your employee (unless you paid for dedicated resources AND want to manage them) and it's not your place to ask the staff what they are doing. Not okay.
- Customers routinely, and I mean ROUTINELY, don't understand the answers and get pissed off because they are confused. So it's not in an MSPs interest to let techs who are not trained or responsible for giving those answers to do so. Customers do this often in the hopes of quoting the tech and using something that they say against the company.
- Why would you do this? What is your purpose for trying to separate off one animal from the herd and trying to force it to speak on behalf of the herd? What is your reasoning for even wanting to break with the proper communications chain? What do you seek from this interaction?
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
It seems unreasonable for them to have to call the MSP office, get their contact person, who then has to hang up (most likely) then call the tech, then call you back. Are there times when this needs to happen sure, but in SMB, it seems rare.
How is it unreasonable? How can it be unreasonable at all? You can't do this internally, how do you expect the MSP to get around the limits that any department would have? You can't, ever, unless told specifically, ever expect any tech to know the full status of anything. That's the nature of IT. I've never worked outside of a one man shop where that was reasonable at all. Internal IT included. When I worked for a cellular company doing on site tech work or a nursing agency... they were never allowed to ask us for status and we were not allowed to answer, and we were internal. The situation needed verification from remote, for example, just like an MSP would normally do. The on site guy might not know how the testing is going, what is being tested, if every step is done. If he's asked to plug in a monitor, yeah, it's reasonable to ask him how long that will take. But if he is fixing a two day long issue, not only is it generally unreasonable to ask IT for status (if we knew the issue, it would be fixed already) but to ask one cog in a machine for the status just isn't reasonable no matter how much he's the only visible cog. And why introduce the extra workflow when every other time you have one way to get status, why make a new one?
You keep moving this to big projects - sure MSPs don't have to mean only one person is working on a problem - there might be a team.. but it's normally pretty obvious when this is happening - phone calls, messages, etc.. not just sitting there twiddling thumbs for 2 days (now I'm being obtuse)....
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
Now before you say - did they show the reasoning to another IT firm and see if they agreed with the reasoning? I say this doesn't matter. but if you say it does, why does it?
Because firing someone for doing a good job isn't good business and isn't good human behaviour. Let me ask you... when is it good (business, personal, whatever) to fire someone for having done a good job and helping you?
LOL of course it's probably never good - but who's to say if they are doing a good job or helping you? you or them? I suppose the only reasonable answer is a panel of experts...
Right. Unless the customer is an expert and has no need of the MSP beyond being "extra hands", they can't make this assessment and will be forced to just be random.
We've gotten this from another MSP before. They got pissed that we cost 300% what they did and refused to pay their bills. They argued that "they are an MSP and are cheaper than us, how do we justify our rates." And our answer was "because we did in one hour with one person what your team of sixty was unable to do, at all." We earned our money, but they fired us because we made them look foolish for how easy it was to fix and how obviously unqualified they were to be MSPs. Customers often fire MSPs for making IT look "too easy".
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
not asking for a status on things the tech standing in front of me isn't working on, only what they are working on.
- I can't state this enough, in a normal MSP that's inappropriate, completely. They are not your employee (unless you paid for dedicated resources AND want to manage them) and it's not your place to ask the staff what they are doing. Not okay.
- Customers routinely, and I mean ROUTINELY, don't understand the answers and get pissed off because they are confused. So it's not in an MSPs interest to let techs who are not trained or responsible for giving those answers to do so. Customers do this often in the hopes of quoting the tech and using something that they say against the company.
- Why would you do this? What is your purpose for trying to separate off one animal from the herd and trying to force it to speak on behalf of the herd? What is your reasoning for even wanting to break with the proper communications chain? What do you seek from this interaction?
huh - Well I'm definitely seeing a broken record here - in a good way mind you.
All communication should run through management(customer rep) and never through a tech. Sadly I've never worked in a company that worked this way fully. But maybe fully is just a pipe dream because, as you mention, the client might always try to get around to things they shouldn't otherwise have.
Along these lines, in my current job, I constantly push people back to their supervisor when they ask me for things - run it up the flag pole. This removes me from telling them they can't have something and them being mad at me. Sadly doesn't really work in SMB though
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
It seems unreasonable for them to have to call the MSP office, get their contact person, who then has to hang up (most likely) then call the tech, then call you back. Are there times when this needs to happen sure, but in SMB, it seems rare.
How is it unreasonable? How can it be unreasonable at all? You can't do this internally, how do you expect the MSP to get around the limits that any department would have? You can't, ever, unless told specifically, ever expect any tech to know the full status of anything. That's the nature of IT. I've never worked outside of a one man shop where that was reasonable at all. Internal IT included. When I worked for a cellular company doing on site tech work or a nursing agency... they were never allowed to ask us for status and we were not allowed to answer, and we were internal. The situation needed verification from remote, for example, just like an MSP would normally do. The on site guy might not know how the testing is going, what is being tested, if every step is done. If he's asked to plug in a monitor, yeah, it's reasonable to ask him how long that will take. But if he is fixing a two day long issue, not only is it generally unreasonable to ask IT for status (if we knew the issue, it would be fixed already) but to ask one cog in a machine for the status just isn't reasonable no matter how much he's the only visible cog. And why introduce the extra workflow when every other time you have one way to get status, why make a new one?
You keep moving this to big projects - sure MSPs don't have to mean only one person is working on a problem - there might be a team.. but it's normally pretty obvious when this is happening - phone calls, messages, etc.. not just sitting there twiddling thumbs for 2 days (now I'm being obtuse)....
Not a big project. Pretty much anything. Once you need expertise, this is what you want, a team. Sure you might have trivial little things, like plugging in a monitor. But what kind of thing do you have IT do that takes long enough to want status but doesn't require thinking, unknowns and wouldn't potentially benefit from a team?
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
not asking for a status on things the tech standing in front of me isn't working on, only what they are working on.
- I can't state this enough, in a normal MSP that's inappropriate, completely. They are not your employee (unless you paid for dedicated resources AND want to manage them) and it's not your place to ask the staff what they are doing. Not okay.
- Customers routinely, and I mean ROUTINELY, don't understand the answers and get pissed off because they are confused. So it's not in an MSPs interest to let techs who are not trained or responsible for giving those answers to do so. Customers do this often in the hopes of quoting the tech and using something that they say against the company.
- Why would you do this? What is your purpose for trying to separate off one animal from the herd and trying to force it to speak on behalf of the herd? What is your reasoning for even wanting to break with the proper communications chain? What do you seek from this interaction?
huh - Well I'm definitely seeing a broken record here - in a good way mind you.
All communication should run through management(customer rep) and never through a tech. Sadly I've never worked in a company that worked this way fully. But maybe fully is just a pipe dream because, as you mention, the client might always try to get around to things they shouldn't otherwise have.
Along these lines, in my current job, I constantly push people back to their supervisor when they ask me for things - run it up the flag pole. This removes me from telling them they can't have something and them being mad at me. Sadly doesn't really work in SMB though
Right, it's not just status. It's to stop clients from pushing techs to "do just one more thing" that isn't documented. Or to pirate software for them. Or to make changes without proper oversight and change control. It might sound silly on the surface, but in practice, it quickly becomes SO important.
-
@Dashrender said in MSP Teams in the SMB:
I will give you that, if the reasoning was sound and their fired the MSP anyhow, the client is probably a bad client and won't keep MSPs for very long because they are unreasonable, but let's not go down that path.
And that's why MSPs fire clients just as often as vice versa. But when you, as an MSP, start with a new client, they always leave out the big about having been fired and act like they did the firing.
