On this page
When an internal IT team needs a shared operating model
An internal team may understand its applications well but spend too much of the week resolving repeated employee issues, coordinating vendors or maintaining routine systems. Co-managed IT services can assign selected recurring work to Root while the internal team retains the business context and decisions it owns.
Start with the work that needs a reliable owner. A recurring support queue, an agreed maintenance responsibility or a defined escalation path gives both teams something concrete to operate. A one-time installation needs a project scope; continuing shared IT support also needs rules for the next request, the next exception and changes to the environment.
The working agreement should identify supported systems, deliverables, access, work windows and decision authority. The example below helps structure that discussion; it is not a list of automatically included services.
Agree who owns the work and who approves changes
| Workstream | Internal owner and approver | Possible scoped Root work | Evidence the next owner needs |
|---|---|---|---|
Employee tickets | Internal service owner defines supported requests and approves access exceptions. | Handle agreed ticket categories; keep a named owner until a receiving team accepts a transfer. | User impact, affected system, checks already completed, next action and accepted owner. |
Endpoint changes | System owner approves the change scope and maintenance window. | Carry out authorized maintenance on agreed devices and record the result. | Device scope, approval, pre-change state, verification result and any rollback or follow-up. |
Identity changes | Business or application owner authorizes the specific access required. | Execute approved account actions within assigned permissions. | Request, approver, access granted or removed, completion check and unresolved dependencies. |
Vendor coordination | Internal owner retains commercial decisions and approves business-impacting actions. | Gather relevant diagnostics and coordinate an agreed technical workstream. | Vendor reference, issue summary, requested action, next update owner and decision needed. |
Exceptions | Named decision maker accepts risk or authorizes work outside the routine process. | Explain the impact, preserve the available evidence and escalate within the agreed boundary. | Exception, current containment or workaround, decision deadline if known, and accountable approver. |
Make exception handoffs usable during real incidents
Hypothetical example: an employee can open a business application but cannot export a report after a device change. The application owner is internal, endpoint support is shared and the application vendor controls the export component. Sending the ticket to all three teams leaves the employee without a clear next step.
The assigned ticket owner first records the affected report, error, device change and whether an approved comparison test reproduces the issue. If the next check requires application permissions, the internal application owner approves it. Root can coordinate the agreed endpoint checks and pass the relevant findings to the vendor without claiming authority over the application.
The handoff should name the receiving owner and the action being accepted. Keep responsibility for user updates explicit while the vendor investigates. If the proposed fix changes business permissions or production settings, route that decision to the authorized approver rather than treating administrative access as permission to proceed.
Bring the access and operating information that defines scope
Use the initial inquiry to describe the environment. Arrange an approved sharing method before providing credentials, private logs or detailed access records.
- A current inventory of systems and the internal owner for each business application.
- Recurring ticket categories, unresolved ownership disputes and examples of repeat work, summarized without personal or confidential records.
- Ownership of ticketing and device-management tools. Remote monitoring and management (RMM) and professional services automation (PSA) describe tool categories; the actual products and access must be reviewed.
- Who can approve named administrative accounts, least-privilege roles and removal of access when responsibilities change.
- Maintenance windows, change approvers, escalation contacts and any work that requires a separate authorization.
- Vendor contacts, documentation locations and who maintains each runbook after a change.
Review whether the shared model is working
Agree the operating rules
Choose recurring workstreams, accountable owners, coverage windows and response expectations. Define where requests enter, how teams accept handoffs and who can approve an exception.
Try a bounded workstream
Start with an agreed category or system group. Check that each team can find the current instructions, obtain approvals and record work in the chosen process.
Review evidence together
Examine backlog age, repeated issues, completed changes, rejected handoffs and unresolved ownership. Interpret those records alongside business impact rather than treating ticket counts alone as success.
Adjust the working agreement
Assign corrections to an owner and update the runbook. If systems or responsibilities expand, confirm authority and scope before the new work becomes an assumed obligation.
Connect the operating model to the work it supports
Choose the management model
Compare managed IT service options when deciding which responsibilities your business retains and which it asks Root to operate.
Define employee support
Employee helpdesk support addresses request intake and resolution. Co-management specifies how that work connects to the internal team.
Separate alerts from authority
Monitoring and escalation scope defines what is observed and who receives an alert. Permission to make a corrective change must also be clear.
Handle a provider change
If responsibilities are moving between providers, plan a staged provider handover with transfer and acceptance checks before settling into ongoing operations.
Co-managed IT questions
Does co-managed IT replace our internal IT team?
The model is built around an agreed division of ongoing work. Your team retains the knowledge, systems and decisions assigned to it, while Root supports the selected responsibilities. Define that split before work begins.
Can we keep our existing ticketing and management tools?
Existing tools, permissions, integrations and licensing need review. The working process must establish where the authoritative record lives and how both teams exchange updates; compatibility is not assumed.
Who approves changes and handles an escalation?
Name the change approver and escalation contact for each workstream. The person investigating a problem may differ from the person authorized to approve a production change. Administrative access does not settle that distinction.
Is after-hours coverage included?
Coverage windows and response expectations depend on the agreed scope. Confirm which requests are handled in each window and how exceptions are routed before relying on additional coverage.
How is this different from an MSP transition project?
Co-management governs repeated work between teams. A transition project governs the transfer of access, records and responsibility, with explicit acceptance of what has moved. A transition may precede co-management, but it does not replace the continuing operating agreement.
Define the responsibilities your team wants to share
Describe the responsibilities your team wants to retain, the recurring work that needs additional capacity and the systems involved. Root can use those boundaries to discuss a workable co-managed scope. Share a summary first; credentials and private operational records do not belong in the public inquiry.
The email action opens a draft in your email app for you to review and send.