Client management

Co-managed IT: where the model works and where it quietly fails

Co-managed IT is the fastest growing shape of the managed services relationship, and the reason is obvious once you say it out loud: it reaches the organisations that already have their own IT people and have no intention of giving them up. The advice about how to run it has settled into a tidy list of rules, and those rules are roughly half right. This piece is for both sides of the arrangement, the provider selling co-managed IT and the internal team living inside it, and it goes through the standard advice one line at a time to separate what holds from what quietly falls over in month four.

What the co-managed IT pitch gets right

Start with the part that is true, because it is genuinely true. Kaseya's channel research has 61% of MSP leaders reporting co-managed revenue growing year on year, and that is not a fashion. It is a segment that fully outsourced managed services could never reach, because the buyer was never going to make their own IT staff redundant to sign a contract.

The complementary strengths are real too. An internal team of one to five people knows the business: which director never restarts their laptop, which line-of-business application breaks if you touch the print spooler, which invoice run cannot slip. What the same team usually lacks is depth in narrow areas, cover at 2am and during annual leave, tooling that would be absurd to license for forty endpoints, and a second opinion at the moment an incident is going badly. A provider has all four and none of the context. On paper that is a perfect trade.

The standard advice that follows is correct in outline too: document who owns what, run both teams on shared tooling, define the escalation path. The trouble is that all three are stated at a level of abstraction where they cannot fail, and the failures all live one level down.

Myth one: agree who owns what and the rest follows

The usual implementation is a responsibility matrix drawn up in the sales process. You take patching, servers and backup, we keep user support and the applications. Everyone signs it, everyone feels organised.

For planned work this holds beautifully. Patch windows, backup verification, starters and leavers, hardware refresh, projects: all of it is scheduled, all of it has an owner before it begins, and a functional split is exactly the right tool. If your co-managed relationship is mostly planned work, the matrix will carry you a long way.

It fails on unplanned work, and it fails for a structural reason rather than a discipline one: incidents do not arrive labelled with their category. "Finance cannot get into the ERP" might be a network problem, an expired certificate, a Microsoft 365 licensing change, a supplier outage or one user's cached credentials. You find out which at minute forty. A matrix that assigns ownership by category is therefore assigning ownership using an answer that nobody has yet. In the gap, both teams either start work or neither does, and the two classic failure modes appear: ticket ping-pong, where each side reclassifies the ticket towards the other, and the double-ticket loop, where the user emails internal IT and also rings the provider, and two technicians now work the same fault from different facts.

What actually holds is ownership assigned by state rather than category. Every unclassified incident has one default owner from the second it is raised. Reclassifying it may move the technical work, but it never moves who is accountable for talking to the user, and a handover is an explicit act with the current state written down, not a mention in a chat channel. Deduplication needs to be mechanical as well: same user, same asset, inside the same short window, one ticket.

Myth two: co-managed means filling the gaps

"We flex around your team and fill whatever gaps you have" is a superb sentence in a sales meeting and a poor operating model. Gaps are, by definition, undefined. They are also infinite, always urgent, and reliably composed of the work nobody in-house wanted to do.

Two things go wrong, and they compound. The commercial one is that gap work is interrupt driven and unplannable, which makes it the most expensive kind of work to deliver, and it is almost always sold at a discount on the grounds that "they do half of it themselves". The relationship one is worse. Gap-filling puts the provider in permanent implicit competition with the person who recommends whether to renew. If the provider takes credit with end users for fixes the internal team asked for, that team turns hostile inside a quarter, and hostility from that direction is fatal because they control access, information and the renewal conversation.

The version that holds is unglamorous: named services with a defined output, even where the scope is genuinely broad. "Patch compliance for all Windows endpoints, monthly evidence pack, exceptions raised within one working day" survives contact with reality in a way that "we help with patching" does not, because it can be delivered, measured and disputed. And the internal IT lead is the client, not the end user. Route the credit to them, present findings to them first, and let them take the report upstairs.

Myth three: shared tooling means giving them a login

Everyone agrees both teams should work in the same system. In practice this is usually delivered as a read-only login to the provider's platform, which is not shared tooling at all. It is a window.

Read-only has a specific cost: every action the internal team wants becomes a request, every request becomes a ticket, and the ping-pong you removed earlier comes back through a different door. What has to be shared is the state and the permission to act on it. The state that matters is unremarkable and rarely all in one place: device inventory with warranty and age, patch state per device, protection gaps including anything with no working antivirus at all, backup job outcomes, alert history, and a ticket audit trail both teams can read.

Two practical points get skipped in the excitement of a new contract. First, do not run two management agents on the same endpoint because the two parties each brought their own. Duplicate patching engines fight over reboots, contradict each other's compliance reporting, and produce the specific misery of a device that is compliant in one console and failing in the other. Second, agree at signature who owns the tenant and the licences, what an export looks like, and how long access persists after notice is served. That conversation is cheap on day one and grim on the day it matters, which is the whole argument of our client offboarding checklist.

Myth four: co-managed is the easy version of managed services

It is easier to win. It is harder to run. The overhead of a co-managed relationship is two teams, two calendars, two escalation cultures and a service level commitment measured against a partner who is also doing some of the work, and none of that appears in a proposal that prices co-managed at sixty per cent of the full stack because the client "does half of it".

Service levels are where this bites first. If your first response depends on the internal team granting access, providing a decision or confirming a change window, then either that waiting time is excluded from the clock or you should not be promising the number. Say which, in writing, before the first breach rather than after it. Our guide to setting SLA response targets you can actually hit applies here with one extra rule: a co-managed SLA needs a stated dependency clause or it is fiction.

Pricing follows the same logic. The cost driver in a co-managed agreement is the surface you are responsible for, not the number of tickets you happen to receive, because coverage costs the same whether or not anyone rings. Price the estate you monitor and the named services you agreed, add blocks for project work, and treat genuine out-of-hours cover as its own line rather than a goodwill gesture. "We sleep, you do not" is a real service and it is worth what it costs.

Ninety days in, the model is working if the internal team's own backlog is shrinking rather than the provider's, if escalations arrive with context attached instead of a forwarded email, if no incident this month was worked twice, and if the internal lead is the person presenting results to the board. If instead the provider is quietly becoming the second line for everything, you have not built a partnership, you have built an understaffed internal team with an invoice attached.

Where this fits with Helios

Helios is multi-tenant by design, so a provider and an internal team can work the same estate without either one being reduced to a spectator: the same device inventory, patch state, protection gaps, backup outcomes and ticket history, with roles that let the internal team act rather than only look. Helio, our AI layer, triages incoming tickets and runs device investigations before either team picks the ticket up, which is the part of the first hour that both sides currently spend arguing about ownership. One agent reports patching, antivirus and backup state, so there is one version of the truth to disagree with.