The email lands on a Saturday afternoon: the file server's nightly backup has failed for eleven straight days, and nobody noticed. The internal system administrator assumed the managed services provider owned backup monitoring, because the MSP installed the agent. The MSP assumed the administrator owned it, because his console was still open on his desk. Both were wrong, and eleven days of restore points are gone. This is exactly the failure that co-managed IT is supposed to prevent, and exactly the one it creates when the responsibility split lives in a handshake instead of on paper. A co-managed arrangement is only as strong as the boundary between the two teams, and most boundaries are drawn far too loosely to hold under pressure.

Why "we'll figure it out" becomes finger-pointing

If you have already decided that pairing your internal staff with an outside partner is the right model, you have made a sound structural call. Our overview of co-managed IT services covers why the model works and where it beats going all-internal or all-outsourced. But the model itself doesn't allocate work; people do, task by task, and wherever they don't, three predictable problems appear.

  • Gaps. A task nobody clearly owns silently stops happening. Backup verification, certificate renewals, and firmware updates are the usual casualties, because they run quietly in the background until the day they fail loudly.
  • Double-work. Both teams patch the same server on different schedules, or both open a ticket with the same carrier, and now you are paying twice for conflicting effort that occasionally collides mid-change.
  • Finger-pointing. When something breaks and ownership was never written down, the post-incident conversation becomes a negotiation about blame instead of a path to a fix. That erodes the trust the whole arrangement depends on.

None of these is a personnel problem. They are design problems, and the fix is a document, not a stronger apology after the fact.

RACI, translated for an IT operation

RACI assigns four roles to every task or decision. Applied honestly to an IT shop, it forces the uncomfortable conversations before an incident rather than during one.

  • Responsible. The person or team that does the hands-on work: runs the patch, restores the file, closes the ticket.
  • Accountable. The single owner who answers for the outcome and holds the authority to approve it. There is exactly one Accountable per row. If you have two, you effectively have none.
  • Consulted. People whose input is required before the work proceeds. This is a two-way conversation, not a courtesy heads-up.
  • Informed. People who need to know the outcome after the fact, one-way, so they are not blindsided later.

The discipline that makes a matrix work is the single-Accountable rule. In the Saturday-backup story, both teams believed they were Responsible and neither knew who was Accountable. Name one Accountable owner for backups, and that same failure surfaces on day one instead of day eleven, because someone is now obligated to look.

A domain-by-domain split that holds up

Here is a workable division for the functions that cause the most confusion. Treat it as a starting template you tune to your own staff's depth and coverage hours, not a mandate handed down from outside.

Help desk tiers

Split by tier, not by ticket. The internal team is Responsible for Tier 1: password resets, access requests, and the desk-side questions where physical presence and business context matter. The MSP is Responsible for Tier 2 and 3, plus after-hours and overflow. The internal IT lead stays Accountable for the overall user experience so escalation paths never dead-end between the two groups.

Patching and updates

The MSP is typically Responsible for the patch pipeline: testing, staging, and deploying operating-system and third-party updates on a defined cadence. Internal IT is Consulted on maintenance windows and Accountable for line-of-business application compatibility, because they know which update will break the ERP integration. Running a real pipeline instead of scattered ad-hoc fixes is the heart of the shift from reactive to proactive IT rather than break/fix.

Backups and recovery

One team, Responsible and Accountable, owns the whole chain: job configuration, daily success verification, and quarterly restore tests. Do not split backup configuration from backup monitoring across two teams. That single seam, invisible until it fails, is precisely where our Saturday story went wrong.

Security monitoring

The MSP or its security operations center is Responsible for around-the-clock alert triage and containment. Internal IT is Informed on routine events and Consulted before any action that disrupts users. Isolating an executive's laptop during quarter-close is a business decision, not just a technical one, so name who can authorize that call at 2 a.m. before the alert fires.

Projects

Assign RACI per project, not once for all projects. A network refresh might make the MSP Responsible and Accountable; a new business application might flip that, with internal IT owning the outcome. Write the split into the project charter so it is explicit before the first invoice, not litigated after the go-live slips.

Vendor management

Decide per vendor who holds the relationship. Letting the MSP be Responsible for carrier and hardware-vendor tickets removes a real burden from internal staff, but the internal lead should stay Accountable for contracts and renewals so nothing auto-renews unexamined or lapses at the wrong moment.

Strategy and roadmap

Strategy is Consulted-heavy and genuinely shared. The MSP brings pattern recognition from across its client base; internal IT brings business context nobody outside the company has. Budget authority, and therefore Accountability, stays with the internal leader or the executive they report to.

Writing the boundary down

A matrix that lives in someone's head is not documentation. Capture it as a simple grid: domains down the side, both teams across the top, one letter per cell. Attach it to the service agreement as an appendix both sides sign, and then keep it honest with a few habits.

  • Review it quarterly. As your internal team gains or loses depth, rows shift. A departure or a new hire should trigger a re-read of the matrix, not a silent gap that surfaces during the next outage.
  • Resolve every blank and every double. An empty Accountable cell is a future outage; two Accountable owners in one row are the same outage wearing a disguise. Close both before you sign.
  • Distinguish this from staffing. Co-management divides ownership between two standing teams. When you simply need more hands working under your own direction, that is IT staff augmentation instead, and the RACI collapses into your existing chain of command.
  • Let cost drive the cut lines. Where you draw each boundary carries budget consequences; our internal IT versus MSP cost comparison is the right lens for deciding which rows are cheaper to own outright versus outsource.

The Bottom Line

Co-managed IT succeeds or fails on one artifact: a written responsibility matrix with exactly one Accountable owner per domain, reviewed on a schedule and signed by both teams. Get that right and the gaps, double-work, and blame that sink most arrangements simply have nowhere left to hide. Get it wrong and you will meet all three on some future Saturday. If you are standing up a co-managed model, or trying to repair one that has already gone blurry, our co-managed IT service is built around a boundary drawn this way from day one. Reach out through our contact page or call +1 (888) 790-8777, and we will walk your functions through the matrix before an incident writes it for you.