I'm an IT Director and need to find a managed service provider (MSP) to outsource our help desk. How do I choose a good one?

Named in 31% of answers

To help narrow this down, could you tell me:

• Your approximate user count and monthly ticket volume?
• Whether you need 24 × 7 support or standard business hours?

I can help you draft a tailored RFP or build a scorecard matrix for your vendor evaluations.

A structured RFP is useful because it forces vendors to answer the same questions and makes proposals comparable.Single Point of Contact+1

1. Define exactly what you're outsourcing

Before talking to MSPs, document your current environment and decide what stays with you.

For example:

Be particularly explicit about what is not included. “Unlimited support” is meaningless unless you know what's considered a support ticket versus a project, engineering work, or billable professional service.

A good RFP should define scope, coverage hours, escalation, SLAs, pricing, and support channels.Single Point of Contact

2. Evaluate the service desk itself

This is probably your most important category.

I'd ask:

• Where are the technicians located?
• How many technicians are actually assigned to your account?
• What percentage of tickets are handled by L1 vs. L2/L3?
• What's their average first-response time?
• What's their average resolution time?
• What percentage of tickets are resolved at first contact?
• How do they handle VIPs?
• How do they handle major incidents?
• Is there 24×7 support, or merely an answering service after hours?
• What happens when your assigned technician is unavailable?
• How are tickets escalated?
• Can you see the entire ticket history and technician notes?
• Can users contact the desk by phone, email, portal, Teams/Slack, etc.?

Don't accept averages alone. Ask for actual SLA performance from the last 6–12 months, ideally from a comparable customer.

One particularly useful question:

“Walk me through what happens when one of our users calls at 9:03 AM with a problem that your L1 technician can't resolve.” Have them demonstrate the process rather than describe it.

3. Put the SLA in operational terms

Don't let an MSP give you a single vague promise such as “15-minute response.”

Define priorities and consequences.

For example:

Those numbers are examples—you should set them from your organization's actual requirements.

Also define:

• When does the SLA clock start?
• Does an automated acknowledgment count?
• What pauses the clock?
• What constitutes resolution?
• What happens if they miss the SLA?
• Are service credits available?
• Who can declare a major incident?
• What is the escalation procedure?

A useful SLA is measurable enough that you and the MSP can't reasonably disagree about whether it was met.

4. Security should be a separate evaluation

Your MSP will potentially have privileged access to your environment, so you're effectively outsourcing part of your security boundary.

Ask for:

• SOC 2 Type II report
• Penetration-test summary
• Cyber insurance
• MFA requirements for MSP technicians
• Privileged-access management
• Just-in-time/JIT access, if applicable
• Technician background checks
• Endpoint security on technician workstations
• Logging of administrative activity
• Separation of customer environments
• Incident-response procedures
• Breach notification requirements
• Data retention/deletion policies
• Backup and disaster-recovery procedures
• Subcontractor/third-party access

SOC 2 is particularly relevant because it examines controls concerning areas such as security, availability, processing integrity, confidentiality, and privacy.AICPA & CIMA+1

But don't treat “we have SOC 2” as a security score. Ask to see the report, its scope, the systems covered, the auditor's opinion, and any relevant exceptions.

5. Find out who will actually do the work

This is where MSP sales presentations can be misleading.

Ask:

“Who specifically will be supporting us after the contract is signed?” Then ask:

• How many named technicians?
• How many customers does each technician support?
• What is the technician-to-user ratio?
• What is employee turnover?
• How long have the assigned technicians been there?
• How much work is outsourced offshore?
• Which tiers are offshore?
• Where is the after-hours team located?
• What happens if the account manager leaves?
• Who is your escalation engineer?
• Who owns the relationship?

I'd actually request a meet-the-team session with the people who would support you, not just the salesperson and VP.

6. Make them demonstrate your environment

Give each finalist a scenario-based test.

For example:

