Choose in-house IT when your business needs substantial daily involvement and can provide the skills and cover the role requires. Consider managed services when a defined set of operational work can be assigned to a provider with measurable responsibilities. A co-managed arrangement can suit a business that wants to keep an internal owner while buying specific expertise or additional coverage.
For a Riyadh SME, the decision should reflect actual working hours, site access, application dependencies and who can authorize changes. Headcount alone is a weak basis for choosing. A small business with several sites and evening operations may have more complex support requirements than a larger office using a consistent application set.
Count the work before choosing the model
Review recent support requests and planned changes. Group them into user support, device setup, network operations, application administration, security tasks, recovery, procurement and project work. Record frequency, approximate effort, specialist knowledge and whether physical attendance was necessary.
Include work that has been postponed or performed informally. If one employee resets passwords, receives equipment and calls the internet provider alongside another job, those responsibilities still need an owner in the new arrangement. An empty ticket system does not prove that the workload is small.
Then identify which activities require business knowledge. Approving access to finance records, deciding when a store can stop trading and prioritizing a payroll incident remain business decisions even when a supplier performs the technical work.
Compare in-house, managed and co-managed IT
This table is a decision aid, not a staffing threshold or an assumption about any provider's capabilities.
| Workload or constraint | Model to examine first | Condition to verify |
|---|---|---|
| Daily support closely tied to internal processes | In-house | Skills, documentation and absence cover are available |
| Defined recurring monitoring and maintenance | Managed | Assets, tasks, exclusions and reports are specified |
| An internal administrator needs specialist help | Co-managed | Escalation and change ownership are unambiguous |
| Several sites require physical assistance | Any model with an explicit site plan | Attendance arrangements and site access are realistic |
| Opening hours extend beyond normal office support | Managed or co-managed coverage extension | Actual staffing and response commitments match those hours |
| Major migration alongside routine operations | Separate project scope plus an operating model | Project work will not displace essential support |
Each model also has a tradeoff to plan for. An internal role needs absence cover and a route to skills beyond that person's experience. A managed service needs a clear business contact and documented processes so the provider can act without guessing. Co-managed IT needs explicit handoffs so neither team assumes the other completed the work. Compare how each proposal handles those weaknesses, not just its list of capabilities.
Worked example: keep the internal owner or replace the role?
Imagine a Riyadh business with an internal administrator who understands its accounting application and helps staff every day. The gaps are network troubleshooting, absence cover and maintenance outside office hours. This is an illustrative decision, not a customer case study.
Start by comparing a co-managed scope for those gaps with the resources needed to cover them internally. Keep application approvals and daily priorities with the internal owner; ask the provider to name its network escalation, maintenance tasks and absence-cover procedure. A full outsourcing proposal needs to explain who will take over the administrator's business knowledge and user relationships.
If the same business has little recurring internal work and no administrator, a managed scope with an accountable business contact may be more suitable. The deciding evidence is the workload and coverage gap. Neither employee count nor the label “unlimited support” settles the choice.
Make local support specific
Give prospective providers the addresses of the Riyadh sites they would support and the hours when users need assistance. Explain building access procedures, any reception or facilities coordination, and when disruptive work can occur.
Ask which incidents can be resolved remotely and what triggers a site visit. Specify whether travel, physical replacement, spare equipment and third-party coordination are included. A provider's proximity is useful context, but the agreement must define the service you can call on.
Check language requirements for the people reporting faults and receiving instructions. If your application vendor or global team operates in another time zone, define how the local support team escalates incidents during the overlap and outside it.
What should an SLA actually measure?
A service-level agreement (SLA) records the service commitments and how they are measured. Define the response target separately from restoration and resolution targets, including whether response means acknowledgment or engagement by a qualified engineer. For a vendor-specific example, AWS explicitly distinguishes first-response times from resolution times for third-party software support. Your agreement must define its own measurements, severity criteria, support hours and start/stop rules. AWS third-party support scope.
Walk through a realistic scenario before signing: users can reach the internet but cannot open the accounting application. Who gathers the initial evidence? Who contacts the application vendor? Who communicates with staff? Who can authorize a temporary workaround? The answer should remain clear even when the fault is outside the managed provider's direct control.
Ask a provider to complete this sentence: “For a [defined severity] incident reported through [channel] during [covered hours], [role] will engage within [agreed target]; [role] coordinates restoration and sends updates at [agreed interval].” Then specify exclusions and any separate on-site commitment.
Do the same for monitoring: name who receives an alert, investigates it and records the outcome. A dashboard without an assigned response is an unfinished support arrangement.
Keep business control of access and records
Record the business owner of domains, tenants, subscriptions and equipment. Agree how privileged access is granted, reviewed and removed. The business needs an authorized recovery path and access to the documentation required to transfer operations later.
The May 2022 joint advisory from CISA and international partners, available on the Australian Signals Directorate's official website, recommends that MSP customers make security responsibilities explicit in their contracts and restrict provider access to the systems being managed. Use it to inform the security scope of the agreement; it does not certify a particular provider or prescribe your complete operating model. Joint advisory on MSP and customer security.
For a co-managed arrangement, name the owner of each control. Avoid an arrangement in which both teams assume the other checks failed backups or removes departing users. The backup and disaster-recovery guide can help define the recovery outcomes those owners must demonstrate.
Compare proposals using the same scope
Give every candidate the same asset list, operating schedule and workload summary. Ask for included tasks, exclusions, onboarding work, reporting, escalation, project boundaries and exit deliverables. List software subscriptions and tools separately so overlapping coverage is visible.
For an internal model, include recruitment, training, cover, external specialist support and management effort in the comparison. For a provider model, include the internal time needed to approve changes, coordinate staff and oversee the agreement. Keep the comparison about total responsibilities and resources rather than assuming outsourcing always reduces effort.
If Azure operations form part of the scope, use the Azure managed-services partner guide for the cloud-specific questions. The wider SME operating model also needs to cover users, local networks and on-site equipment.
Start with an assessment and a handover
The first deliverable should be an agreed inventory and responsibility register. Confirm working administrative access, monitoring ownership, recovery procedures and open issues before the new model takes over. Keep the outgoing arrangement active until continuity is established through an agreed transition.
After an initial operating period, review the evidence: which incidents repeated, which work fell between teams and whether users received help during the required hours. Adjust the scope around observed gaps.
BustanTech's managed services and infrastructure assessment provide starting points for a scoped discussion. Request an IT operating-model review with your site list, application inventory and recent support workload.