Most SMBs select their IT service providers through a process that consists of getting two or three referrals, having a few sales conversations, and picking whoever felt most trustworthy. That's not entirely irrational — relationships and references do carry real information — but it tends to select for salespeople rather than operators, and it rarely surfaces the contract-level details that determine whether the relationship actually works.
A formal RFP (Request for Proposal) process is often dismissed as overkill for small companies — "that's something enterprises do." The reality is that a well-designed RFP process takes 3–4 weeks and consistently produces better vendor selections than informal evaluation, primarily because it forces you to define your requirements before you're in a sales conversation, and it creates a structured basis for comparing vendors on the same dimensions.
This guide provides a practical template and process, designed for a 20–200 person company evaluating an MSP, MSSP, or IT consulting firm. Adapt it to your context.
Phase 1: Internal Preparation (Before You Talk to Any Vendor)
The most common RFP failure is writing the RFP before defining what you actually need. Vendors respond to what you ask for. If your RFP is vague, you'll get vague proposals that are impossible to compare.
Before drafting your RFP, document:
Current state inventory. Servers and storage (count, age, location), endpoints (workstations, laptops, mobile devices), network infrastructure, SaaS applications (with user counts), cloud workloads (AWS, Azure, GCP), and any specialized systems (line-of-business applications, industrial systems, medical devices). This is the scope the vendor will manage. If you don't know what you have, the vendor will discover it after contract signing — usually in a way that triggers a change order.
User count breakdown. Full-time employees, part-time employees who access company systems, contractors with company device access. How many are remote vs. on-site. Geographic distribution if relevant.
Compliance requirements. What frameworks apply: HIPAA, PCI-DSS, SOC 2, CMMC, state data privacy laws, cyber insurance requirements. These are non-negotiable evaluation criteria, not preferences.
Problems you're actually trying to solve. The three to five specific IT failures, frustrations, or gaps that are driving this evaluation. Slow ticket response? No disaster recovery plan? Security incidents that weren't caught proactively? Previous MSP relationship that ended badly? Naming the real problems focuses the RFP and gives vendors a specific brief to respond to.
Budget range. You don't have to publish your budget in the RFP, but knowing your budget before you evaluate proposals prevents wasted time evaluating vendors whose pricing will never fit. A realistic budget estimate: for standard managed IT, $100–$200 per user per month is the range for most mid-market companies; compliance-oriented or security-forward services run higher. See our MSP buyer's guide for the full pricing framework.
Phase 2: The RFP Document
An effective IT services RFP has six sections. Here's a template structure with the key content for each:
Section 1: Company Overview and Opportunity Description
Brief description of your company (industry, size, locations, what you do), the services you're seeking, and the decision timeline. Keep it brief — this is orientation, not a sales brochure.
Example language: "We are a [industry] company with [N] employees across [locations]. We are seeking a managed IT service provider to assume responsibility for [scope]. We expect to select a vendor by [date] with services commencing [date]."
Section 2: Current Environment
The inventory you collected in Phase 1. Include server count and ages, endpoint count, network infrastructure, key SaaS applications, cloud workloads, any specialized systems. This is the scope the vendor will price against — give them accurate information.
Section 3: Service Requirements
The specific services you need. Be explicit about what you want included versus what you're open to as optional scope:
- Help desk (hours, channels, response time expectations)
- Remote monitoring and management (RMM) — all endpoints, servers, network
- Patch management — OS and application, with specific cadence requirements
- Endpoint security — what you currently have, what you expect them to provide
- Backup and disaster recovery — current state, RPO/RTO requirements
- Microsoft 365 / Google Workspace administration
- Vendor management
- Security awareness training
- Compliance support (specify applicable frameworks)
- On-site support (coverage area, response time expectations)
- Security operations / MDR (if applicable)
- Virtual CISO or security advisory (if applicable)
Section 4: Proposal Requirements
What you want vendors to provide in their proposal. Include:
- Company overview: size, years in business, client count, staff count, staff certifications
- Service delivery model: how services are delivered, where staff are located, escalation structure
- Three client references at comparable size in comparable industry (with direct contact information)
- Sample SLA from a current client agreement (redacted)
- Pricing: itemized by service category, per-user and/or per-device model clearly defined
- Implementation timeline and transition plan
- Any major exclusions or scope limitations
- Security posture: their own security controls, certifications, cyber insurance coverage
Section 5: Evaluation Criteria
Tell vendors how you'll make the decision. This is useful both for them (guides what to emphasize) and for you (forces you to define your weights before you're influenced by proposals):
- Technical capability and service depth (30%)
- Pricing and value (25%)
- References and track record (20%)
- Contract terms and SLA definitions (15%)
- Cultural fit and communication style (10%)
Adjust weights based on your priorities. For organizations with compliance requirements, shift weight toward technical capability; for budget-constrained organizations, increase the pricing weight.
Section 6: Process and Timeline
Submission deadline, format requirements, questions/clarifications process, expected evaluation timeline, and finalist interview/demo expectations. A reasonable timeline for a $50,000+/year contract: 2 weeks for proposals, 1 week for initial evaluation and shortlist, 1 week for finalist demos/interviews, 1 week for reference checks and contract negotiation.
Phase 3: Evaluating Proposals
Create a scoring matrix based on your evaluation criteria before you read any proposals. Score each vendor against the same criteria. This prevents the halo effect — one impressive section influencing the overall evaluation — and ensures you're comparing vendors on the same dimensions.
The most commonly overlooked evaluation step: reference checks. Call every reference. Ask not just "are you happy with them?" but "tell me about the last time something went wrong and how they handled it." The answer to that question tells you more about operational quality than any sales presentation.
See our MSP contract negotiation guide for the specific contract terms to negotiate once you've selected a finalist.
Red Flags in Proposals
Proposals that should trigger additional scrutiny or direct questions:
- Pricing that is significantly below market without explanation. Either the scope is different from what you asked for, or there are unadvertised add-on fees.
- Generic proposals that don't address your specific current environment or stated problems. Indicates they didn't read your RFP carefully.
- References who are unwilling to discuss service failures. Every MSP has had service issues; unwillingness to discuss them indicates the vendor is managing perception.
- SLA language that is vague about what "response" means or that lacks any credit mechanism for SLA failures.
- No mention of their own security posture. An MSP that can't describe its own security controls is not a credible security partner.
Frequently Asked Questions
How many vendors should we invite to submit proposals?
Three to five is the practical range. Fewer than three doesn't give you meaningful comparison; more than five creates evaluation overhead that rarely improves the outcome. Qualify vendors before sending the RFP — confirm they serve companies of your size and sector before investing their time and yours in a full proposal process.
Should we include pricing in the RFP or negotiate separately?
Include pricing requirements in the RFP. You need comparable pricing to make a decision, and asking vendors to price against the same scope document is the only way to compare proposals fairly. Allow vendors to note scope assumptions or exclusions that affect their pricing — that transparency is useful information.
How do we handle an incumbent vendor who is also one of the bidders?
The incumbent has real advantages: they know your environment, your staff knows them, and transition costs are real. Acknowledge those advantages in your evaluation rather than pretending they don't exist. Weight the incumbent appropriately — but also be honest about the problems that drove you to do an RFP in the first place. If the incumbent's proposal doesn't address those specific problems, those problems will continue.
What should we do with our current contract if we're switching vendors?
Review your current contract for termination provisions before you start the RFP process — not after you've selected a new vendor. Know your notice window, termination fees, and data portability provisions. Plan your RFP timeline so that your new vendor can be selected and onboarded before your current contract termination takes effect.