MSP Teams in the SMB
-
@scottalanmiller said in MSP Teams in the SMB:
Maid comes to clean my house. She's there ALL day long. I show up at the end of the day. I find her sitting around. I ask her when the floors will be dry so I can walk across the. She says in five minutes. I wait for her to go home and call the maid service and fire them because she "sits around the house all day" because I "checked and the floors weren't dry when I got home but were minutes later so clearly they do no work."
I think this is not an acceptable comparison to the tech. You could easily look around the rest of the house and see it was clean - my question is.. why is she sitting around at all? If the answer is, she can't leave until the floor is dry, fine, but if it's .. well she was done - then why didn't she leave? Yes there are all kinds of reasons she was 'sitting' around... some valid some not. but unlike the computer - you could inspect the other things she was suppose to clean to know work was done.. in the computer, it's pretty much an all or nothing situation.
If the work really took that amount of time, I'm sure the tech COULD have provided a reason for it that could satisfy the customer.
-
@scottalanmiller said in MSP Teams in the SMB:
- MSP provided good estimate of completion when asked.
What? I never said that!
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
- MSP provided good estimate of completion when asked.
What? I never said that!
are you claiming this because they guy left 30 mins after he was asked... if you are, that's an assumption on your part... my contact never told me the tech offered a repair time either when the call was opened or when he inquired about the status near the end of 2 days. I have no idea if he was given a time or not. this line just needs to be removed because it's completely unknown.
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
- MSP provided good estimate of completion when asked.
What? I never said that!
Oh, I thought that you had said that they asked how long, and he said half an hour. He didn't respond and just was done in half an hour?
-
@Dashrender said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
- MSP provided good estimate of completion when asked.
What? I never said that!
are you claiming this because they guy left 30 mins after he was asked... if you are, that's an assumption on your part... my contact never told me the tech offered a repair time either when the call was opened or when he inquired about the status near the end of 2 days. I have no idea if he was given a time or not. this line just needs to be removed because it's completely unknown.
Gotcha, I got that part incorrect. I'll adjust.
-
There you go.
-
@scottalanmiller said in MSP Teams in the SMB:
Instead of working from assumption, let's look at only the factual bits:
- MSP fixed the issue.
- MSP took two days to fix the issue.
- MSP provided good estimate of completion when asked.
Those are the facts. The rest is conjecture and coincidence. Sure, there is every possibility that the tech was sitting idle wasting time. There is always every possibility that he was not. What we know for sure is that from the info given, the company has zero, literally zero, reason to fire the MSP. Maybe they have more info that they are not telling us, but maybe not. But if they did, don't you think they'd want it to sound like a valid firing rather than bragging that they randomly fired a guy who helped them out?
LOL bragging - lol there was no bragging. They were unhappy with any reasoning they did receive, or didn't receive any for the amount of time that ticket took.
They also told me that they were slow to respond to tickets in general - but I have no idea what their SLA was, so can't say if this was acceptable or not.I'm not defending them firing them or not.. I'm just wanting to make sure Scott isn't crucifying someone when there really isn't enough information.
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
- MSP provided good estimate of completion when asked.
What? I never said that!
Oh, I thought that you had said that they asked how long, and he said half an hour. He didn't respond and just was done in half an hour?
He did ask - but didn't tell me if there was a response.. left out that detail. He simply moved on to telling me that 30 mins later he left and it worked.
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
Instead of working from assumption, let's look at only the factual bits:
- MSP fixed the issue.
- MSP took two days to fix the issue.
- MSP provided good estimate of completion when asked.
Those are the facts. The rest is conjecture and coincidence. Sure, there is every possibility that the tech was sitting idle wasting time. There is always every possibility that he was not. What we know for sure is that from the info given, the company has zero, literally zero, reason to fire the MSP. Maybe they have more info that they are not telling us, but maybe not. But if they did, don't you think they'd want it to sound like a valid firing rather than bragging that they randomly fired a guy who helped them out?
LOL bragging - lol there was no bragging. They were unhappy with any reasoning they did receive, or didn't receive any for the amount of time that ticket took.
They also told me that they were slow to respond to tickets in general - but I have no idea what their SLA was, so can't say if this was acceptable or not.I'm not defending them firing them or not.. I'm just wanting to make sure Scott isn't crucifying someone when there really isn't enough information.
I'm not crucifying at all, I'm just stating that they example is pointless. It doesn't show or even suggest an MSP doing a bad job. Just that a customer fired an MSP and the impression given was that the MSP was doing a bad job and people responded as such as, correct me if I am wrong but the intention of the example being given was to portray a bad MSP, but nothing in the example actually shows them having done anything bad.
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
- MSP provided good estimate of completion when asked.
What? I never said that!
Oh, I thought that you had said that they asked how long, and he said half an hour. He didn't respond and just was done in half an hour?
He did ask - but didn't tell me if there was a response.. left out that detail. He simply moved on to telling me that 30 mins later he left and it worked.
So we really have nothing to go on. Why was the person telling you this story without enough details to know which party was supposed to have failed? I feel like it's the framework of a story, but nothing more. If the tech was idle for days and only wrapped up because prompted, the MSP failed. If the tech did a great job and they coincidentally checked up before the work was done, the MSP did a good job (in the one instance we are discussing) probably. But without those details, the story is...
MSP fixed and issue and was fired. The end.
That's it. We don't know if two days was a good amount of time for the issue, what the issue was, what the agreement was between the two parties... nothing.
-
@Dashrender said in MSP Teams in the SMB:
This is clearly an example of a bad MSP - or at minimum a bad employee at an MSP.
Here is the wrap up of your original statement. That the MSP or the employee WAS BAD. But we don't have any idea if that is true. Not in the slightest. It's reasonable, it's likely. But there is a huge chance for it not to be true, either. If it was true, we'd expect the story to have details making it seem like it was true rather than just pointing out a coincidence. We know that a customer acting annoyed because IT "appears idle" while thinking or waiting for a process causing us to want to "look busy." That someone "appeared idle" and "hopped to" in IT, as we all know, means literally nothing.
I feel pretty confident that I'm not reading into this, there were assumptions made without basis and the MSP crucified in this thread. But the reality is, we have no reason to think that (or to not think that.) We simply know nothing about the situation. Given that we hear only one side of the story and it sounds so fishy, if we were placing bets I'd bet that it was the customer acting inappropriately, but there is no way to know without a lot more info.
-
@Dashrender said in MSP Teams in the SMB:
If I hire you to do work for me.. and I see you sitting there for 2 days doing what appears to me like you just twiddling your thumbs for that time and I ask you what the status is - I fully expect a full blow by blow what you have been doing for 2 days. As the customer I feel I have to right to inquire what you are doing with the time I am paying you for.
Well, I'd say that that is a foolish expectation. A tech may not even be allowed to provide that. You can't have that expectation, you can't. Unless you ask for a blow by blow, have demonstrated that you will understand the answer and are speaking to your account rep and not the hands on tech doing remote hands for an engineer potentially you can't even begin to think that that is how it should work. Can you demand that in your contract? Sure. Unless you know that this customer did that, you can't make this claim, at all. In fact, if a customer said this I'd assume that they knew that they were just making excuses. It's a totally unreasonable thing. That tech is probably there for tech skills, not to be a customer interface guy for the account management team. And the customer is NOT paying that tech, they pay the MSP. The tech has a manager to report to. We have this problem all the time, customers trying to cause problems by knowingly skirting the communications chain hoping to break something, get info, get free service, scare someone or whatever.
-
@Dashrender said in MSP Teams in the SMB:
I'm not defending them firing them or not..
But you said that clearly the MSP or employee was wrong. How is that not defending?
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
Maid comes to clean my house. She's there ALL day long. I show up at the end of the day. I find her sitting around. I ask her when the floors will be dry so I can walk across the. She says in five minutes. I wait for her to go home and call the maid service and fire them because she "sits around the house all day" because I "checked and the floors weren't dry when I got home but were minutes later so clearly they do no work."
I think this is not an acceptable comparison to the tech. You could easily look around the rest of the house and see it was clean - my question is.. why is she sitting around at all? If the answer is, she can't leave until the floor is dry, fine, but if it's .. well she was done - then why didn't she leave? Yes there are all kinds of reasons she was 'sitting' around... some valid some not. but unlike the computer - you could inspect the other things she was suppose to clean to know work was done.. in the computer, it's pretty much an all or nothing situation.
If the work really took that amount of time, I'm sure the tech COULD have provided a reason for it that could satisfy the customer.
It's a decent comparison. They could look around and see that the issue was fixed. Why is she sitting? Because she doesn't want to walk across a wet floor and get it dirty again. Or she is done, waiting to leave. Why do you care that she is sitting, you pay for results, not process. It's VERY bad business to care "how", rather than for the results.
We don't know if the tech COULD provide an answer. We don't know if they are allowed to, can explain it, if the customer would understand it or if they even did. Did the customer ask? Unless the customer told you they did, you must assume that they did not and the tech didn't know that they should explain something that had no need to be explained.
-
@Dashrender said in MSP Teams in the SMB:
The MSP wasn't fired after this single instance, there were many issues this was just an instance they specifically mentioned to me. Yes I glossed over the other issues mentioned to me. But they had several complaints. Sadly price was one of them..
It's totally reasonable that the MSP was garbage. But the example given didn't demonstrate it. But that's the problem we see constantly - this ire against IT in general and jobs that primarily involve "thinking" being treated like freeloaders. That only manual labour is valid. IT is a thinking job. I spend 90% of my day pondering, 10% doing. If I pondered less, my doing would be far less effective.
-
@Dashrender said in MSP Teams in the SMB:
You're saying that someone asking for a status update means they are trying to get rid of you? really? That seems backwards..
That's not what I said. I said that the way it was done was fishy. They asked someone that is not even slightly likely to be the appropriate person. We aren't even clear what they asked or what was responded. What we've NOT heard about is if they checked on the status from the right party. That's never been said at all. So without that info, we have to assume that they might not have. The tech is almost never the right party. That none of the info that would come from asking the right party was provided, there is very little chance that they did. What did the MSP say when they asked management? Why is ALL info that makes this make sense missing? Because they don't know how to tell a story? Or they know how to sell the story?
If I ask a tech instead of my communications person for a status, yes, that's setting them up for failure. MSPs, 95% of the time, have proper channels for this. If you avoid them, which most customers do, that's setting the MSP up for blame. What if the MSP was telling status updates to the janitor instead of management? Same issue, right?
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
I'm not defending them firing them or not..
But you said that clearly the MSP or employee was wrong. How is that not defending?
I had more details than I provided you..
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
The MSP wasn't fired after this single instance, there were many issues this was just an instance they specifically mentioned to me. Yes I glossed over the other issues mentioned to me. But they had several complaints. Sadly price was one of them..
It's totally reasonable that the MSP was garbage. But the example given didn't demonstrate it. But that's the problem we see constantly - this ire against IT in general and jobs that primarily involve "thinking" being treated like freeloaders. That only manual labour is valid. IT is a thinking job. I spend 90% of my day pondering, 10% doing. If I pondered less, my doing would be far less effective.
LOL pondering is what lead me to resolve my IP Helper-address issue a few days ago.
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
You're saying that someone asking for a status update means they are trying to get rid of you? really? That seems backwards..
That's not what I said. I said that the way it was done was fishy. They asked someone that is not even slightly likely to be the appropriate person. We aren't even clear what they asked or what was responded. What we've NOT heard about is if they checked on the status from the right party. That's never been said at all. So without that info, we have to assume that they might not have. The tech is almost never the right party. That none of the info that would come from asking the right party was provided, there is very little chance that they did. What did the MSP say when they asked management? Why is ALL info that makes this make sense missing? Because they don't know how to tell a story? Or they know how to sell the story?
If I ask a tech instead of my communications person for a status, yes, that's setting them up for failure. MSPs, 95% of the time, have proper channels for this. If you avoid them, which most customers do, that's setting the MSP up for blame. What if the MSP was telling status updates to the janitor instead of management? Same issue, right?
Having no personal experience with MSP - especially a good one, I have no idea about this.
Not asking the tech - really? Assuming the appropriate person was asking the tech - it does seem weird to me that you couldn't ask a tech for a status update. But i'll have to bow to your infinitely larger exposure.
I would also expect that if all questions like that had to be run through a client rep at the MSP, then the MSP needs to inform the customer of that fact when they become client/vendor.. but I have no idea what the protocol setup was for them.
-
Question - is an ITSP any different?
If Gene is working for a customer onsite at a client, and the right party at the client wanted a status update, would they be required to call Art instead of asking Gene?