“It's Monday at 8:15 AM. A new employee starts at 9:00. Their laptop won't authenticate to Microsoft 365, they're missing two applications, and their manager says they need access to three systems.” Ask the MSP to demonstrate how they would handle it.

Then give them harder scenarios:

• A CEO can't access email.
• 30 users lose access to a critical application.
• A user's account is compromised.
• A laptop is infected with malware.
• A terminated employee still has active credentials.
• Microsoft 365 has an outage.
• A branch office loses connectivity.
• A recurring problem generates 50 tickets.

You're testing judgment and process, not trivia.

7. Demand meaningful reporting

You shouldn't have to ask your MSP what's happening.

At minimum, I'd want monthly reporting covering:

• Ticket volume
• Tickets by category
• Tickets by priority
• First-response SLA
• Resolution SLA
• Reopened tickets
• Aging tickets
• First-contact resolution
• User satisfaction/CSAT
• Recurring incidents
• Major incidents
• Problem-management activity
• Security incidents
• Patch compliance
• Backup status, where applicable
• Recommendations

And I would expect an IT service review meeting with someone senior enough to discuss trends and corrective actions.

8. Be extremely careful with pricing

MSP pricing can look inexpensive until you discover what's excluded.

Get vendors to price the same hypothetical environment.

Ask them to separately identify:

• Per-user/per-device recurring fee
• After-hours support
• Onsite support
• Projects
• Engineering
• Migrations
• New-user onboarding
• Offboarding
• Hardware procurement
• Licensing
• Third-party software
• Security services
• Backup
• vCIO/strategic services
• Emergency work
• Travel

Then ask:

“If we paid exactly the monthly recurring fee and nothing else, what would you refuse to do?” That's often more revealing than asking what is included.

9. Check references differently than most companies do

Don't just ask for three references and call them.

Ask for customers similar to you in:

• Number of users
• Technology stack
• Industry
• Geographic footprint
• Support requirements

And ask the references:

1. What did the MSP promise during the sales process?
2. What turned out differently?
3. How good is the help desk really?
4. How often do you have to escalate?
5. Do tickets get bounced around?
6. How often do you see unfamiliar technicians?
7. How transparent is billing?
8. What happens when something goes wrong?
9. What does the MSP do particularly well?
10. If you were selecting an MSP again, what would you investigate more carefully?

That last question tends to produce the useful information.

10. Don't overlook the contract and exit

This is one of the most important areas for an IT Director.

Make sure the contract addresses:

• Initial term
• Renewal
• Termination for convenience
• Termination for cause
• SLA failures
• Price increases
• Minimum commitments
• Data ownership
• Documentation ownership
• Password/credential ownership
• Configuration ownership
• Ticket-history export
• Asset/inventory data
• Transition assistance
• Knowledge-transfer obligations
• Assistance to your next MSP
• Data deletion after termination
• Notice period

Your MSP should make it easy to leave.

That sounds counterintuitive, but it's an excellent indicator of whether you're buying a service relationship rather than becoming dependent on a vendor.

A practical scorecard

I'd use something like this for the final 3–5 vendors:

Have each evaluator score vendors before the finalist presentations, then compare scores and discuss the large discrepancies. A published 2026 MSP scorecard similarly emphasizes defining scope and P1 criteria rather than relying on generic “unlimited IT” claims.Alcala Consulting

I would also impose some non-negotiable gates rather than letting a cheap price compensate for a serious weakness:

• No acceptable security controls → eliminate
• Cannot provide meaningful SLA reporting → eliminate
• Can't clearly identify service-delivery personnel → eliminate
• Poor reference feedback → eliminate
• Contract makes exit/documentation transfer difficult → eliminate

The biggest red flags

I'd be particularly cautious if you hear:

