Capability
Managed IT and Co-Managed IT
A managed agreement is an operating arrangement. It defines who is responsible for what, what gets monitored, how quickly things are answered, and what evidence exists that any of it is happening.
At a glance
- Service desk with defined response commitments
- Endpoint management, patching and monitoring
- Documentation maintained continuously
- Co-managed models for teams with internal IT
What is included
Service desk handling day-to-day requests and incidents, with severity-based response commitments rather than a single blanket promise. Endpoint management covering deployment, configuration baselines, patching, encryption and asset records. Monitoring across endpoints, servers, network devices and cloud services, with alerting routed to people rather than dashboards.
Underneath all of it sits documentation: asset inventory, network diagrams, credential records held in your control, vendor details and runbooks for recurring procedures. Documentation is the deliverable that determines whether an agreement produces a well-run environment or just a ticket queue.
- Service desk with severity-based response targets
- Endpoint deployment, baselines, patching and encryption
- Server, network and cloud monitoring with escalation
- Backup oversight and restore verification
- Identity and access administration
- Documentation maintained as work happens
- Quarterly review of posture, spend and roadmap
Co-managed arrangements
Where an internal IT person or team already exists, the useful arrangement is rarely replacement. It is coverage for the gaps: after-hours and holiday cover, escalation for specialist areas, project capacity, and the tooling and process discipline that is difficult to sustain with one or two people.
The critical part is written division of responsibility. Which party owns identity administration, who approves changes, who holds administrative credentials, who is called first for what. Ambiguity here is the reason co-managed relationships fail, and it is entirely avoidable.
- Written responsibility matrix agreed at the start
- Escalation path with named contacts
- Shared tooling and documentation access
- Project capacity without permanent headcount
Onboarding and the first 90 days
Onboarding is discovery, stabilisation and documentation. Discovery establishes what exists — every device, account, system, vendor and dependency. Stabilisation addresses the immediate risks found, which almost always includes backup verification and administrative access control. Documentation captures all of it in a form that survives staff turnover on either side.
By the end of onboarding you should have an accurate asset and vendor inventory, verified backups, controlled administrative access, and a rated findings list with a sequenced plan. That is the baseline everything after it is measured against.
Keep exploring
Related Oakville services
Most engagements combine several of these. Follow the thread that matches the problem you are trying to solve.
Questions
Frequently asked questions
- How is pricing structured?
- Typically per user or per device with defined inclusions, so cost is predictable and does not rise every time something breaks. Project work outside the agreement is quoted separately and agreed before it starts.
- What are your response times?
- Commitments are severity-based: a whole-office outage or a suspected security incident is treated differently from a single non-blocking request. The specific targets are written into the agreement rather than implied.
- What happens if we leave?
- You take documentation, credentials and administrative access with you, because you held them throughout. Offboarding is a handover exercise, not a negotiation.
See what a properly run environment looks like
Start with an assessment. You will get findings, a sequence and a realistic view of what ongoing management would involve.