Choosing a managed service provider is a decision about how technology work will be owned, delivered and reviewed. Price and service commitments matter, but they are only part of the comparison. Before selecting an MSP, make sure you understand what is included, who will do the work, how issues are escalated, what the provider needs from your team and how the arrangement can change over time.
Start with your requirements
Write down the outcomes you need from a provider and the constraints it must work within. Include your users, locations, critical systems, internal team responsibilities, security requirements, compliance obligations and current projects. Identify what is working well and should be preserved. A provider cannot give a useful proposal if the request is simply “manage our IT” with no definition of scope.
Decide whether you want a fully managed service, co-managed support alongside an internal team, or help with a defined project. These models can involve different responsibilities. If your internal team is staying in place, ask how the provider will complement it rather than duplicate or override its work.
Compare scope, not just the headline price
Ask each provider to describe the services included in the proposed fee and the assumptions behind it. Clarify which systems, users, sites and hours are covered. Check how the proposal treats onboarding, projects, major changes, new locations, specialist work, after-hours requests and third-party services.
Ask for examples of work that would be out of scope and how it would be priced or approved. Look for licence costs, hardware, travel, incident response, cloud consumption and other third-party charges. The right comparison is between complete scopes, not merely between the first figures on two proposals.
Understand accountability
Ask who owns the service relationship and who is responsible for each operational task. Who receives a request? Who triages it? Who can make a change? When does the internal team need to approve? Who coordinates a multi-vendor issue? What happens when a request does not fit the standard process?
If the provider uses tiers, understand what each tier can do and how the case moves between them. Ask how technical context is preserved during a hand-off. A process should provide visibility and ownership, not just a reference number.
Test the escalation model
Do not rely on a diagram alone. Ask the provider to talk through a realistic scenario relevant to your environment. Which person or team would be engaged? What information would they need? How would your internal staff participate? Who would communicate with affected users? How would the provider return the service to normal operation and record follow-up actions?
The provider should distinguish between its contractual commitments and its general service approach. Read the service levels carefully. Confirm how terms are measured, what is excluded and what your organisation must do to enable the commitment. A response target, for example, should not be assumed to mean a resolution guarantee unless the agreement says so.
Check security and access practices
A provider may need access to sensitive systems to deliver its work. Ask how access is requested, approved, limited, reviewed and removed. Understand how administrative privileges are controlled, how provider personnel are identified, what records are maintained and how security events are communicated. Request the relevant policies or evidence appropriate to the engagement, without assuming a certification or control from a sales presentation.
The provider and customer should agree which party owns each security task. This includes areas such as endpoint management, patching, identity, backup, monitoring and incident coordination. Avoid broad promises like “we take care of security” unless the actual activities, boundaries and responsibilities are specified.
Evaluate onboarding and knowledge transfer
The service begins before steady-state support. Ask how the provider will learn the environment, validate asset and contact information, identify dependencies, document access and confirm operational readiness. Ask what input is required from your team and how issues discovered during onboarding will be handled.
A good transition plan should describe responsibilities, checkpoints and the information needed to begin. It should also explain how your organisation can retrieve documentation and transfer knowledge if the provider changes.
Ask who will support you
Find out whether the people presenting the service will be involved in delivery, who your main contacts will be and how specialist expertise is brought in. Ask how the provider handles staff changes and continuity. Seek references or examples that are relevant to your type of environment, and confirm that you have permission to contact the referees.
A provider should be willing to discuss limits as well as strengths. Pay attention to whether it asks about your operating context, explains trade-offs and is clear when a capability is outside scope.
Make the decision reviewable
Record why you chose a provider, what each party owns, which risks remain and how you will review the service. Agree review frequency, reporting, improvement actions and the route for raising concerns. The relationship should not depend on a single verbal assurance or one person’s memory.
Use what co-managed IT means to assess whether shared support suits your internal team, and vendor or partner: the difference for a practical view of the working relationship. To discuss managed IT options with AltTab, visit managed services.