• “We don't really have SLAs because we're all about relationships.”
• “Your dedicated technician will handle everything.”
• “Our offshore team is just as good, but much cheaper.”
• “Projects aren't really part of our scope, we'll figure it out later.”
• “We don't normally show customers our SOC 2 report.”
• “You'll have a dedicated account manager” but nobody can explain technician assignment.
• “Our average resolution time is excellent” without showing the underlying data.
• “We'll customize the contract after you select us.”
• “You won't need to worry about documentation.”
• A remarkably low price that becomes substantially higher once exclusions are exposed.

If I were running the procurement

I'd probably run it as:

Internal requirements → RFP → 5 vendors → written proposals → 3 finalists → technical/service-desk demo → reference checks → security review → commercial negotiation → transition plan → 90-day acceptance period.

And I'd make the MSP prove its operational model before signing, rather than selecting based on a polished sales presentation.

The most important mental model is: you're not buying “IT expertise.” You're buying a repeatable service-delivery machine. Evaluate the machine.

If you tell me your approximate user count, locations, hours of support needed, Microsoft 365/Azure vs. other stack, and what you want to retain internally, I can turn this into a vendor-ready MSP RFP and a weighted 100-point scorecard you can actually send to bidders.

That last question tends to produce the useful information.

10. Don't overlook the contract and exit

This is one of the most important areas for an IT Director.

Make sure the contract addresses:

• Initial term
• Renewal
• Termination for convenience
• Termination for cause
• SLA failures
• Price increases
• Minimum commitments
• Data ownership
• Documentation ownership
• Password/credential ownership
• Configuration ownership
• Ticket-history export
• Asset/inventory data
• Transition assistance
• Knowledge-transfer obligations
• Assistance to your next MSP
• Data deletion after termination
• Notice period

Your MSP should make it easy to leave.

That sounds counterintuitive, but it's an excellent indicator of whether you're buying a service relationship rather than becoming dependent on a vendor.

A practical scorecard

I'd use something like this for the final 3–5 vendors:

Have each evaluator score vendors before the finalist presentations, then compare scores and discuss the large discrepancies. A published 2026 MSP scorecard similarly emphasizes defining scope and P1 criteria rather than relying on generic “unlimited IT” claims.

A useful RFP scorecard should emphasize support quality, SLA/metrics, security, technical capability, transition approach, cultural fit, and total cost rather than headline price. ITIL-oriented practices and continual improvement are useful evaluation signals.itsm.tools+1

I'd create a simple RACI matrix for these before issuing an RFP.

A particularly important question is:

"What percentage of our tickets will you actually resolve without involving my team?" Ask them to provide historical numbers from comparable customers rather than simply promising "high first-call resolution."

2. Establish the metrics you will hold them to

Don't accept an SLA that merely says "99.9% availability."

For a help desk, I'd want metrics such as:

The exact numbers should come from your business requirements rather than blindly adopting these examples.

Also distinguish response time from resolution time. Vendors sometimes advertise excellent response SLAs while taking considerably longer to actually resolve incidents.

3. Look very closely at the staffing model

This is one of the biggest differences between MSPs that look similar on paper.

Ask:

• Where are the service desk technicians located?
• Are they employees or subcontractors?
• How many technicians support customers of our size?
• What is the technician-to-user ratio?
• What happens during peak periods?
• What's the average technician tenure?
• What's annual service-desk turnover?
• Is there a dedicated team or a shared queue?
• Can we interview the people who would actually support us?
• How are escalations handled?
• Is there an L2/L3 engineering team?
• Do technicians have security training and background checks?

I'd be particularly interested in who will actually answer the phone at 2:00 PM on a Tuesday, rather than the account executive's description of the company.

4. Demand a real demonstration

Don't sit through a generic PowerPoint.

Give each finalist 5–10 realistic tickets from your environment and have them demonstrate how they would handle them.

For example:

1. User can't authenticate to Microsoft 365 after changing phones.
2. Executive's laptop has intermittent Wi-Fi.
3. Employee reports a suspicious MFA prompt.
4. New employee starts Monday and needs laptop/apps/access.
5. Printer works for everyone except one department.
6. User accidentally deleted an important OneDrive file.
7. VPN stops working while traveling.
8. Employee leaves the company unexpectedly.

