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.
-
@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.
-
Let me ask this:
Let's say a the client asks for a reason for a service call's amount - and doesn't like that reasoning.
Let's assume they pay the bill but then choose to fire the MSP because they don't like the reasoning for the bill -
Do you have a problem with that?
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?
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.
-
@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.
