Co-Managed IT: How to Share a Ticket Queue Between In-House IT and an MSP
By the Helios team
Most co-managed arrangements fail in the queue, not in the contract. The statement of work says who owns what. The ticket queue says who actually does what, and the two drift apart within a month. The co-managed IT services model works when both sides can look at the same list and know, without a meeting, whose ticket each one is. It fails when every ticket is technically both parties' problem and therefore practically neither's. Here is how to design the split, the routing and the reporting so that never happens, ending with a one-page agreement you can put in front of your partner this week.
Split responsibilities by layer, not by ticket type
The instinct is to split by category: MSP takes servers, in-house takes desktops, or MSP takes security, in-house takes users. It sounds tidy and it collapses immediately, because real tickets cross categories. A user cannot log in: is that a desktop problem, an identity problem or a security problem? Nobody knows until someone investigates, and if the category decides ownership, the investigation itself is nobody's job.
Split by layer instead. One side owns the infrastructure layer: servers, identity, Microsoft 365 tenancy, backup, patching policy, security tooling. The other owns the user layer: first contact, desk-side support, onboarding and offboarding execution, hardware, the things that require knowing that Sandra in accounts always means the shared mailbox when she says "my email". In most arrangements the in-house team takes the user layer because they are in the building, and the MSP takes the infrastructure layer because they run the same stack across many clients. Sometimes it is the other way round. Either works. What does not work is both sides owning both layers.
The 2am test: for every service you run, ask who gets woken up when it breaks at 2am. If the answer is "whoever notices first" or "we'd discuss it", that service has no owner and it belongs on the agenda for your next meeting, not in production.
We have written before about where the co-managed model works and where it quietly fails. The short version: it fails wherever ownership is implied rather than written down.
Queue design for the co-managed IT services model
One queue, two owners, clear routing. Resist the temptation to run two separate ticketing systems, one per side, with tickets emailed between them. Skip this and you get the classic co-managed pathology: a ticket that is "with the MSP" according to the in-house system and "awaiting client" according to the MSP's, while the user waits and both sides believe they are blameless. A shared queue removes the argument because there is only one record.
The routing rules should fit on a napkin:
- First contact goes to the user-layer owner. They triage, resolve what they can, and reassign anything that touches the infrastructure layer. Triage is a five-minute job, not a diagnosis.
- Alerts go straight to the infrastructure-layer owner. Monitoring alerts, backup failures and patch failures should never route through the user-layer team. They are not user problems yet and routing them through the desk just adds latency. If your alerts are too noisy for one side to own outright, that is a separate problem worth fixing before you share a queue.
- Reassignment resets nothing except the assignee. The SLA clock keeps running from first contact. The moment reassignment pauses the clock, reassignment becomes a way to hit targets without helping anyone, and your queue fills with tickets being gently passed back and forth like a parcel nobody wants when the music stops.
- Every ticket has exactly one assignee at all times. Not a team, not "both". A person or, at worst, a side. Shared assignment is unassignment wearing a rota's clothes.
Permissions: least privilege applies to partners too
Co-managed arrangements have a habit of starting with both sides holding global admin everywhere, because it was easiest on day one. It is also how one compromised account at either organisation becomes a full compromise of the estate. Least privilege is not a courtesy between partners; it is the thing that limits the blast radius when one of you has a bad day.
The practical version: the infrastructure-layer owner gets admin on the systems they own and read access on the rest. The user-layer owner gets the delegated roles they need, password resets, licence assignment, device enrolment, and nothing above them. In Microsoft 365 that means proper role assignment rather than everyone being Global Administrator, which is worth doing anyway and features on our Microsoft 365 security checklist. Named accounts only, on both sides. A shared "msp-admin" login means your audit trail says "someone did something", which is not an audit trail, it is a shrug in log form.
Escalation paths that survive contact with a real incident
Escalation in a co-managed setup has two directions and both need writing down. Upward: the user-layer team hits something beyond their access or expertise and hands it to the infrastructure-layer owner, with the triage notes attached, not a one-line "user says it's broken". Sideways: an incident spans both layers, ransomware being the obvious case, and someone has to be incident lead. Decide now, in peacetime, which side leads a security incident, because deciding during one costs you the first hour, and the first hour is the one that matters.
Agree a severity ladder with response expectations at each rung, and make it the same ladder for both sides. If the MSP promises a 15-minute response to a priority one and the in-house team works office hours only, that is fine, but write it down so the gap is a known gap rather than a surprise. If you have never set response targets you can actually hit, start with realistic SLA response times rather than aspirational ones.
Documentation: one source of truth or two sources of doubt
Both sides will accumulate documentation. If it lives in two places, it will disagree, and the disagreement will surface at the worst moment, usually mid-incident when someone follows the runbook that was superseded eight months ago. Pick one home for network diagrams, credentials, runbooks and asset records, give both sides write access, and make "update the doc" part of closing any ticket that changed anything. It is dull. It is also the difference between a partner and a dependency.
Reporting so neither side wears the other's backlog
The quiet killer of co-managed relationships is the blended report. One chart of ticket volume and resolution times for the whole queue, presented to the business, in which the MSP's backlog and the in-house team's backlog are indistinguishable. Whoever presents the report gets blamed for all of it. Whoever does not gets away with anything.
Report by owner, always. Volume, ageing and SLA performance split by which side held the ticket, with reassignment time counted against the side that sat on it. This is not about apportioning blame; it is about making blame impossible to apportion wrongly. When both sides can see their own numbers, the monthly review becomes a working session instead of a tribunal.
The one-page agreement: a table of services with a single owner each, the napkin routing rules, the severity ladder, the named incident lead, the documentation home, and split reporting. If it does not fit on one page, you have not finished deciding.
The two ways this fails, side by side
Failure by overlap: both sides monitor the same servers, both hold global admin, both keep their own docs. Everything is done twice or not at all, and every incident starts with an argument about whose alert it was.
Failure by gap: the split was agreed once, then the estate changed. A new SaaS platform arrived, nobody claimed it, and it sat unowned until it broke. The fix for both failures is the same: review the one-page agreement quarterly, and treat any ticket that took more than one reassignment as evidence the page needs editing.
Where this fits with Helios
Most of this article is agreement and discipline, not tooling, and no platform will rescue a split that was never written down. What tooling can do is make the shared queue real: Helios gives an MSP and an in-house team one service desk with email-to-ticket, SLAs that keep running through reassignment, and a client portal, alongside monitoring and patching in the same place, so alerts route to the infrastructure owner without passing through the desk. When the AI agent investigates an alert or drafts a fix, it works under per-client approval guardrails, which matters in co-managed setups where two organisations need to trust the same automation.
Helios is a flat-rate RMM and PSA for small MSPs and IT teams: £99 to £399 a month, every feature on every plan, monthly billing. 14-day trial, no card, no feature gating. Start free.