Begin with the work, not the label
A support model is useful only when everyone understands who does what. List the work your organization relies on: user requests, account changes, device maintenance, backup checks, infrastructure changes, security reviews, and planning. For each activity, name the current owner and the person who can authorize a change. Gaps and overloaded responsibilities often become visible before you compare any proposals.
When managed IT may fit
An organization with limited internal IT capacity may want a provider to coordinate a broad set of day-to-day responsibilities. The agreement still needs boundaries: supported systems, user eligibility, service hours, escalation routes, and work that requires a separate project. A provider managing technology does not remove the business owner’s responsibility to approve access, set priorities, and make budget decisions.
When co-managed IT may fit
An internal IT leader may need extra operational capacity, specialist skills, or help delivering a change. Co-management works best when the provider complements a defined internal role. For example, the internal team might own architecture and application decisions while a partner handles an agreed endpoint maintenance scope. Avoid having two teams assume the other is watching the same task.
Write the handoffs down
Use a simple responsibility table with an owner, approver, escalation contact, and record of completion for each service. Discuss tool access, documentation ownership, administrator privileges, and the exit process. If both teams can change the same system, agree on a change calendar and how exceptions are recorded. These are operating decisions, not just contract wording.
Compare proposals using a real month
Take a recent month of requests and changes. Ask each provider to explain which activities are included, which require approval, and which are separately scoped. Include a new employee, a departing employee, a failed backup, and a business application upgrade. The answers are more useful than a long feature list because they reveal the handoffs your people will actually experience.