MSP Teams in the SMB
-
@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."
-
@scottalanmiller said in MSP Teams in the SMB:
@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.
What is that client trying to get from you by asking? i'm hazy - scheduling? Are you saying the client wants a faster response than they are getting now?
-
@scottalanmiller said in MSP Teams in the SMB:
@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."
Interesting - I suppose if the hourly rate isn't affected by the number of people working on the problem, I see your point.
-
@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?
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
@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."
Interesting - I suppose if the hourly rate isn't affected by the number of people working on the problem, I see your point.
Even if it is, the time it takes to get work done is the time it takes. Same with internal IT. You need someone else at another site to look at an issue, do you move the mouse and mess with them while they look at it? Or do you wait for them to finish? Do you wait for them to drive in or just have patience? MSPs aren't magic, they work just like internal IT departments - and those use multiple people, have times when they have to wait and such all the time. It's just the cost of getting IT done. You can't get around it.
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
@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.
What is that client trying to get from you by asking? i'm hazy - scheduling? Are you saying the client wants a faster response than they are getting now?
Yes. For example, they don't want to wait until the person that they want is available, so they try to get a tech to commit someone's time without checking their schedule. Or they want work done when they've not paid for it. Or they want a named resource at the low MSP rates.
