The single biggest predictor of whether a co-managed IT relationship works is whether the boundary between internal and external responsibility was written down before the first incident, or improvised during it. An undefined boundary doesn't stay neutral — it defaults to confusion, duplicated effort, or a gap where each side assumed the other was covering something nobody actually owned.
A workable split usually separates by relationship and by discipline, not by ticket volume. Internal IT typically keeps the frontline relationship — user requests, day-to-day troubleshooting, and the institutional context of how the business actually operates. The external partner takes named ownership of specific platforms or disciplines the internal team lacks the specialist depth for: cloud infrastructure, network architecture, advanced security controls, complex escalations.
The boundary needs to specify three things concretely: which systems each side owns, what the escalation path looks like when an issue crosses that boundary, and what happens during the handoff — who initiates it, what information travels with it, and how quickly. "We'll figure it out when it happens" is the sentence that produces the worst incidents, because it happens under time pressure with two parties each assuming the other has already started.
It's worth revisiting the split periodically rather than treating it as fixed at the start of the relationship. As an internal team's capability grows, or as the environment changes, work that made sense to hold externally at the outset may reasonably move internal, and vice versa.
Done well, the internal team never has to wonder whether calling in the external partner is an admission of failure — it's simply how the agreed boundary works, which is what makes the model sustainable rather than adversarial.
All technical perspectives