< Back
A practical guide for business owners and internal IT staff who keep hearing the term and want the version without the sales gloss.
If you’ve started looking into co-managed IT, you’ve probably noticed something: almost every page explaining it was written by a company trying to sell it to you. The definitions are vague on purpose, the “benefits” sections all say the same five things, and nobody tells you how the arrangement actually feels once it’s running, or where it tends to go wrong.
This is the version we wish existed when people ask us about it. We sell co-managed IT, so we’re not pretending to be neutral. But the fastest way to lose a co-managed client is to oversell the model to a business that didn’t need it, so it’s genuinely in our interest to be straight with you.
Co-managed IT means your internal IT person or team keeps running things, and an outside provider works alongside them, not instead of them. You split the work. Your people handle what they’re best placed to handle; the provider covers the rest with their tools, their after-hours staff, and specialists your one-or two-person team can’t reasonably be.
The two models it sits between are easy to picture. On one end, fully managed IT means you outsource everything to a provider and have no internal IT at all. On the other hand, in-house IT means your own staff does everything, and you call an outside vendor only when something is on fire. Co-managed is the deliberate middle: you keep your person, and you give them a force multiplier.
The single most useful thing to understand is that co-managed is not “managed IT with a discount.” It’s a different shape of a relationship. In a fully managed environment, the provider owns the outcome. In a co-managed environment, ownership is shared, which is exactly why getting the split right matters so much.
This is the part the marketing pages skip, and it’s the part that decides whether the arrangement works. There’s no universal division; every good co-managed setup is negotiated, but here’s the pattern we see most often, and a reasonable starting point for the conversation.
| Responsibility | Usually, your internal person | Usually, the co-managed partner |
|---|---|---|
| Day-to-day helpdesk | Front-line tickets, the stuff staff walk over to ask about | Overflow tickets, after-hours, and when your person is out |
| Servers & infrastructure | Knows the environment, makes the calls | Monitoring, patching, and heavy maintenance at odd hours |
| Security | Day-to-day hygiene, know the people | Tooling, alerting, incident response, and the specialist depth |
| Projects & migrations | Plans around the business, owns the relationships | Extra hands and senior engineers so projects don’t stall |
| Strategy & budgeting | Knows what the business needs | Bring the roadmap, the benchmarks, and the “what others do” view |
| Documentation | Holds the institutional knowledge | Provides the system that captures it so it’s not in one head |
Notice what the internal person keeps in every row: the relationships, the context, the knowledge of how this specific business works. That’s the whole point. You’re not buying a replacement for that knowledge; you’re buying capacity and depth around it.
In practice, co-managed IT runs on shared tooling. The provider brings a stack that your internal team logs into alongside them, and this is where the model lives or dies.
A typical co-managed setup gives both sides access to the same core platforms. There’s an RMM (remote monitoring and management) tool watching every device and pushing patches. There’s a PSA (the ticketing and documentation system) where work is logged. And there’s a documentation platform, something like IT Glue or Hudu, that holds passwords, network diagrams, and procedures so knowledge isn’t trapped in one person’s memory or a spreadsheet on their desktop.
Ask, before you sign anything, who owns those tools and that data. In many arrangements, the provider owns the RMM and PSA licenses, which is fine, until you part ways and discover the documentation of your own environment leaves with them. A good provider will be comfortable discussing how documentation is transferred if the relationship ends. A cagey answer is a red flag.
The mechanics are usually one of two patterns. Either tickets route to your internal person first and overflow to the provider, or certain categories (after-hours, specific systems, anything security-related) go straight to the provider while everything else stays in-house. Both work. What matters is that the routing is written down and everyone knows it, because the failure mode is a ticket sitting in the gap between two teams, each assuming the other has it.
Most articles stop at the benefits. Here’s the honest list of how this model fails, so you can watch for it.
When responsibilities overlap instead of dividing cleanly, you get duplicated work, conflicting changes, and the occasional small disaster where both teams “fixed” the same thing in opposite directions. This is almost always a symptom of a vague split at the start. The fix is boring and essential: write down who owns what before anyone touches a server.
This is the quiet one. If your IT person hears “we’re bringing in an outside firm” and reads it as the first step toward replacing them, they may resist the whole arrangement, withhold passwords, slow-walk the onboarding, or treat the provider as a rival. It’s human. The way through is to involve them in choosing the provider and to frame it honestly as what it is: help, so they can stop being on call 24/7 and start doing the higher-value work they were probably hired for. The best co-managed relationships are the ones that the internal IT person actively wanted.
In fully managed IT, when something breaks, it’s unambiguously the provider’s problem. In a co-managed environment, “whose fault was the outage” can get murky. A serious provider heads this off with clear escalation paths and a shared definition of who is responsible for what during an incident, not so there’s someone to blame, but so there’s never a moment where everyone assumes someone else is handling it.
Sometimes the internal person leaves, the provider absorbs more and more, and one day you’re paying co-managed rates for what is effectively a fully managed service, or paying for capacity you no longer split with anyone. Co-managed should be reviewed periodically. If the balance has shifted, the arrangement (and the price) should shift with it.
Pricing for co-managed IT is genuinely all over the map because the scope is negotiated every time. Anyone who quotes you a precise figure before understanding your environment is guessing. That said, here are the models you’ll actually encounter, so you can read a proposal critically.
The real questions aren’t just the rate. Ask what counts as out-of-scope and what it costs when it happens. Ask whether after-hours and emergency work is included or billed separately. Ask whether tool licensing is bundled or added on top. Two proposals with the same headline number can be wildly different once those answers are in.
A quick gut-check. You probably want fully managed IT if you have no internal IT at all, don’t plan to hire any, and want a single throat to choke when something breaks. You probably want co-managed IT if you already have an internal person or small team that’s competent but stretched, and you want to keep them while adding tools, coverage, and depth.
The signals that you specifically need co-managed, rather than just more hours from your existing person:
If two or more of those describe you, co-managed is worth a serious conversation. If none of them do, you may just need to support the team you have, and a good provider will tell you that.
If you get to the point of choosing one, these are the questions that separate a real partner from a vendor who will quietly take over or quietly disappear:
There’s a local wrinkle worth mentioning. NYC offices come with realities a remote-only provider can’t fully cover: old buildings, shared risers, cabling that needs hands-on attention, and hardware that needs someone physically present. One of the underrated advantages of co-managed IT here is pairing your internal person with a provider who can actually show up in the boroughs when the problem is on the wall, not in the cloud. Remote monitoring handles most of it; the rest still needs a person who can get to Brooklyn.
That’s the model we run at PointerTech, a Brooklyn-based team that backs up the IT staff NYC businesses already have, rather than replacing them. If you’ve read this far and recognized your own situation in it, that’s the conversation worth having. And if co-managed turns out not to be the right fit for you, we’d rather tell you that than sell it to you anyway.
