MSP project management for co-managed IT

Co-managed IT is a partnership, not a handoff. The client keeps an internal IT person or team, and your MSP fills the gaps — projects, escalations, after-hours coverage, specialized skills, or simply extra hands. It works when both sides can see the same plan and know exactly who owns what. It breaks the moment your project tracking lives somewhere the client can't reach, or somewhere you'd never let them log in.

The job to be done

You are running project work that two teams execute together. A server migration where the client's admin handles on-prem and you handle the cloud cutover. A security rollout where your engineers deploy the tooling and their staff owns user communication and change management. The client's internal team wants to contribute — assign themselves tasks, comment, and watch the timeline move — and their leadership wants status they can trust without a standing weekly call. Your job is to coordinate the shared work, keep everyone honest about ownership, and give the client genuine visibility into progress.

Where it usually goes wrong

Most PSA project modules were built for your technicians, not your client's. Autotask Projects, ConnectWise, and HaloPSA are mature and billing-native, but they assume the only people inside a project are on your payroll. So co-managed status turns into a chore: weekly screenshots, a shared spreadsheet that drifts out of date within a day, a status email nobody opens.

The tempting shortcut — handing the client a PSA login — is the one you should never take. Your PSA holds your rates, your margins, your other clients, and your internal notes. One login exposes all of it. So you either overshare, or, far more often, you undershare and let the client fly blind through the most stressful part of a project — the part where they most need to see it working.

How Current fits

Current runs alongside your PSA — you keep Autotask, ConnectWise, or Halo PSA as the source of truth for time and billing — and adds the layer they were never built for: a shared project workspace with database-level financial isolation.

• A partner portal that shows the client only the projects they're an explicit member of — name, status, timeline, tasks, progress, and shared documents — and nothing else in your workspace.
• Financial isolation enforced at the database, not the interface. Row-level security, partner-safe views, and restrictive policies mean a partner viewer cannot reach a dollar figure even if they go looking. It isn't a hidden button; the data never leaves the server.
• Co-managed comments, so the client's internal team can post on tasks and milestones and stay in the conversation without ever touching a PSA seat.
• Shared task ownership across both teams on the same Kanban board, timeline, and interactive dependency map — everyone sees what's blocking what, in real time.
• Unlimited free partner-portal viewers. Invite the whole internal IT team and their leadership at no extra cost; you pay for your own users, not theirs.

An honest boundary

Current is not a billing system and is not trying to replace your PSA. Time your engineers log against a synced project still flows to your PSA — Autotask, ConnectWise, or Halo PSA — for invoicing. Current just owns the schedule and the shared view. If a co-managed relationship is light enough that a monthly email genuinely suffices, you may not need this. But the moment two teams are executing dependent work against a real deadline, a shared plan the client can safely see is the difference between a partnership and a guessing game.

What makes co-managed different

A co-managed engagement has two teams with different employers, different priorities, and different tooling working one plan. That breaks assumptions most project tools make. The client's internal team needs to see and update real work, not a summary. But they must never see your cost basis, margins, or what you charge for the hours they are watching.

Most tools solve this by hiding financial fields in the interface, which is not a security boundary. Anyone who has ever opened a browser's developer tools knows the difference between hidden and absent.

The isolation that makes it safe

Current enforces the boundary at the database layer. Partner accounts read through views that exclude financial columns entirely, with row-level security and restrictive policies behind them, so the data is not merely hidden from the interface but genuinely unreachable by that account. That is what makes it defensible to give a client's internal IT team real access rather than a weekly export.

Practical patterns that work

• One shared plan with clear ownership per task, rather than two plans somebody reconciles.
• Explicit handoff points modelled as dependencies, so nobody waits on someone who does not know they are being waited on.
• Comments the client team can actually use, so decisions are recorded where the work is.
• Your internal tasks visible as sequencing without exposing what they cost.

The failure mode to avoid

The usual way co-managed engagements go wrong is duplicate systems: the client tracks their half in their tool, you track yours, and the two disagree within a fortnight. Once that happens, meetings become reconciliation sessions and the relationship starts to feel adversarial. One plan both sides can see is worth more than perfect tooling on either side.