Co-managed IT is a shared service model in which an external provider works alongside an organisation’s internal IT team. The provider adds agreed capacity, specialist skills or operational coverage while the organisation retains the responsibilities and decisions it wants to keep. It is not simply a smaller version of fully outsourced IT. The useful question is not “Who manages the technology?” but “Who owns each part of the work, and how do the two teams coordinate?”
Co-managed IT is a way of dividing work
An internal IT team may already know the organisation’s people, systems, priorities and constraints. It may lead technology decisions and maintain important relationships with the business. That does not mean it has every skill or enough time for every operational task, project or out-of-hours need.
A co-managed arrangement recognises both sides. The organisation keeps its chosen internal ownership. The service provider takes on agreed work that complements it. That could mean providing specialist engineering for a defined project, helping operate selected platforms, supporting service desk activity, or making additional expertise available when an issue crosses into another technology domain.
The exact division varies. “Co-managed” is a description of the relationship, not a standard package with a universal list of inclusions. The statement of work, service description and operating procedures should say what each party does.
What the organisation keeps
The customer should retain the responsibilities and decision rights it wants to own. These often include setting business priorities, approving material changes, choosing risk tolerances, controlling budgets and deciding which systems or services are in scope. The internal team may also retain architecture, vendor relationships, user communication or first-line support.
Those are examples to discuss, not assumptions. A small internal team may want to retain service ownership while delegating routine platform administration. Another may want a provider available for escalation but keep all daily operations in-house. A third may ask for delivery help on a particular project without ongoing support.
What a provider may add
A provider can add depth where the internal team has a defined gap. That may be specialist knowledge in networking, security or cloud, extra hands during a planned change, or a documented escalation path when an issue needs a different skill set. It can also provide continuity for tasks that otherwise depend on one person, if the scope and handover process support that goal.
The provider should be clear about the people, services, hours and platforms covered. “Access to expertise” is not precise enough by itself. Ask how an issue is raised, who triages it, when a specialist becomes involved, what information is shared and who coordinates updates to your users.
How shared support works in practice
A co-managed service needs an agreed way to work together. The provider should understand the existing environment, the internal team’s roles and the boundaries of its authority. The customer should know which requests go to the provider, which remain internal and how the teams handle work that sits between them.
Documentation matters. Record ownership, contact paths, escalation criteria, change approvals and the systems in scope. Agree how both teams will access the information needed to resolve issues, and how that access will be reviewed. If either team uses a service desk or ticketing system, decide how records, priorities and updates are shared. The goal is not to remove every ticket. It is to ensure the process supports the work rather than becoming a substitute for clear ownership.
When the model may suit
Co-managed IT may suit an organisation that wants to retain an internal team but needs additional capacity, skills or support coverage. It can be useful when demand varies, when a project needs expertise the team does not use every day, or when an internal team wants a defined escalation option.
It may not be the right fit if no one can own the relationship internally, if responsibilities cannot be agreed, or if the provider’s proposed service requires control the organisation is unwilling to delegate. A fully managed arrangement may be more appropriate where the organisation wants to outsource a broader set of operational responsibilities.
Questions to settle before starting
Before selecting a provider, write down the work you want to retain and the work you want help with. Then confirm the service scope, named responsibilities, escalation route, change authority, access controls, reporting, onboarding requirements and commercial terms. Ask what happens when an issue crosses a boundary or a task is outside scope.
The answers should be specific enough that both teams can act without guessing. If the model depends on an informal promise to “work flexibly”, ask how that flexibility will be supported day to day.
A practical next step
Co-managed IT works best when it strengthens the internal team without blurring accountability. Start with the operating gaps, decide what you want to keep, and agree how the provider will plug into the way your organisation works. Read more about AltTab’s managed services, or explore why rigid MSP models can frustrate capable teams and how a hybrid service model can reduce hand-offs.