What do you do when a prospect already has IT? How do you handle the lead? How do you build a relationship when there’s potentially a sense of competition with the onsite resource? In other words, how do you handle co-managed prospects and clients?
A co-managed client can be great but it can backfire. So, how do you build that great working relationship?
My name is Adam Hannemann, and welcome to Ramblings of a Geek. I’ve spent the better part of the last couple decades in the MSP space and have been a part of quite a few co-managed relationships. I’ve seen some go well, and some… well, not so much.
Today we are talking co-managed. What it is, the different flavors, and most importantly how to build a solid co-managed practice.
Defining Co-managed
First, let’s define co-managed to be on the same page: Co-managed IT is when your client has an IT person or department and the goal of the relationship is to work together as a team to provide the client solid IT support and give their IT person or department a break and some backup.
Usually, these clients are on the larger side and/or have very demanding users.
The key here is that I’m making the assumption that you want to work together with their IT department, not just eventually replace them.
The goal here is a collaborative environment, not adversarial. You don’t want to replace them, and they welcome you into the fold.
Flavors of Co-Managed
There are a couple of different flavors of co-managed that seem to be more common in our space:
- You are the outsourced helpdesk/level 1 and the onsite IT group is level 2-3.
- You are the level 2-3 and they’re the helpdesk.
Projects may be done by either side. That said, if you’re doing the higher level work as the MSP you almost certainly are doing the projects.
As the MSP, you should want to run the project, but the important piece is to make sure the best project manager is the one running the project. It’s probably you because you run more projects than most internal IT departments.
Building Co-Managed Relationships
What makes a good co-managed relationship? This is the crux of the whole conversation isn’t it? Especially, if there’s any sort of an adversarial vibe from the onsite IT team. Even if you aren’t there to replace the onsite IT team, there may be a bit of apprehension to you coming in and being part of their world. My intuition with a little bit of real world observation says that when you come in to be the higher level side of things you get a little more pushback from the local IT team. On the flip side, in most of the situations where the MSP takes on the daily calls and first level items I’ve seen the local IT team be pretty happy about not having to do password resets.
So, how do you build this relationship and remove any of this adversarial situation?
As with many things, I think the core tenant of a good relationship here is properly managed expectations.
Governance Plan
The very first thing I would do, and this would be part of the sales process is to define who will perform what roles within the organization. Call this your governance plan. For each area of their IT space define who is first line of defense and who is the backup. The list could look like the following:
- Desktops -> Primary: MSP -> Secondary: Client IT
- Servers -> Primary: Client IT -> Secondary: MSP
- Phones -> Primary: Client IT -> Secondary: MSP
- Network -> Primary: MSP -> Secondary: Client IT
- Line of business apps: Client IT -> Secondary: MSP
Build the list and get agreement on it as early as possible. Then make sure that your contracts with the client reference the list. I would probably have a specific attachment for co-managed, especially if co-managed clients are part of your target client profile.
I’ve created a template that you can use in your business. Head over to the Co-Managed Governance Plan page to download your copy today.
Support Process
As part of the governance plan conversation it is imperative that you determine what the support process will be. Do all of their users call them first? Do they call you first? Who do they email? How do their users get their issues fixed?
Document that process and make it so painfully obvious that anyone that doesn’t follow it was clearly not paying attention.
Make sure that during whatever your go-live process looks like that every user gets the message about who to reach out to for help.
Stack Compliance and Toolset
I recommend getting the client on YOUR stack and tools as quickly as possible. The goal of your business is to support clients efficiently, and it’s routinely best done with your own tools. Also, many of the MSP tools are better at managing endpoints than many of the non-MSP tools. That’s not a universal truism, but our toolsets are pretty good when implemented well.
Ultimately, you will be better able to support the client if you have your own stack to utilize. If you’re able to go this route, make sure to get your client IT team logins for the tools so they can see their own endpoints that they will be supporting in some capacity.
I would also recommend using your PSA/ticketing system and building the escalation procedure so you are all working out of the same ticketing system. I’ve tried to work through different ticketing systems escalating back and forth and at best it’s a pain in the rear.
If you must use their tools they need to give you appropriate logins so your team (or a subset of your team) can log in and do their part when needed. If you are using their tools, I think it would be a good idea to build a roadmap to shift to yours as quickly as reasonable.
The MSP’s team is usually larger AND is less likely to leave the client company as a whole so working towards getting your tools in place is smart.
I might go as far as to say that if you are signing your first co-managed client and they won’t use your tools that I would consider not signing them. I would only consider signing a co-managed client without my tools after I’ve done co-managed for a bit. There’s simply more risk in not using your tools.
Building strategic relationships
Now that I’ve gotten a lot of the tactical stuff out of the way with governance plan, support process, and tools let’s talk about building and maintaining the relationship inside the company.
First, as the MSP you MUST have relationships with more than just the client’s IT team. They cannot be your only hook into the company. Having multiple levels of connection within the company will prevent knee jerk reactions to replace you at the whim of their IT team. Show your value to the c-suite of their organization and make it clear that their IT is improved by you being a part of it.
Make sure that your business review meetings include multiple stakeholders within the organization and make sure the content is relevant to all those involved.
Second, do everything you can to treat their IT team as part of your company wherever possible. If you are doing a happy-hour or company event, invite them where practical.
Take them out to lunch, do regular check-ins, and even help them with career growth and advice where appropriate. If you are doing training as a team on the MSP side, invite their team to join you in the training wherever possible.
Your goal should be one happy and cohesive team. The closer you get to that, the further away you are from being replaced because someone got a wild hair up their butt.
In addition to the business review meetings, it might make sense to do weekly check in style meetings where you cover what you’re collectively working on for the week and share any issues back and forth to help each other out.
If you do these things I think you will be setting both you and your clients up for success when it comes to co-managed relationships. Co-managed should be done deliberately and managed well. When done well these relationships can be massively profitable for you and equally beneficial to the client.
Thanks for coming on this ramble with me, and I hope to see you on the next one.