Watch for whether they:

• ask good diagnostic questions;
• distinguish incidents from requests;
• verify identity before making account changes;
• recognize security incidents;
• document tickets properly;
• escalate appropriately;
• communicate clearly to the end user;
• know when not to make a change.

That exercise can tell you more than a 50-slide sales presentation.

5. Evaluate their technology stack—but don't let the tools fool you

Ask what they use for:

• ITSM/ticketing
• Remote monitoring and management (RMM)
• Endpoint management
• Microsoft 365 administration
• Identity management
• Documentation/knowledge base
• Asset management
• Endpoint detection/response
• Backup
• Network monitoring
• Reporting/analytics

Then ask the more important question:

"Show me what my team will actually see." You should have appropriate visibility into tickets, SLA performance, escalations, assets, changes, incidents and relevant security activity.

CISA specifically recommends contractual provisions around monitoring/logging, provider access to customer systems, incident notification, and appropriate security controls.CISA+1

6. Treat security as part of the MSP evaluation

You're giving another organization privileged access to your environment. That's a substantially different risk from hiring an ordinary business-services vendor.

At minimum, investigate:

• SOC 2 Type II report, if applicable
• ISO 27001 certification, if applicable
• MFA for MSP administrative access
• Privileged-access management
• Least-privilege architecture
• Separate customer environments/data
• Logging and audit trails
• Background screening
• Security awareness training
• Vulnerability management
• Incident-response process
• Breach notification obligations
• Business continuity/disaster recovery
• Backup architecture
• Subcontractors
• Cyber insurance
• Penetration testing
• Offboarding procedures

Don't just ask "Are you SOC 2 compliant?"

Ask for the report, identify exceptions, and determine whether the controls actually cover the services you're buying.

CISA recommends, among other things, MFA, least-privilege access, monitoring/logging, incident notification, and contractual security requirements when working with MSPs.CISA

7. Reference checks are incredibly valuable

Ask for three customers similar to you, preferably:

• similar employee count;
• similar technology stack;
• similar regulatory/security requirements;
• customers who have been with them for several years.

Don't let the MSP select only their happiest reference if you can avoid it.

I'd ask those references:

"What did the MSP promise during the sales process that turned out not to be true?" "What happens when they screw something up?" "How often do you have to escalate things internally?" "How good is the service desk after the honeymoon period?" "What costs surprised you?" "How difficult would it be to leave them?" That last question is particularly revealing.

8. Pay close attention to the contract

This is where seemingly inexpensive MSPs can become expensive.

Look for:

• Per-user vs. per-device pricing
• Minimum user/device commitments
• After-hours charges
• Project fees
• Onboarding fees
• Hardware/software markups
• Microsoft licensing markups
• On-site support charges
• Travel expenses
• Out-of-scope definitions
• Security incident responsibilities
• SLA credits
• Price increases
• Contract renewal
• Termination rights
• Data ownership
• Data export
• Documentation ownership
• Administrative-account ownership
• Transition assistance when you leave

The exit clause matters almost as much as the SLA.

You want the ability to leave without discovering that the MSP owns your documentation, has all the admin credentials, and will charge you a six-figure "transition project" to hand your environment back.

CISA's current MSP guidance similarly emphasizes defining responsibilities, incident response, outage compensation, records/logging, and other requirements contractually before award.CISA

9. Don't automatically outsource everything

As IT Director, I'd seriously consider a hybrid model.

For example:

MSP

• L1 help desk
• Password/account requests
• Endpoint support
• Standard software
• Device provisioning
• Basic M365 support
• Routine onboarding/offboarding

Internal IT

• Architecture
• Security governance
• Vendor management
• Business applications
• IT strategy
• Complex escalations
• Major incidents
• High-impact changes
• Relationship with business leadership

