Co-managed IT can be one of the best business relationships an organization ever has. When it works, you get the depth of an outside team layered on top of the institutional knowledge of your in-house people. When it fails, it fails loudly, and usually in ways that hurt the customer most.
Before we get into why these arrangements break down, let me define what I mean by co-managed. This is not a technical or NIST term. It is just industry shorthand for any IT support relationship where roles are shared or split between an in-house team and an outside provider.
That can look like a lot of things:
- An in-house generalist who outsources help desk to an MSP.
- An in-house help desk that outsources servers, network, and security to an MSP.
- A larger in-house team with various roles split between internal staff and the outside provider.
- An MSP used purely for backfill, taking tickets when in-house volume gets too heavy.
Whatever the shape, you have two groups sharing or segmenting the work. That is where the trouble usually starts.
Reason 1: Tribal Behavior from the In-House Team
The single most common reason co-managed relationships fail is that the in-house team starts to view the MSP as a threat. They get defensive. They get tribal. They begin controlling as much as they can and keeping as much away from the outside company as possible, because they are worried about their job.
Once that mindset takes hold, it is very hard to fix. You usually end up with one of two outcomes: the MSP gets removed, or the in-house team gets removed and the work is fully outsourced. Both outcomes are bad for the business.
Once the in-house people see the outsourced group as a threat to their livelihood, there is not much you can do to reconcile that.
The fix has to start before the relationship begins. Leadership needs to set the expectation clearly that the MSP is there to extend the in-house team, not replace it, and then back that up with structure that makes everyone’s contribution visible.
Reason 2: No Structure for the In-House Team
This is the one that quietly sinks more co-managed relationships than anything else. The in-house people may be competent, but they have no system for tracking what they do. The expectation from management is that things will get fixed and complaints will be rare. That is not a system. That is hope, and hope cannot run a business.
You can run an IT operation where everyone is highly motivated and gets things done without being watched. But that only works as long as everyone stays motivated forever and never has a bad day. In most organizations, the moment no one is looking, a few people will quietly take advantage. It is just too easy not to.
I have seen technicians literally hide in closets or sit in the data center pretending to work. Years ago I took over a team where the entire group called in claiming they had been up all night fixing a server. I checked the logs. No one had logged in. The gravy train had been running for a long time, and they did not appreciate having it shut off.
Meanwhile, a mature MSP runs on metrics. Everything is billable, everything is tracked, and the team knows the standards they are measured against. A few examples of what that can look like:
- Closing roughly 20 tickets per day per technician.
- Averaging less than 30 minutes per ticket before resolution.
- Very few reopened tickets after closure.
- Around 80 percent of time on billable support, with 10 percent on maintenance work.
To the untrained ear those sound like oppressive expectations. In practice, technicians who work inside a clear structure are usually happier. They know exactly what is expected. When they hit their numbers, their time is their own and no one is hovering.
Drop a structured MSP into a culture where the in-house team has no metrics at all, and the friction starts immediately. The MSP can prove what it did. The in-house team cannot. Guess who gets blamed when something falls through the cracks.
Reason 3: You Hired a Bad MSP
There is no kinder way to put this. Some companies are managed service providers in name only. They claim to be structured. They talk about KPIs in the sales process. Then you sign the agreement and discover the wild west. Tickets get worked when someone feels like it. The fun problems get attention. The hard ones rot on the board.
If you bring that kind of MSP into your organization, all you have done is double down on the chaos you already had.
Vet every MSP you talk to. Ask to see their cadence. Ask for the actual KPIs they hold their team to. Ask how they track ticket age, resolution time, reopened tickets, and customer satisfaction. If the answers get vague, the partnership will get vague too.
Reason 4: Two Teams, Two Different Systems
If both sides are going to share work, both sides need to live in the same ticketing and project system. This one gets sticky, because a serious MSP is going to have a much more refined system than the customer does. Asking the MSP to double-track time inside the customer’s tools slows them down and adds cost to you.
Our recommendation is almost always to use the system the MSP brings. We use ConnectWise. The ticketing portion can be carved off and given to the customer so the customer can submit tickets, track time, manage projects, and see the full picture in one place. We have a saying inside the company:
If it is not in a ticket, it did not happen.
That rule has to apply to the in-house team as well. Their KPIs do not need to be identical to the MSP’s, but they need to be similar enough that performance can be compared and gaps can be identified.
Building KPIs That Cannot Be Gamed
You cannot run an IT team on one or two numbers. People will game them. They always do.
If you tell your help desk to close 10 tickets a day, and 10 password resets at two minutes each will hit the quota, what do you think happens with the rest of the day? Even motivated people will know they could coast if they wanted to. That awareness alone changes behavior over time.
Have you ever been on a support call where the technician sounds like they want to get off the phone immediately? That usually means someone set up a ticket-count quota with no other safeguards. The technician needs to close yours so they can get to the next one and hit their number. Your problem may or may not be solved.
Here is the kind of multi-dimensional measurement that holds up:
- Ticket volume. A reasonable count per technician per day, calibrated to your environment.
- Average time per ticket. For a typical help desk, under 15 minutes is a healthy average.
- Time from ticket received to closed. This is your real customer satisfaction number. A ticket that sits on the board from 2 PM to 5 PM is a customer waiting.
- Reopened tickets. If a customer reopens an issue, that should ding the technician who closed it prematurely. This is the counterweight to ticket volume.
- Stalest tickets. Track the top five tickets with the longest unresolved time. Averages can hide a single furious customer whose ticket has been sitting for a week.
- Time mix. Roughly 70 to 80 percent on customer-facing tickets and 10 percent on maintenance work like log review, alerts, and reports.
That last one, stalest tickets, is worth its own paragraph. When we first instituted our KPIs we still had customers complaining about specific tickets that lingered. The averages looked fine. When we dug in, we found a couple of tickets had been misclassified onto the wrong board and just sat there.
I have also seen this pattern at other organizations before I started this company: a technician quietly avoids tickets from a person they dislike. Everyone else gets prompt service, the average looks great, and one decision-maker at the customer is furious because their tickets always sit. Tracking the stalest five protects against that.
Run a Weekly Cadence
Pick a day, pull the numbers, and meet for a short stand-up. We prefer Tuesday so Monday can be used to gather and clean up the data. Walk through each technician’s metrics. Thumbs up or thumbs down.
Do not call people out cold in the meeting. If someone’s numbers are off because of PTO, vacation, or a project, address that in advance so the meeting is about facts, not surprises. A weekly rhythm catches drift early. Monthly is too slow.
Internal vs External SLAs
Service level agreements are the contract that holds the metrics in place. We run two of them. Externally, our SLA tells the customer what to expect, for example a one-hour response on a typical ticket. Internally, our SLA is much tighter. We expect our team to be working a new customer ticket inside 20 minutes of receipt.
Your in-house team should have its own internal SLA, even when no MSP is involved. Without one, response times drift, and you only find out from a complaint.
Where Co-Managed Conflict Actually Happens
When the outside company and the in-house team work on completely separate things, co-managed usually goes well. Conflict shows up at the seams, where roles are shared. The classic example is a rollover queue: tickets sit with the in-house team for a while, then roll to the MSP, or the other way around.
If something falls through the cracks in that handoff, the customer is unhappy and the finger pointing starts. A good MSP can show exactly when it received the ticket and what it did. If the in-house team has no metrics, no one can show what happened on the other side. The in-house team gets blamed by default, even when the MSP was the bottleneck.
Both sides need to be measured the same way for a co-managed relationship to be fair to either of them.
Final Thought
IT teams are a little like herding cats. You set the boundaries, you reward the people who hit the numbers, and most technicians will prosper inside that structure. Leave it open-ended and you get Lord of the Flies. I have seen it almost every time.
If your shop is the rare exception that runs well without metrics, congratulations. Just understand that you are gambling on the continued goodwill of every person on your team, every day, forever. That is a bet most owners should not be making.
Co-managed IT can absolutely work. It works when the in-house team has structure, the MSP has structure, both teams use the same tools, and the metrics are designed so they cannot be quietly gamed. Get those four things right and you have one of the most powerful IT setups available to a mid-sized business.
Thinking through a co-managed setup?
If you are exploring whether co-managed IT could work for your business, or you already have an arrangement in place that is not delivering, we would be glad to talk through it. The ArcLight Group has been doing managed and co-managed IT for 18 years out of Tulsa, with deep experience in healthcare, legal, finance, and manufacturing.
Call us at (918) 270-6600 to start the conversation.
Brian Largent
Father to five, husband to one, founder, CEO, and all around swell fella (or so I'm told)
