Co-managed IT: what actually changes when the client keeps their own IT person

Co-managed IT — where an MSP works alongside a client's internal IT staff rather than replacing them — is usually described as a licensing and access question. Give the internal person a login, agree who does what, invoice accordingly.

The engagements that go badly rarely go badly over access. They go badly over authority: two competent parties with overlapping remits, a decision that needed one owner, and a user in the middle who has learned they get a faster answer from whichever one they ask second.

The three splits that actually work

• By layer: the internal person owns applications, users, and anything business-specific; the MSP owns infrastructure, security, and the systems that stay the same across clients. Clean, and it fails at the seam where an application problem turns out to be a network problem.
• By tier: the internal person is tier one and lives with the users; the MSP is tier two and three. Natural for the user, and it puts the person with the most context in the role with the least authority, which burns people out.
• By time: the internal person owns business hours; the MSP owns nights, weekends, and holidays. Unambiguous, and it means the MSP inherits every problem in the state it was left in at 5pm.

None of the three is correct in general. What matters is that one of them is chosen explicitly, written down, and reflected in where tickets land — rather than emerging by accident from whoever answered first for the first six months.

Co-managed engagements do not fail because two teams share a system. They fail because nobody wrote down who decides.

The escalation path is the real deliverable

The single most valuable artifact in a co-managed relationship is a written escalation path that a user can follow without knowing the org chart. Who do I contact, what happens if they are unavailable, what gets escalated to the other party and by whom.

Without it, users route around the structure — and they route toward whoever was helpful last time, which is usually the internal person, who quietly absorbs work that was contracted out and then resents the invoice. That dynamic is the most common way a co-managed relationship dies, and it is entirely a communication failure rather than a technical one.

What the internal person is actually worried about

Worth saying directly, because it changes how the first ninety days should go: the client's IT person frequently believes the MSP is the first step toward their redundancy. Sometimes they are right. Usually they are not, and the arrangement works far better when they are told plainly, early, what the MSP is and is not being brought in to do.

The practical version of that reassurance is not a conversation, it is visibility. An internal person who can see everything the MSP does — every ticket, every change, every action taken on their estate — stops guessing about their position. One who has to ask what happened will keep asking, and will hear the answer as a negotiation.

What tooling has to support

Concretely: role separation that reflects the agreed split rather than a single shared admin account; a shared ticket queue where both parties see the same history rather than two systems reconciled by email; and an audit record that lets the internal person answer their own leadership's questions without going through you.

Nexus supports this shape through per-tenant role-based access, one shared ticket and device history rather than parallel records, audit logging on write actions, and client and staff portals that give people inside the organisation their own view. The model itself is still a decision the two parties have to make and write down — the tooling can only stop the decision from being quietly undone by how the system behaves.