That can give you the scale of an MSP without surrendering the knowledge and control you need internally.

10. Build a weighted scorecard

I'd use something like this:

Then have each finalist respond to the same requirements and scenarios.

Importantly, don't let price dominate the scoring. If Vendor A costs $70/user and Vendor B costs $85/user, the $15 difference may be insignificant if B resolves substantially more issues without your intervention.

A good RFP structure

If you're at the point of actually going to market, I'd structure the process like this:

Phase 1 — Internal discovery

• Current ticket volumes
• Users/devices
• Hours of support
• Ticket categories
• Resolution times
• Escalation rates
• Current staffing costs
• Technology environment

Phase 2 — Requirements

• Scope
• SLAs
• Security requirements
• Reporting
• Staffing
• Transition requirements
• Commercial model

Phase 3 — RFP

• Send identical requirements to 5–8 MSPs.

Phase 4 — Shortlist

• Select 3 finalists based on written responses.

Phase 5 — Technical/operational validation

• Ticket simulations
• Tool demonstrations
• Security review
• Reference calls

Phase 6 — Commercial negotiation

• Compare total cost over 3 years, not just monthly per-user price.

Phase 7 — Transition

• Knowledge transfer
• Documentation
• Tool deployment
• Pilot group
• Parallel operation
• Full cutover

One thing I'd do differently from many IT departments

Don't start by asking "Which MSP should we hire?"

Start with:

"What service do we want our employees to experience, what work do we want our internal IT team to stop doing, and what measurable outcomes will prove the MSP is delivering it?" Once you have those answers, selecting the MSP becomes considerably easier.

If you tell me roughly your number of users, locations, hours of desired support, Microsoft/Google environment, current help-desk staffing, and whether you want L1 only or L1–L2, I can turn this into a practical MSP RFP + weighted evaluation scorecard you could send to vendors.

One thing I'd do differently from many IT departments

Don't start by asking "Which MSP should we hire?"

Start with:

"What service do we want our employees to experience, what work do we want our internal IT team to stop doing, and what measurable outcomes will prove the MSP is delivering it?" Once you have those answers, selecting the MSP becomes considerably easier.

If you tell me roughly your number of users, locations, hours of desired support, Microsoft/Google environment, current help-desk staffing, and whether you want L1 only or L1–L2, I can turn this into a practical MSP RFP + weighted evaluation scorecard you could send to vendors.

That last item is particularly important.

I'd build a simple RACI matrix for every major IT function. For example:

You don't want the contract to say "managed help desk" while you and your team are still doing half the work.

2. Don't select primarily on price

I'd weight the evaluation roughly like this:

The reason I'd make price only 5% is that a cheap help desk that frustrates your employees can cost considerably more than an expensive one that resolves issues quickly.

Also beware of MSPs that give you an extremely low per-user price and then monetize everything outside the basic package.

Ask explicitly:

"What isn't included in your standard monthly fee?" Then ask for the complete rate card.

3. Dig deeply into their help desk operation

This is where I'd separate the serious MSPs from the sales organizations.

Ask to see their actual operation—not just a PowerPoint.

You want to know:

• Where are Tier 1/2/3 technicians located?
• Are they employees or subcontractors?
• What percentage of tickets are resolved at Tier 1?
• What are their current first-response and resolution times?
• What are their abandonment rates?
• What is their technician-to-user ratio?
• How do they handle ticket spikes?
• How do they handle VIPs?
• How do they handle major incidents?
• What happens when a technician doesn't know the answer?
• Is there 24×7 support, and is it actually staffed 24×7?
• Can you speak directly to Tier 2/3?
• How much technician turnover do they have?
• What is their average technician tenure?

The single best question:

"Show me the last 90 days of anonymized help-desk metrics for a customer roughly our size." A provider that can't—or won't—show meaningful operational metrics deserves scrutiny.

