Evaluating managed IT service providers in BC? These 10 questions reveal how a prospective MSP actually operates, what their SLAs mean in practice, and what to watch out for.
- 1 1. What does a typical month look like for a client similar to ours?
- 2 2. How many clients does each of your engineers support?
- 3 3. What are your SLA terms by priority level, and can you share an example?
- 4 4. What is included in the monthly fee, and what specifically triggers a separate invoice?
- 5 5. How do you handle patch management for third-party applications, not just the operating system?
Selecting a managed IT service provider is one of the more consequential vendor decisions a BC business makes. The relationship affects daily operations, security posture, and your team’s ability to work without friction. A sales conversation will not tell you much. The right questions will.
This guide covers 10 questions that reveal how a prospective MSP actually operates, not just how their proposal describes them.
1. What does a typical month look like for a client similar to ours?
This question shifts the conversation from marketing language to operational reality. A confident MSP should be able to describe a typical month: how many helpdesk tickets are common for a business your size, what monitoring activity looks like, what proactive work is scheduled (patch cycles, backup testing, security reviews), and how that activity is reported back to you.
Vague answers about “proactive support” and “dedicated care” without operational specifics suggest the MSP does not have structured delivery processes. The more concrete and operational the answer, the better.
2. How many clients does each of your engineers support?
This question reveals whether the MSP has the staff capacity to deliver on its promises. An engineer supporting 50 clients simultaneously has far less time per client than one supporting 25. Support quality is directly affected by the ratio of engineers to clients.
There is no universal right answer here, but follow up by asking what the process is when your assigned engineer is handling multiple critical issues at the same time. The answer tells you whether there is genuine bench capacity or whether you will be in a queue.
3. What are your SLA terms by priority level, and can you share an example?
Response time targets should be specific, tied to defined priority levels, and committed to in writing. The relevant question is not just “how fast do you respond” but what “respond” means. First acknowledgement of a ticket is different from an engineer actively working the problem.
A well-structured SLA distinguishes between P1 (systems down, business impact), P2 (significant degradation, partial outage), P3 (minor issues, workarounds available), and P4 (general requests, non-urgent). Each level has a defined first-response time and resolution target. If a prospective MSP cannot show you a sample SLA document with this level of specificity, the contractual protection is not real.
4. What is included in the monthly fee, and what specifically triggers a separate invoice?
After-hours response, on-site visits, hardware procurement, project work (migrations, new system deployments), and cybersecurity incident response are all common exclusions from base managed IT agreements. Some MSPs also cap the number of support hours per month or charge separately for support beyond a defined threshold.
You are not looking for an all-inclusive answer. You are looking for clarity. An MSP that cannot clearly define the boundary between included and extra-cost work will produce billing surprises at the worst moments.
5. How do you handle patch management for third-party applications, not just the operating system?
Operating system patches are table stakes. Keeping Chrome, Firefox, Adobe Reader, Java, and line-of-business applications current is where many MSPs fall short. Ask specifically what the patch management process covers, how frequently third-party patches are applied, and how the MSP handles situations where a patch breaks something in a production environment.
The answer reveals the depth of the patch management programme. An MSP that patches the OS monthly but has no documented process for third-party applications leaves a significant part of the attack surface unmanaged.
6. Where is our data processed and stored?
This matters for BC businesses under PIPA, PIPEDA, and in some sectors PHIPA. Monitoring tools, ticketing systems, backup infrastructure, and remote access tools all process data about your environment and potentially your business data.
Some MSPs use US-hosted monitoring and ticketing platforms. This may create compliance considerations depending on the nature of your data. A provider with genuine Canadian compliance expertise will know which of their tools are hosted on Canadian infrastructure and will be able to speak to this clearly.
7. What is your security stack and what does it cover?
Ask specifically what security tools are deployed as part of the managed IT engagement. The answer should include endpoint detection and response (not just antivirus), email security filtering, multi-factor authentication enforcement, and some form of security event monitoring.
Follow up by asking who reviews security alerts and how quickly. A monitoring tool that generates alerts that no one reviews is not security coverage. Understand whether the MSP has a dedicated security operations function or whether security monitoring is handled by the same engineers doing helpdesk support.
8. How do you handle onboarding, and what does the first 90 days look like?
Onboarding quality is a reliable predictor of ongoing service quality. An MSP that cannot describe a structured onboarding process is likely to start billing before they understand your environment.
A proper onboarding involves documenting your infrastructure (every device, every user account, every application in scope), deploying monitoring tools, establishing backup configurations and testing them, and introducing the engineers who will support your account. This typically takes four to eight weeks. Expect to be asked for cooperation during this period. That is a good sign, not an inconvenience.
9. Can you provide references from businesses similar to ours in size and industry?
References reveal what the day-to-day relationship is like after the sales process ends. Ask for references from businesses with similar headcount, similar technology complexity, or similar industry requirements. A manufacturing business asking for references from professional services firms may get answers that do not translate to their environment.
An MSP confident in their results will make reference introductions readily. Deflection, testimonials instead of direct contacts, or references from very different businesses are worth noting.
10. What happens when the engagement ends and how do we get our documentation back?
Before signing any managed IT agreement, understand what happens when the relationship ends, regardless of the reason. You should receive all documentation, credentials, network diagrams, and configuration records. Monitoring tools should be removable without disrupting your environment.
An MSP reluctant to discuss offboarding terms, or whose agreement makes it difficult to leave, is worth approaching with caution. A provider confident in their service does not need contractual mechanisms that make switching painful. This question also reveals whether the MSP builds client-owned documentation as part of normal delivery or retains it as leverage.
Putting the Answers Together
No single answer makes or breaks an MSP evaluation. What you are looking for is consistency between what the provider claims and the operational specifics they can demonstrate. Vague answers to operational questions, reluctance to provide contractual detail, and defensive responses to the offboarding question are patterns worth weighing seriously.
The best managed IT relationships are ones where the provider’s success depends on your technology working reliably, not on you continuing to pay to fix problems. That incentive alignment starts with how the agreement is structured.
SFS Technologies provides managed IT services to BC businesses with fixed monthly pricing, documented SLAs, and named engineers. Let us walk through these questions together and show you specifically how we answer them.
