Skip to content
Home » Managed IT Services: Co-Managed Models and Responsibility Split

Managed IT Services: Co-Managed Models and Responsibility Split

The 24% Growth Trajectory

Co-managed IT services grew by 24% in 2023. Kaseya’s MSP Global Report documents the surge as organizations seek middle ground between full outsourcing and complete internal ownership. The appeal is obvious: retain strategic control while offloading operational burden.

The execution is harder than the concept. Co-managed models create seams where fully managed models have clarity. Those seams become friction points, accountability gaps, and operational confusion.

The Fundamental Split Problem

Co-managed IT divides responsibility between internal team and MSP. The division sounds logical. In practice, 35% of co-managed engagements experience “role collision” where both parties attempt to address the same issue or neither party owns a gap.

Split Model Internal Responsibility MSP Responsibility Collision Risk
Tier-based L1 support L2-L3 escalation Medium
Technology-based Applications Infrastructure High at integration points
Function-based Strategy, projects Operations, maintenance Medium
Hybrid Variable by system Variable by system Highest

Each model has collision points. Tier-based splits fail when L1 can’t clearly distinguish from L2. Technology-based splits fail where applications meet infrastructure. Hybrid models fail everywhere because nothing is clearly defined.

The RACI Requirement

Co-managed models require explicit RACI charts: Responsible, Accountable, Consulted, Informed. Without documented assignment, assumptions diverge.

Activity Without RACI With RACI
Server patching Both assume other handles MSP responsible, IT informed
Application updates Neither acts, gap forms IT responsible, MSP consulted
Incident first response Both respond, duplicate work MSP responsible first 10 min
Capacity planning Surprise shortfalls IT accountable, MSP provides data
Vendor management Confusion on who calls Split by vendor category

The RACI must reach granular detail. “Infrastructure” is too broad. Specific systems, specific activities, specific ownership.

The Burnout Economics

Successful co-managed models reduce internal IT burnout by 40%. The relief comes from offloading operational toil while retaining strategic engagement.

Internal IT burnout sources in pure internal models:

After-hours coverage. Someone internal must respond at 2 AM.

Repetitive tasks. Password resets, user provisioning, routine maintenance.

Vendor management. Endless calls with ISPs, software vendors, hardware suppliers.

Documentation burden. Creating and maintaining operational documentation.

Escalation anxiety. Being the last line of defense creates constant pressure.

Co-managed models shift these to MSP while internal team focuses on business alignment, strategic projects, and relationship management.

The Accountability Matrix

Clear accountability requires more than RACI. It requires defined escalation, handoff protocols, and failure ownership.

Escalation triggers. When does internal issue become MSP responsibility? Time thresholds, complexity thresholds, or impact thresholds?

Handoff protocols. How does a ticket move between teams? What information must transfer?

Failure ownership. When something falls between teams, who owns resolution? Who owns prevention?

Communication cadence. How often do teams sync? What standing meetings exist?

The matrix should answer: “When X happens, who acts first, who gets notified, and who owns the outcome?”

The Technology Boundary Challenge

Splitting by technology seems clean: MSP manages infrastructure, internal manages applications. The boundary blurs at integration points.

Application performance issues. Is slow performance an application problem (internal) or infrastructure problem (MSP)?

Database optimization. Database engine is infrastructure. Query performance is application. They interact.

Authentication failures. Active Directory is infrastructure. Application-specific permissions are application. Both affect login.

Network application dependencies. Application works but can’t reach required services. Whose problem?

Each boundary case requires predetermined resolution. Otherwise, boundary cases become finger-pointing opportunities while users wait.

The Skill Overlap Problem

Co-managed models sometimes create skill gaps. Internal team assumes MSP handles X. MSP assumes internal handles X. X doesn’t get handled.

Prevention requires:

Explicit skill matrix. What capabilities exist on each side?

Gap identification. Where do neither party have skill? Those gaps need filling.

Cross-training. Basic capability on both sides for boundary cases.

Escalation paths. When gap appears, where does it go?

The skill audit should happen before engagement and periodically during. Skill profiles change. Gaps emerge over time.

The Communication Architecture

Co-managed models require communication architecture that pure models don’t need.

Shared ticketing. Both teams see all tickets. No black boxes.

Joint documentation. Single source of truth both teams access and maintain.

Collaboration channels. Real-time communication for active issues.

Regular synchronization. Standing meetings to align on priorities and handoffs.

Escalation transparency. Each side sees what the other escalated and why.

Communication overhead is the hidden cost of co-managed models. The flexibility comes with coordination requirement.

The Internal IT Resistance Factor

Internal IT teams often view MSPs as threats. Co-managed models can exacerbate or reduce this depending on execution.

Threat perception drivers:

Job security anxiety. Will outsourcing expand to eliminate internal roles?

Competence questioning. Does bringing in MSP imply internal team is inadequate?

Control loss. Sharing responsibility means sharing control.

Credit distribution. Who gets credit when things work? Who gets blame when they don’t?

Addressing resistance requires:

Clear role protection. Explicit that co-managed reduces burden, not headcount.

Internal advantage. Internal team gets strategic work while MSP handles toil.

Relationship investment. Treat MSP as partner, not replacement.

Joint success metrics. Both teams succeed together or fail together.

The Evolution Pattern

Co-managed relationships evolve. Initial split rarely remains static.

Phase Typical Movement Driver
Year 1 Finding balance Learning what works
Year 2 Responsibility drift Convenience overrides plan
Year 3 Renegotiation Accumulated misalignment
Year 4+ Stabilization or change Either works well or needs restructuring

Planned evolution beats drift. Quarterly reviews assess whether the split still makes sense. Annual renegotiation adjusts boundaries based on learned experience.

Measuring Co-Managed Success

Metrics for co-managed models differ from pure models:

Boundary incident rate. How often do issues fall in gaps or cause collision?

Handoff efficiency. Time spent transferring between teams. Should decrease over time.

User satisfaction by team. Do users report different experience for internal vs. MSP resolved issues?

Internal capacity freed. Is internal team actually doing strategic work, or absorbing MSP coordination overhead?

Burnout indicators. After-hours work, turnover, engagement scores for internal team.

If co-managed overhead exceeds fully managed simplicity without delivering strategic value, the model isn’t working.

When Co-Managed Fails

Co-managed models fail when:

Split is too complex. Nobody can remember who does what.

Coordination overhead exceeds value. More time managing the split than doing the work.

Internal team resists indefinitely. Relationship never normalizes.

MSP treats as fully managed. Co-managed pricing with fully managed behavior.

Gaps persist. Boundary issues never get resolved, just repeated.

Recognition of failure mode enables correction. Either simplify the split, address the resistance, or acknowledge that co-managed isn’t right for this organization.


Sources

  • Co-managed growth rate: Kaseya MSP Global Report
  • Role collision frequency: Co-managed IT engagement studies
  • Burnout reduction metrics: IT workforce research