4. Make them demonstrate the service

Don't just run an RFP.

Give your finalists 5–10 realistic tickets and ask them to demonstrate how they'd handle them.

For example:

1. "User can't connect to VPN."
2. "Executive's laptop won't connect to Teams five minutes before a board meeting."
3. "New employee starts Monday; laptop hasn't been provisioned."
4. "User reports a suspicious MFA prompt."
5. "Printer isn't working for the accounting department."
6. "Employee needs access to three applications."
7. "CEO calls after hours because email isn't working."

Watch what happens.

A good MSP should demonstrate:

Intake → authentication → triage → troubleshooting → escalation → communication → resolution → documentation

rather than simply telling you that they have "great customer service."

5. Be extremely specific about SLAs

Don't accept:

"We provide industry-leading SLAs." Put measurable commitments into the contract.

For example:

Those numbers are examples, not universal benchmarks—you should establish targets from your current ticket data and business requirements.

More importantly, define what "response" and "resolution" actually mean. Otherwise the MSP can technically meet the SLA by sending:

"We're looking into it." Gartner similarly emphasizes clear service levels and SOW language because vague scope and deliverables make providers difficult to hold accountable.Gartner+1

I'd also negotiate:

• SLA measurement methodology
• Exclusions
• Service credits
• Chronic SLA failure remedies
• Escalation procedures
• Reporting requirements
• Customer satisfaction targets
• Ticket reopen rates
• First-contact resolution
• Backlog limits

6. Security deserves almost as much scrutiny as support

You're giving an outside company privileged access to your environment.

That makes the MSP a security dependency, not merely a vendor.

CISA warns that compromising an MSP can provide attackers with a pathway into multiple customer environments.CISA

I'd require evidence around:

• SOC 2 Type II and/or ISO 27001
• MFA everywhere
• Privileged access management
• Least privilege
• Separate admin accounts
• Conditional access
• Endpoint security
• Logging and monitoring
• Background checks
• Employee security training
• Security incident notification
• Breach response
• Backup/recovery
• Business continuity
• Disaster recovery
• Subcontractor management
• Data segregation
• Access reviews
• Offboarding procedures

CISA's current MSP guidance specifically recommends obtaining evidence around certifications/attestations, security practices, employee vetting, logging, data segregation, incident management, and the MSP's ability to provide relevant security telemetry.CISA+1

I'd also ask:

"Show me exactly how an MSP technician gets privileged access to one of our systems." You want to see a controlled process—not a shared Domain Admin account sitting in a password vault.

7. Investigate their actual customers

References are incredibly valuable, but don't just ask for "three references."

Ask for:

• One customer approximately your size
• One customer that has been with them >3 years
• One customer who migrated from another MSP
• One customer with a similar technology stack

Then ask those customers:

"What do you wish you knew before signing?" "What does the MSP still not do well?" "How much management attention does the MSP require from your IT leadership?" "When something goes wrong, what happens?" "Would you hire them again?" That last question is often more informative than a dozen vendor presentations.

8. Pay close attention to the transition plan

A great MSP can still fail spectacularly during onboarding.

Require a written 30/60/90-day transition plan.

It should cover:

• Asset discovery
• Documentation transfer
• Network discovery
• Account/access setup
• Monitoring deployment
• Endpoint tooling
• Ticket migration
• Knowledge transfer
• Application documentation
• Vendor contacts
• Escalation paths
• Runbooks
• User communications
• Baseline metrics
• Service commencement criteria

I'd actually make successful transition a contractual milestone, rather than simply accepting "go-live" as success.

9. Ask how they make money

This is an underrated part of MSP selection.

Understand whether the MSP makes money from:

• Per-user fees
• Per-device fees
• Minimum monthly charges
• Projects
• Hardware
• Licensing
• Security services
• Cloud services
• After-hours support
• Onsite visits
• Change requests

Then ask:

