MSP Teams in the SMB
-
@Carnival-Boy said in MSP Teams in the SMB:
And do you think you offer good value to your company or do you think they'd be better off outsourcing your position?
I'd argue that we can prove this in this simple way...
His position could be outsourced to an MSP. The customer could request him back as a full time resource. His cost to the company would be essentially the same, but with the benefit of the MSP infrastructure. No real change in cost, but with improvement in working arrangement. Any additional variation made to that, moving him to part time, bringing in other resources, would all be done solely because they were evaluated as being additionally beneficial.
Basically, if you need traditional resources, MSPs can do that as well as in house staffing (we've proven this in the real world, it's dollar for dollar the same) but the moment you need anything different than that, MSPs offer value you can't get any other way. So it's always break even... or better.
-
@Dashrender said in MSP Teams in the SMB:
@scottalanmiller said in MSP Teams in the SMB:
If someone has internal staff and wants to do an MSP cost comparison, that would be interesting. However it is SUPER hard to do unless you want to do a direct replacement, which we have done before and saved the company money because they couldn't hire the same quality of people that we could as an MSP because we have better career prospects, because an MSP works totally differently, needs to assess how the internal staff is being used inefficiently and generally is asked to do drastically more than internal IT was asked to do. So the costs often go up, because much more work is being done.
Exactly.
Also companies that employee MSPs typically understand the importance of IT, and have a better chance that they will do things right. Of course this requires that they choose a good MSP, because as much as a good MSP can help, a bad one can kill their company.True, but it is easier to get a good MSP than a good employee. Neither is easy, but one has a better chance.
-
@Carnival-Boy said in MSP Teams in the SMB:
Is that a good idea? I dunno, I've never ran the figures, but I'm not sure you have either so who can say MSPs are always better?
@scottalanmiller said in MSP Teams in the SMB:
If someone has internal staff and wants to do an MSP cost comparison, that would be interesting. However it is SUPER hard to do unless you want to do a direct replacement
I consider these two statements basically the same. Maybe there's some confusion here. I took your opening post to be about having multiple specialists (a SQL guy, a UNIX guy, a SAN guy) working for an organisation on an as and when basis, versus having a small number of dedicated generalists. Is that right?
-
@Carnival-Boy said in MSP Teams in the SMB:
Maybe there's some confusion here. I took your opening post to be about having multiple specialists (a SQL guy, a UNIX guy, a SAN guy) working for an organisation on an as and when basis, versus having a small number of dedicated generalists. Is that right?
An MSP could, perhaps should, have all of the above.
The generalist take care of the day to day helpdesk type situations. They are the first line of defense at the MSP, you call because you can't print, they help you. The specialist are who are managing and supporting things like Exchange - OK not really because any MSP worth its salt should be pushing all customers to hosted email solutions, and not ones they are hosting.
-
I stopped by my upstairs neighbors place in my office. They used to have an MSP handle their stuff. They dumped them after the MSP sent a tech who sat at their office for nearly 16 hours doing nearly nothing, my contact told me the tech was literally twiddling his thumbs. When my contact asked when it would be fix, the guy jumped to, and 30 mins later it was fixed and he left.
The MSP then billed that client for the 16 hours of the tech being there.
I have no additional details, but the client was pretty unhappy to see a tech just sitting there basically doing nothing, not typing, not searching the internet for fixes, just sitting for nearly 2 days, then suddenly, when asked when it will be fixed, hopping to and fixing it.
As Scott mentioned this was clearly and hourly bill situation, not a monthly contract (at least not a contract for break/fix - I do know they had a monthly reoccurring cost for things like backups on the server, and network monitoring).
This is clearly an example of a bad MSP - or at minimum a bad employee at an MSP.
-
@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.
Bad employees are everywhere. it is how the MSP chose to handle it that would say is it was a bad MSP.
-
@Carnival-Boy said in MSP Teams in the SMB:
@Carnival-Boy said in MSP Teams in the SMB:
Is that a good idea? I dunno, I've never ran the figures, but I'm not sure you have either so who can say MSPs are always better?
@scottalanmiller said in MSP Teams in the SMB:
If someone has internal staff and wants to do an MSP cost comparison, that would be interesting. However it is SUPER hard to do unless you want to do a direct replacement
I consider these two statements basically the same. Maybe there's some confusion here. I took your opening post to be about having multiple specialists (a SQL guy, a UNIX guy, a SAN guy) working for an organisation on an as and when basis, versus having a small number of dedicated generalists. Is that right?
Mostly correct. But I think it is two unique things. Let me make two more "thought out" statements.
-
I believe that the "dedicated IT organization" is better than the "IT department reporting to a non-IT organization" model. Meaning, if you (or any IT person) was to be moved from an internal role to a totally apples to apples role in an MSP/ITSP/DITO and sold back one to one to your old company, that this should be beneficial to everyone. Generalists can be maintained, but improved.
-
I believe that generalists should be very rare and mostly in management or oversight roles. So moving to any structure, DITO or NONDITO, where there is specialties doing the "work" and a generalist doing the "oversight" is beneficial. Fortune 1000s do this with internal IT, MSPs can bring this to SMBs.
So I think that there are two benefits here, structure of management and structure of roles. MSPs improve both, but they are two different aspects. Each is, I believe, beneficial on its own, but together become even better.
-
-
@Dashrender said in MSP Teams in the SMB:
The generalist take care of the day to day helpdesk type situations. They are the first line of defense at the MSP, you call because you can't print, they help you. The specialist are who are managing and supporting things like Exchange ...
I'd say the opposite. Ideally, and only ideally, specialists would handle all day to day (generalists L0 would handle ticket routing, but not the servicing) and generalists only brought in when you need a cross-discipline oversight.
Even desktop support people are specialists (or should be in this example.) For example, your desktop guy might be a specialist in local Windows 10 administration (local meaning NOT the guy doing Group Policy setup, not imaging, etc.) and MS Office and a few common apps used in your environment so that he can sit with the users at their desks and fix or train them.
-
@Dashrender said in MSP Teams in the SMB:
I stopped by my upstairs neighbors place in my office. They used to have an MSP handle their stuff. They dumped them after the MSP sent a tech who sat at their office for nearly 16 hours doing nearly nothing, my contact told me the tech was literally twiddling his thumbs. When my contact asked when it would be fix, the guy jumped to, and 30 mins later it was fixed and he left.
The MSP then billed that client for the 16 hours of the tech being there.
I have no additional details, but the client was pretty unhappy to see a tech just sitting there basically doing nothing, not typing, not searching the internet for fixes, just sitting for nearly 2 days, then suddenly, when asked when it will be fixed, hopping to and fixing it.
As Scott mentioned this was clearly and hourly bill situation, not a monthly contract (at least not a contract for break/fix - I do know they had a monthly reoccurring cost for things like backups on the server, and network monitoring).
This is clearly an example of a bad MSP - or at minimum a bad employee at an MSP.
Well, there is a bit of assumption there. What if that guy was busting hump for sixteen hours, knew what the issue was, had the fix underway, was waiting on a system to finish a reboot or update that had 30 minutes left and just happened to get asked how long it would be at the end after having done an excellent job for two days. We are assuming that he was twiddling his thumbs for two days, and likely that is true, but unless they really checked up, there is a ton of room for error there. What if that was an internal IT guy, would they have reacted the same? If not, why not? Internal IT staff are generally hourly as well, same factors.
-
@JaredBusch said in MSP Teams in the SMB:
@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.
Bad employees are everywhere. it is how the MSP chose to handle it that would say is it was a bad MSP.
Yup, I see so many bad people on both sides. The nice thing about working with an MSP is that there are more ways to handle it, more flexibility. We replace bad MSPs and bad internal people all the time. MSPs tend to get swapped out rapidly because it's easier to do so, so people tend to accumulate more stories about them. But more often than not, when we find companies with bad MSP horror stories, we also figure out why - because the client is a nightmare that won't pay their bills, refuses to listen, doesn't let the MSP do their jobs, etc. So suddenly you realize that the stories of most of the "other" MSPs are often made up or exaggerated. They didn't maintain that Exchange server for three years? That's because they weren't paid to do so and the customer refused service. The stories of "old IT" are not very reliable.
-
As an example, a user phones the MSP and says "I tried to open our Accounts system and I get a message saying 'not responding'. How does the MSP handle the call? How does it get routed?
-
First is getting all the information:
While still on the phone with them they get asked:
What were they doing when they got this message. Depending on the client we know if we can trust what they are telling us, or if not, we log into their machine and watch them re-create the issue.
-
@Carnival-Boy said in MSP Teams in the SMB:
As an example, a user phones the MSP and says "I tried to open our Accounts system and I get a message saying 'not responding'. How does the MSP handle the call? How does it get routed?
Well I'd need a ton more info about the situation, but here are some ideas:
-
Exactly the same as how it was before. Call goes to a "ticket router", which might be the sole IT guy, sitting in the IT room at the customer. He handles the call because he's the IT guy. Exactly the same as it is handled without an MSP, except the IT guy can call his peers at the MSP for guidance, extra eyes or "ideas" on problems. There is no reason that the MSP has to change workflow over the old system. NTG does this.
-
The call goes to a call handling location centrally where an L0 (or whoever is on the board) takes the call, puts in a ticket and decides to whom it should be assigned. If there is dedicated on site staff, likely it would go there. If there is an "accounts system" admin, it would go there. The call coming in from customer X would designate to which person or team on the horizontal axis the assignment would go and being a little technical, the L0 could decide which vertical team would be used. That logic works whether there is one person servicing the account or a thousand. NTG also does this.
-
Call system detects the number, determines client, opens a ticket to that customer's team with a voicemail.
-
Ticket goes into a pool and the next available resource picks it up irrespective of clients or application (this is not very efficient.)
-
-
@Carnival-Boy said in MSP Teams in the SMB:
As an example, a user phones the MSP and says "I tried to open our Accounts system and I get a message saying 'not responding'. How does the MSP handle the call? How does it get routed?
By whoever you have manning the phone. They will should be a L1 helpdesk type person. They will have documentation on the client and the clients LoB app.
Said document will have basic troubleshooting notes.
Once tried call goes up to a specialist based on the L1 finding errors.
-
Next it depends on what caused the issue. Troubleshooting is step two after figuring out what the client did to get said message.
This is all done in the first phone call.
-
If L1 can't handle it then a ticket is put in for up the chain for whoever needs to work on said item. Usually it's worked on very quickly from there but depends on that client's level of service they pay for.
-
Here is a more real world example, nothing makes this good or bad, it's just "how a real MSP would often handle a real situation."
- Client Y calls NTG and opens a ticket with the helpdesk. This is a human that takes the call, asks questions, determines the client, authoritization, issue basics and puts the data into a ticket along with ticket routing information. We like this method because there is immediate feedback and human verification of the issue and a human determines where the ticket goes.
- Ticket is assigned to the IT person that handles that account. @gjacobse is an example person for that, so let's say that the issue goes to him. Let's even say that it is the accounting system that is down or having a problem at client Y.
- @gjacobse logs into the customer's systems, sees that the application is really down like they said. He does some quick troubleshooting like seeing if the desktops are online, is the server up, are the services running, is there obvious issues?
- Assuming that the issue was not resolved above, @gjacobse collects documentation on the system, documents in the ticket what he has done already, determines what next step escalation is needed and escalates.
- Assuming the issue is Windows as an OS seems to be having an issue, the ticket and issue would escalate to the Windows Engineering and Administration (A&E) team who would assign someone to work on the issue to get Windows working at the server level. If they need to loop in someone from another team (say SQL Server DBA) they can do so.
- If a vendor is needed, normally @gjacobse would loop them in and get them involved and communicate logs or whatever to them while the other teams continue to work.
- @gjacobse would keep the customer up to date on the technical level (assuming there is a tech contact to talk to) or if it is all handled at a higher level, @art_of_shred would give management updates of states or completion.
Handled much like an internal ticket would be if there were enough resources for an internal team to work that way. This is how internal IT works at larger companies as well. Ticket -> Router -> Base Assignment -> Resource Team Specialists -> PM Oversight
-
@scottalanmiller said in MSP Teams in the SMB:
@Carnival-Boy said in MSP Teams in the SMB:
But in reality, the owner is more likely to take a 100% cut on top and buy a Ferrari. At least that's been the experience of all the MSPs I've known.
I've never found any MSPs like that. I certainly know that they exist, but I'm not coming across any in my travels. I know for certain that there are many MSPs not doing that that are not getting work. Maybe companies only like hiring people with Ferraris?
Before I found out about NTG, that's the only type of MSP I knew of. Know a guy that still works for one based in Youngstown, OH, and I don't know why he keeps working for them.
-
@scottalanmiller said in MSP Teams in the SMB:
@Dashrender said in MSP Teams in the SMB:
I stopped by my upstairs neighbors place in my office. They used to have an MSP handle their stuff. They dumped them after the MSP sent a tech who sat at their office for nearly 16 hours doing nearly nothing, my contact told me the tech was literally twiddling his thumbs. When my contact asked when it would be fix, the guy jumped to, and 30 mins later it was fixed and he left.
The MSP then billed that client for the 16 hours of the tech being there.
I have no additional details, but the client was pretty unhappy to see a tech just sitting there basically doing nothing, not typing, not searching the internet for fixes, just sitting for nearly 2 days, then suddenly, when asked when it will be fixed, hopping to and fixing it.
As Scott mentioned this was clearly and hourly bill situation, not a monthly contract (at least not a contract for break/fix - I do know they had a monthly reoccurring cost for things like backups on the server, and network monitoring).
This is clearly an example of a bad MSP - or at minimum a bad employee at an MSP.
Well, there is a bit of assumption there. What if that guy was busting hump for sixteen hours, knew what the issue was, had the fix underway, was waiting on a system to finish a reboot or update that had 30 minutes left and just happened to get asked how long it would be at the end after having done an excellent job for two days. We are assuming that he was twiddling his thumbs for two days, and likely that is true, but unless they really checked up, there is a ton of room for error there. What if that was an internal IT guy, would they have reacted the same? If not, why not? Internal IT staff are generally hourly as well, same factors.
I thought I left room for your added possible situation - but the fact that the tech didn't offer an explanation that of what had been going on for days, instead (as it was told to me ) the tech offered nothing, but jumped to a fix and was gone.
-
@scottalanmiller said in MSP Teams in the SMB:
What if that was an internal IT guy, would they have reacted the same? If not, why not? Internal IT staff are generally hourly as well, same factors.
Yes I think they would have questioned internal IT for just sitting there for 2 days preventing someone else from using the machine.
