An MSP RFP is useful when vendors answer the same questions on comparable scope, evidence and cost assumptions. Use the editable working template below to identify requirements, clarify exclusions and document how responses will be evaluated.
Download the editable MSP RFP working template
Download the MSP RFP working template (TXT)
No email address, account or upload is required. Copy the plain-text sections into your own procurement document and replace every bracketed field before circulation. The template includes a vendor response format, scope exclusions, pricing questions, evidence requests, evaluation criteria and exit requirements.
This is a planning aid, not legal advice or an approved public-sector solicitation. Have the procurement process and terms reviewed by an appropriate adviser before issuing it. Keep credentials, detailed network diagrams, personal information and sensitive incident records out of a public RFP; arrange controlled disclosure where necessary.
The Purpose of a Good RFP
A well-written RFP serves two purposes: it forces you to articulate your own requirements clearly, and it gives vendors enough context to price accurately. Vague RFPs produce vague proposals that collapse during scope negotiations. Specific RFPs attract vendors who actually understand your environment.
Do not assume an RFP is automatically non-binding. Procurement obligations depend on the process, wording and applicable rules. Obtain appropriate advice before issuing terms, particularly for public-sector procurement. Canada's Office of the Procurement Ombudsman explains the distinction between traditional and negotiated procurement processes. Leave room for respondents to identify assumptions and missing information.
Section 1: Company Overview and Current State
Describe your business: industry, number of employees, number of locations, and a rough description of your IT environment. Include: number of workstations, servers (on-prem or cloud), primary line-of-business applications, current M365 or Google Workspace status, and your existing IT support model.
State honestly what is not working. Vendors need to understand whether you are starting from scratch, migrating from another MSP, or trying to supplement internal IT. Each scenario has a different onboarding cost and risk profile.
Section 2: Scope of Services Required
List what you need. Be specific: Managed Helpdesk, endpoint management, patch management, security monitoring, backup and disaster recovery, M365 administration, network management, vendor management. Ask vendors to indicate whether each item is included, excluded, or available as an add-on.
Describe outcomes and genuine compatibility constraints rather than prescribing a tool without a reason. For patching, ask respondents to explain risk prioritization, testing, exceptions and verification. Agree on targets appropriate to exposure, criticality and maintenance windows instead of copying an arbitrary percentage or deadline.
Section 3: Service Level Requirements
Define your SLA expectations: response time for critical incidents, resolution time targets, escalation paths, and after-hours coverage. Ask vendors to state their actual SLAs in writing - not marketing claims. Request sample reports showing historical SLA performance.
Ask specifically about escalation: who handles P1 incidents at 2am on a Sunday? Is that person on staff or contracted? Where are the technicians located? For BC businesses, timezone and physical proximity can matter.
Section 4: Security and Compliance Requirements
Separate applicable legal obligations from requested control frameworks and assurance reports. Ask the appropriate adviser to confirm which privacy and sector requirements apply to your organization, then request relevant evidence and documented responsibilities. A framework name or assurance report alone does not establish that the proposed service meets your obligations.
Ask for appropriate evidence of incident handling, access controls, subcontractor oversight and any insurance requirements you have approved. Define a confidential route for sensitive answers. Ask respondents to explain limitations rather than requesting unrestricted customer incident records.
Evaluating Responses
Agree on criteria, weights and mandatory requirements before evaluating responses. Use the same response structure for every bidder so reviewers can compare what is included, what is evidenced and what still needs clarification. This framework is a practical starting point, not procurement, legal or compliance advice; adapt it with the people responsible for your process.
1. Separate mandatory requirements from scored preferences
Create a pass/fail table for genuine prerequisites such as required coverage hours, supported locations, approved contract conditions and compatibility with systems that must remain. For each item, require meets, does not meet or meets with an exception, plus an explanation. Do not label a framework, certification or data-location condition mandatory until an appropriate adviser confirms that it applies.
2. Define the response evidence
A yes/no answer is not evidence. Request proportionate material such as a sample service report, redacted escalation workflow, onboarding plan, written service-level terms, role matrix or control description. Allow confidential evidence to be reviewed under controlled conditions. Score unsupported claims differently from relevant, current evidence.
3. Record service boundaries and responsibility
For help desk, endpoint management, security monitoring, backup, Microsoft 365 and onsite work, require an included/excluded/add-on response. Ask who owns configuration, monitoring, remediation, vendor escalation and after-hours action. Record limits for devices, users, locations, applications, projects and travel, including work retained by your staff or another provider.
4. Normalize commercial assumptions
Compare prices only after each bidder has priced the same baseline. Record user and device counts, onboarding, term, annual increases, minimums, after-hours and project rates, travel, licensing, taxes and exit assistance. Separate allowances and usage charges. For an unknown input, request the pricing rule rather than forcing a false fixed number.
5. Use a documented comparison score
Set weights before proposals are opened, use one scoring scale and record a reason for each score. An example is service fit 30%, operating evidence 25%, transition and governance 20%, commercial evaluation 15%, and references 10%. Adapt those example weights to approved priorities; they are not a universal standard. Keep mandatory pass/fail decisions outside the weighted total and log unresolved exceptions.
Request relevant references subject to availability and permission. Ask consistent questions about onboarding, escalation, reporting, billing surprises and renewal. The lowest price, longest feature list and a reference alone are not substitutes for verified fit.