"What incentives does your pricing model create for you?" For example, if they charge separately for every onsite visit, they may have an incentive to avoid solving certain issues remotely. If they're paid a fixed fee, they may have an incentive to automate aggressively.

Neither model is automatically good or bad—you just want to understand it.

10. Watch for these red flags

I'd be cautious if an MSP:

• Talks more about products than outcomes
• Can't produce real operational metrics
• Won't let you meet actual technicians
• Uses subcontractors without transparency
• Has vague SLAs
• Has huge numbers of certifications but little operational evidence
• Promises "unlimited" everything
• Can't explain escalation
• Has no meaningful transition methodology
• Wants broad administrative access immediately
• Can't explain its own security architecture
• Has unusually high technician turnover
• Gives you a very low initial price but a huge add-on rate card
• Doesn't ask many questions about your environment
• Has a sales team that seems substantially more sophisticated than the service organization

That last one is a big one.

You are buying the service organization, not the sales presentation.

11. I'd run the selection as a 3-stage process

Stage 1 — RFI

Send 8–12 MSPs a short questionnaire.

Eliminate companies that don't meet your non-negotiables.

Stage 2 — RFP

Take perhaps 4–5 finalists and give them the same requirements, ticket volumes, environment information and SLA expectations.

Require standardized pricing.

This prevents vendors from interpreting the requirements differently. Gartner's recent sourcing guidance similarly emphasizes clear requirements, SOWs and measurable service expectations.Gartner+1

Stage 3 — Proof of capability

Take the top 2–3 and have them:

• Demo their help desk
• Walk through real tickets
• Show reporting
• Show their escalation process
• Explain a security incident
• Walk through onboarding
• Meet the actual service-management team
• Provide references
• Review the draft SLA/SOW with you

Don't choose the winner until after Stage 3.

12. The contract matters enormously

Make sure the final agreement covers:

• Exact service scope
• SLA/SLO definitions
• Pricing
• Rate card
• Annual increases
• Minimum commitments
• Service credits
• Security requirements
• Data ownership
• Data return
• Confidentiality
• Breach notification
• Subcontractors
• Insurance
• Business continuity
• Disaster recovery
• Audit rights
• Access controls
• Documentation ownership
• IP ownership
• Termination rights
• Transition assistance
• Exit costs
• Knowledge transfer

The exit clause is particularly important.

Before signing, ask:

"If we terminate this contract three years from now, exactly what will you give us and how much will the transition cost?" You want a very boring answer.

My recommended scorecard

If I were in your position, I'd build a spreadsheet with roughly 50–70 scored questions, grouped into:

1. Service desk operations — 25%
2. Security — 15%
3. Technical capability — 15%
4. SLA/performance — 15%
5. Transition — 10%
6. References/culture — 10%
7. Commercials — 10%

Score each finalist 1–5, require written evidence for scores of 4 or 5, and have your IT/security/procurement stakeholders score independently before discussing the results.

That reduces the chance that the most polished salesperson wins.

One final recommendation

I'd avoid starting with "Which MSPs are the best?"

Start with:

"What does excellent outsourced IT support look like for our organization, and what evidence would prove that an MSP can deliver it?" Then make vendors compete against that definition.

If you tell me roughly how many employees/endpoints you have, whether you're Microsoft 365/Entra, your industry, locations, current ticket volume, and whether you want only help desk or also infrastructure/security, I can turn this into a ready-to-send MSP RFP with requirements, 50–70 evaluation questions, SLA requirements, scoring matrix, and a vendor comparison spreadsheet structure.

One final recommendation

I'd avoid starting with "Which MSPs are the best?"

Start with:

"What does excellent outsourced IT support look like for our organization, and what evidence would prove that an MSP can deliver it?" Then make vendors compete against that definition.

