Co-Managed IT
Define the recurring responsibilities an internal IT team keeps and the work Root supports.
Root Managed ServicesManaged IT · Cybersecurity · Cloud
Root manages the day-to-day technology behind a business: endpoints, identity, applications and vendor relationships. For owners and IT leaders, the objective is a defined operating model with visible responsibilities, planned maintenance and a dependable route for requests.
Untracked devices, overdue updates, and separate vendors make routine IT work unpredictable. When nobody owns the whole environment, an employee issue can become a chain of handoffs. Root brings endpoint management, identity, applications, and vendor coordination into one ongoing service relationship.
A managed service relationship should explain more than which agents are installed on devices. It should say who approves changes, which requests the service desk handles, how unresolved risk reaches management, and which systems remain with an internal team. Those decisions make the difference between buying technical coverage and establishing an operation that people can use.
Inventory, lifecycle planning and patch management establish which Windows, macOS and Linux devices are managed. Encryption and device policy make the expected configuration explicit; exceptions should have an owner and a review date.
SSO, MFA and conditional access connect users to the resources they need. Microsoft 365 administration should be coordinated with account changes, license decisions and the application owners who understand the business impact of access.
Vendor coordination provides a route for application and carrier issues that cross company boundaries. Quarterly reviews connect operational findings to replacement plans, procurement and decisions that require a business owner rather than a helpdesk ticket.
A company without internal IT may need Root to coordinate most daily operations. An internal IT team may instead want help with a defined set of devices, maintenance work or escalations. Discuss the division of responsibilities explicitly; a shared model only works when both sides can identify the owner of a request without debating the contract during an outage.
For example, internal staff might retain application approval while Root handles endpoint maintenance and the first support investigation. Document that division of work, administrative access and handoff criteria in the engagement scope. The helpdesk service explains how employee requests connect to that operating model.
Bring the device inventory, application list, current provider agreements and business priorities. Identify systems that cannot be interrupted and any upcoming moves, renewals or hiring changes. An incomplete inventory should be an assessment finding, not an assumption hidden in the quote.
Confirm authorized administrative access, vendor contacts, employee request channels and account-change approvers. Record what the outgoing provider must transfer and what the business already owns. Avoid assuming that possession of a password establishes a complete handover.
Prioritize the risks that could disrupt operations, then establish maintenance windows, reporting and system documentation. Root’s published process moves through assessment, design, deployment, monitoring and support; the specific sequence depends on the state of the environment.
A flat-rate agreement is useful when its boundaries are clear. Review covered users and devices, projects, onsite work, after-hours escalation and vendor charges. A large migration or office buildout may need a separate scope. The existing plans are a starting point for a conversation about coverage, not a substitute for an environment-specific agreement.
An accurate asset inventory is the starting point: what you own, who uses it, and when it needs attention. Patching and access policies then become repeatable work instead of occasional cleanups. Quarterly reviews connect that work to replacement decisions, budget planning, and risks that need leadership attention.
Ask what the reports will let you decide. A patch exception may call for an application upgrade; recurring storage alerts may justify a capacity project. Monitoring and NOC provides infrastructure context, while infrastructure consulting turns longer-term findings into a roadmap. Numbers are useful when the next owner and action are apparent.
Operational management should not leave adjacent responsibilities assumed. Confirm which cybersecurity controls are managed, who handles an incident, and whether backup and disaster recovery covers the applications that matter. A maintained endpoint, a protected identity and a recoverable business system address different failure modes. Review those boundaries together when choosing coverage.
| Request | Business decision | Administration check to agree |
|---|---|---|
| Request A new employee joins | Business decision The manager approves the role, start date and applications the employee needs. | Administration check to agree Confirm the account, appropriate licenses, device requirements and access tests within the agreed tenant scope. |
| Request An employee changes roles | Business decision Application and information owners approve access that changes with the job. | Administration check to agree Review both new permissions and access that should end; preserve a record of the approved change. |
| Request An employee leaves | Business decision The authorized owner decides the timing and how business information should be handed over under the organization’s policies. | Administration check to agree Coordinate sign-in blocking, session revocation and device handling with the authorized owner. Confirm retention requirements and approved mailbox/OneDrive handover before license removal or account deletion; application access may need separate action. |
| Request A tenant setting needs to change | Business decision A named owner approves the intended effect and the acceptable interruption. | Administration check to agree Identify affected workloads, required administrative privileges, validation checks and the route for reversing an unsuccessful change. |
A support request can involve an account, a subscription, a device and information owned by another team. Identify which of those responsibilities Root will administer and which stay with your organization or an application vendor. Keep business approval attached to the request so access is not granted merely because a technical change is possible.
Microsoft 365 administration does not automatically define mailbox migration, every application configuration or every dataset’s recovery arrangements. Review those requirements through cloud and virtualization planning and backup and disaster recovery. The co-managed IT guide provides a responsibility matrix for teams retaining internal administration.
Define the recurring responsibilities an internal IT team keeps and the work Root supports.
It can provide day-to-day management where no internal team exists. If you already have IT staff, discuss which responsibilities Root should own and which should stay with your team so requests and changes have a clear route.
The agreement defines scope. Review ongoing maintenance, onsite work, major upgrades, and project requirements before choosing a plan; a predictable budget depends on knowing which work needs separate approval.
Start by identifying their support responsibilities, renewal dates and access requirements. Root’s service scope includes vendor coordination. The useful question is how an issue moves between organizations and who keeps the business informed, rather than assuming every vendor must change.
Ask for the asset inventory, configuration records, administrative ownership, escalation contacts and operating runbooks relevant to your scope. Root’s approach emphasizes documentation the customer owns. Agree on where those records live and how updates are maintained.
Tell us which work is falling between people or providers. We can use that starting point to discuss coverage, onboarding priorities and the decisions that belong in your agreement.