A 75-person distribution company in Stafford brought in an MSP to help their lone IT manager, and for a month everyone was thrilled. Then a user’s laptop wouldn’t connect to the VPN. She emailed the internal manager, who started troubleshooting — and she also called the MSP’s helpdesk, who opened a ticket and started troubleshooting. Two skilled people spent an hour each chasing the same problem from opposite ends, stepping on each other’s changes, before they realized they’d both been on it the whole time. Annoying, wasteful, but survivable.
The one that actually hurt came two months later. The internal manager assumed the MSP was now patching the servers — the whole reason they’d signed up. The MSP assumed the manager still had them, since he’d been so protective of them during onboarding. For nine weeks, nobody patched anything, and a known vulnerability sat wide open the entire time. Nothing exploded, but it easily could have — and not one person had been negligent. They’d simply never written down who owned what. This post is about the single document that prevents both stories: the written responsibility matrix.
Two failure modes, one fix
If you take nothing else from this series, take this: co-managed IT lives or dies on the responsibility matrix. It’s a plain table that names, line by line, who owns each piece of IT — internal team, MSP, or shared. It isn’t paperwork for its own sake; it prevents two specific, predictable failures that show up whenever two capable teams share an environment.
Double-ticketing: both teams work the same issue
When the line is fuzzy, work gets done twice. A user reports a problem to both sides, or an alert fires and both teams jump on it. You burn hours, you risk two people making conflicting changes to the same system, and you annoy the very users you’re trying to help. It’s the visible, embarrassing failure — and the less dangerous of the two.
Orphaned work: each team assumes the other owns it
This is the quiet killer. Both teams look at a task — patching, a backup verification, a security alert — and each assumes the other has it, so nobody does. Double-ticketing wastes time you can see; orphaned work creates risk you can’t see until the day it detonates. The most dangerous orphans are always the same three: patching, backups, and security monitoring — precisely the things that fail silently and only announce themselves during a breach or an outage. A matrix exists, above all else, so none of those three ever falls into the gap between two teams.
What actually goes in the matrix
A good matrix is specific. “The MSP handles security” is not a line item — it’s a future argument. Every function that could plausibly be owned by either side gets its own row, with an owner and, where it matters, an escalation path. At minimum, cover these:
- Helpdesk tiers — who takes Tier 1 (password resets, “the printer’s offline”) versus what escalates, to whom, and when.
- Patching — who patches servers, workstations, network gear, and third-party apps, on what cadence, and who confirms it actually happened.
- Security monitoring & response — who watches the alerts, who responds to each alert type, and what happens at 3 a.m. on a Sunday.
- Backup & restore testing — not just who runs backups, but who periodically tests a restore, because an untested backup is a guess.
- Vendor management — who calls the ISP, the line-of-business software vendor, the printer lease company when something breaks.
- Projects — who scopes, leads, and staffs migrations, rollouts, and upgrades versus who keeps the lights on while they happen.
- After-hours / on-call — the single most important row to get right, because it’s where assumptions hide. Who carries the phone nights, weekends, and holidays?
- Onboarding / offboarding — who provisions a new hire’s accounts and who kills access the hour someone leaves (the offboarding side is a security control, not a courtesy).
- Documentation ownership — who keeps the network diagrams, passwords, and runbooks current, and where they live so both teams see the same truth.
A framework for drawing the line
Deciding who owns each row sounds hard. It isn’t, if you apply one principle consistently: keep what your team is uniquely good at; hand off what’s commoditized, constant, or specialized.
Keep what’s yours
Your internal team should own the things that need someone who knows your business — your users, your culture, and especially your weird line-of-business application that no outsider will ever understand as well as the person who’s lived with it for six years. That knowledge is the whole reason co-managed beats fully outsourced for you. Don’t hand it away.
Hand off the rest
Give the MSP the work that is the same at every company, runs around the clock, or demands a specialist:
- Commoditized — patching and routine monitoring look the same everywhere; there’s no business-specific edge in doing them yourself.
- 24/7 — anything that has to be watched at 2 a.m. is work no single person or small team can cover alone.
- Specialized — security operations, advanced infrastructure, and compliance work that’s a discipline, not a side task.
This is the philosophy behind our co-managed IT services, and the same instinct Bob Coppedge of Simplex-IT built the model on: a good partner lifts internal IT up rather than replacing it. He titled his book for internal staff “I Don’t Want Your Job” on purpose — and notes that roughly 70% of MSPs already have a co-managed client without realizing it, which tells you this way of dividing work forms naturally the moment a capable internal person is in the picture. The matrix just makes the division explicit instead of accidental.
How to build it — and keep it alive
The matrix is built in a working session with both IT leads, during onboarding, and you don’t rush it. This is not a form the MSP fills out and emails over. It’s a conversation: the internal lead and the MSP’s lead sit down, walk every function above, and decide — out loud, together — who owns each one. Talking it through is half the value, because that’s where the “wait, I assumed you had that” moments surface safely on day one, instead of nine weeks later with an unpatched server.
And it’s a living document, not a stone tablet. Teams change: your internal person levels up and takes security back in-house, a key employee leaves and the MSP absorbs more for a while, a new compliance requirement adds rows that didn’t exist last year. The matrix gets revisited at your regular reviews and adjusted — painless precisely because co-managed engagements are month-to-month with no long-term lock-in. The split is never a life sentence; it’s a snapshot of who’s best positioned to own each thing right now.
A simple example split for a Houston SMB
Here’s a clean starting point we’d sketch for a typical 60-to-100-person Houston business with one capable internal IT person:
- Internal IT owns: Tier 1 helpdesk and the user relationship, the line-of-business app, onboarding requests, and day-to-day decisions about the environment.
- MSP owns: servers and infrastructure, security operations and 24/7 monitoring, patching across the board, backup and restore testing, and the after-hours phone.
- Shared (with a named escalation path): projects and documentation — led by whoever has the depth, visible to both.
That single page ends both failure modes at once. Nobody double-works a ticket because routing is defined, and nothing gets orphaned because every dangerous row — patching, backups, monitoring — has exactly one named owner. Everyone works from the same shared tools and dashboards, so both sides see the same reality. (For where this sits in the bigger picture, the full model is in the pillar, what is co-managed IT.)
The honest caveat: a bad matrix is worse than none
We won’t oversell the document. A vague or rushed matrix is genuinely worse than none — because it gives everyone false confidence that the lines are drawn when they aren’t. “Security: shared” reads like a decision and is actually a coin flip on who answers the 3 a.m. alert. The dangerous orphans love a fuzzy matrix even more than no matrix, because nobody’s on guard.
The deeper risk isn’t the spreadsheet, though — it’s ego and turf. Matrices stay vague when someone won’t say out loud who’s really responsible, or an internal person feels threatened, or the MSP doesn’t want to look like it’s grabbing territory. Clarity is the fix for all of it. A specific, honest line that says “the MSP owns this and your team owns that” protects everyone — it makes the internal person the leader who set the partnership up right, not the one blamed when something nobody owned finally breaks.
Frequently asked questions
How detailed does the matrix really need to be?
Detailed enough that no row leaves room for “I thought you had it.” Every function with one named owner, and an explicit escalation path for the shared and after-hours items. If a line could be read two ways at 3 a.m., it’s not done yet.
What if we’re not sure where to draw a line?
That’s exactly what the onboarding working session is for — both leads talk it through until it’s clear, and the default is simple: keep what’s business-specific in-house, hand off what’s commoditized, 24/7, or specialized. You can also get a cost ballpark first with our pricing calculator.
Does the matrix mean we lose control of our IT?
No — it’s the opposite. The matrix is how internal IT keeps control: you decide what you own, you keep the user relationship and the business-critical systems, and you see the same dashboards the MSP does. It documents a partnership, not a handover.
The bottom line
The responsibility matrix is the core mechanic of co-managed IT — the one document that decides whether two capable teams multiply each other or trip over each other. It kills double-ticketing by defining who routes what, and it kills the far more dangerous orphaned-work problem by giving patching, backups, and monitoring exactly one owner each. Build it together in an unhurried onboarding session, keep what your team is uniquely good at, hand off what’s commoditized or constant or specialized, and revisit it as things change. Get it specific and honest and co-managed IT becomes a force multiplier; leave it vague and you’ve bought a more expensive way to drop the same ball. To draw your split the right way, book a free discovery call and bring your IT lead — this works best with the person who’ll live the matrix in the room.
Aspendora Technologies provides co-managed IT and managed IT services to Houston-area businesses, since 2010.