If you tell me roughly how many employees/endpoints you have, whether you're Microsoft 365/Entra, your industry, locations, current ticket volume, and whether you want only help desk or also infrastructure/security, I can turn this into a ready-to-send MSP RFP with requirements, 50–70 evaluation questions, SLA requirements, scoring matrix, and a vendor comparison spreadsheet structure.

Stage 1 — RFI

Send 8–12 MSPs a short questionnaire.

Eliminate companies that don't meet your non-negotiables.

Stage 2 — RFP

Take perhaps 4–5 finalists and give them the same requirements, ticket volumes, environment information and SLA expectations.

Require standardized pricing.

This prevents vendors from interpreting the requirements differently. Gartner's recent sourcing guidance similarly emphasizes clear requirements, SOWs and measurable service expectations.

Stage 3 — Proof of capability

Take the top 2–3 and have them:

• Certifications: Verify compliance standards relevant to your industry, such as SOC 2 Type II, HIPAA, or ISO 27001.
• Access management: Understand how they handle credentials, privileged access management (PAM), and multi-factor authentication (MFA) within your environment.
• Data residency: Confirm where your user data and ticket logs are stored, processed, and backed up.

1. Assess Technical Alignment and Integration

• Toolchain compatibility: Check if they integrate smoothly with your existing stack (e.g., ServiceNow, Jira, Zendesk, or Microsoft 365).
• Tiered support structure: Clarify where Tier 1 ends and Tier 2/3 begins, and how seamless the escalation path is to your internal team or third-party vendors.
• Documentation ownership: Ensure the contract explicitly states that your organization owns all documentation, runbooks, and configurations they build or update.

1. Scrutinize Staffing and Operational Model

• Follow-the-sun vs. shift coverage: Determine if they offer true 24/7/365 coverage or just after-hours paging services.
• Agent training and retention: Ask about their turnover rates and how they train agents on your specific company culture, vertical, and software stack.
• Communication channels: Check if they support the channels your users actually use (phone, email, chat, Microsoft Teams, or Slack integration).

1. Review Financial and Contractual Transparency

• Pricing structure: Analyze whether they charge per-user, per-device, or per-ticket, and look out for hidden fees for onboarding, after-hours support, or project work.
• Exit strategy: Review the offboarding clause carefully to ensure a clean transition of knowledge, data, and access if you ever decide to change providers.
• References and case studies: Request references from clients of a similar size and complexity to your organization.

If you'd like, tell me:

• What is your company size and user count?
• Are you looking for 24/7 support or business hours only?

I can help you build a specific RFP (Request for Proposal) questionnaire or weigh per-user vs. per-ticket pricing models.

Evaluate Technical Stack and Integration

• Ticketing system integration: Check if their platform can sync or integrate smoothly with your internal tools (like Jira, ServiceNow, or ConnectWise).
• Tiered support structure: Verify how they handle escalation from Tier 1 (basic troubleshooting) to Tier 2 and Tier 3 (network or system administration).
• Toolset transparency: Ensure they provide real-time dashboards and granular reporting so you retain full visibility over user friction points.communityit.com+1

Audit Security and Compliance Standards

• Certifications: Request proof of independent audits, such as SOC 2 Type II compliance or ISO 27001 certification.
• Data privacy handling: Verify how their remote support staff handles credential access, endpoint management, and customer data privacy.
• Security tool compatibility: Confirm their agents do not conflict with your existing endpoint detection and response (EDR) or identity provider (IdP) tools.integrisit.com+1

Assess Cultural Fit and Communication

• Communication style: Test their agent soft skills during the sales and vetting process; they represent your department to the rest of the company.
• Dedicated management: Ask if you will have a designated account manager or fractional service delivery manager for regular reviews.communityit.com+1
• References and track record: Speak with current clients of a similar size and industry vertical to evaluate their actual performance under pressure.corsicatech.com+2

If you'd like to narrow this down, tell me:

• What is your company size and user count?
• Are you looking for 24/7 coverage or standard business hours?

I can help you build a tailored RFP template or scorecard for your vendor evaluations.