MSP Teams in the SMB
-
@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?
-
@Dashrender said in MSP Teams in the SMB:
@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.
That's how most stuff gets fixed, I think. The hands on does pretty little. You need some, but way more pondering than doing.
-
@Dashrender said in MSP Teams in the SMB:
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?
Correct. Not that Gene isn't allowed to talk, but there is a proper channel that has all the relevant information and a wrong channel that provides myopic "only my piece of the puzzle" updates. Gene can say "what he is doing" but nothing more. Same with me. Customers try to get updates from me all the time on all sorts of inappropriate things from account details, billing, hours, available resources, scheduling, you name it. Things I could not possibly answer and that they are made very aware go through the main office, not techs working on their issues. There is no way for me to know that stuff, especially while I am in the trenches dealing with their technical issues. They think I have a mental link to some mainframe that fills me in on all kinds of behind the scene details that are not related to what I am doing. Often they have questions about technical stuff I'm not involved in, as well.
-
@Dashrender said in MSP Teams in the SMB:
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.
Well, don't think of them as "the tech". Think of them as an isolated component of the MSP team. Which part? Who knows. Are they the part doing the work? The part with the estimate data? They are not your communications person (necessarily, they could be of course), they might not even be the person working. Same with internal IT. You can't just ask a random person in IT when something will be done, right? In a one person shop, sure, you are asking everyone at once. But when I worked in big shops it was common for people to try to get answers by asking any random person they could find. I was a Linux admin for FX trading, but that wouldn't stop a secretary from asking for an estimate on when I'd get her GPU replaced on her desktop. I couldn't even access the ticket system for that let alone provide useful info about it.
-
@Dashrender said in MSP Teams in the SMB:
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.
We do this all the time. Same customer, literally every time we talk to them. Does the customer remember from Monday to Tuesday? No. Or maybe they do and just hope that by tricking the tech that we will owe them better scheduling. I don't know the reason but from the MSP side, I can tell you that customers know and avoid this regularly. It's a major issue that has to be driven home, and constantly.
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
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?
Correct. Not that Gene isn't allowed to talk, but there is a proper channel that has all the relevant information and a wrong channel that provides myopic "only my piece of the puzzle" updates. Gene can say "what he is doing" but nothing more. Same with me. Customers try to get updates from me all the time on all sorts of inappropriate things from account details, billing, hours, available resources, scheduling, you name it. Things I could not possibly answer and that they are made very aware go through the main office, not techs working on their issues. There is no way for me to know that stuff, especially while I am in the trenches dealing with their technical issues. They think I have a mental link to some mainframe that fills me in on all kinds of behind the scene details that are not related to what I am doing. Often they have questions about technical stuff I'm not involved in, as well.
LOL yeah, those things or anything outside the scope of what Gene is currently working on shouldn't be inquired to the onsite tech, but the specific thing he is working on, like my example above, should be fair game to ask them.
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
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.
Well, don't think of them as "the tech". Think of them as an isolated component of the MSP team. Which part? Who knows. Are they the part doing the work? The part with the estimate data? They are not your communications person (necessarily, they could be of course), they might not even be the person working. Same with internal IT. You can't just ask a random person in IT when something will be done, right? In a one person shop, sure, you are asking everyone at once. But when I worked in big shops it was common for people to try to get answers by asking any random person they could find. I was a Linux admin for FX trading, but that wouldn't stop a secretary from asking for an estimate on when I'd get her GPU replaced on her desktop. I couldn't even access the ticket system for that let alone provide useful info about it.
That's not the same thing at all - sure, you're right, the secretary shouldn't be just asking some random tech. But I'm not talking about that. I'm talking about asking a tech you know is working on a problem that you know they are working on.... like this case above.
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.
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
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?
Correct. Not that Gene isn't allowed to talk, but there is a proper channel that has all the relevant information and a wrong channel that provides myopic "only my piece of the puzzle" updates. Gene can say "what he is doing" but nothing more. Same with me. Customers try to get updates from me all the time on all sorts of inappropriate things from account details, billing, hours, available resources, scheduling, you name it. Things I could not possibly answer and that they are made very aware go through the main office, not techs working on their issues. There is no way for me to know that stuff, especially while I am in the trenches dealing with their technical issues. They think I have a mental link to some mainframe that fills me in on all kinds of behind the scene details that are not related to what I am doing. Often they have questions about technical stuff I'm not involved in, as well.
LOL yeah, those things or anything outside the scope of what Gene is currently working on shouldn't be inquired to the onsite tech, but the specific thing he is working on, like my example above, should be fair game to ask them.
Ah, but there is the rub... how do you, as the customer, know what he's working on? Yeah, he's sitting there, but you are paying an MSP for service, you are not paying him to sit there. You don't know if he's the whole package or just one piece of a team. You don't know if he's waiting on remote people or even on the clock at the time. He might know everything, or nothing or anything in between. You can't tell from the customer side what you are looking at because this it's a staffer that you manage.
Think about a car shop, you can't grab any tech who looked at your car and ask for the status. He might be the guy swapping out your engine, he might be the guy checking your tire pressure. An MSP is a team. You can't pick out a single component and ask for the full status.
-
@Dashrender said in MSP Teams in the SMB:
That's not the same thing at all - sure, you're right, the secretary shouldn't be just asking some random tech. But I'm not talking about that. I'm talking about asking a tech you know is working on a problem that you know they are working on.... like this case above.
There is no such thing in an MSP. You are thinking of a staffing situation where that person is your employee and you assign to a task and you manage who is and isn't working on the task. That's not an MSP or "department" mode. That doesn't work in a two person IT shop or larger (you might get lucky there, but no guarantee) and doesn't work in an MSP (unless it is a one man show.) There is no guaranteed concept of "the tech working on the issue."
