An MSP RFP gives providers the same job to price and explain. Use it when several proposals need to be compared, or when your environment has enough dependencies that a sales conversation will not reliably capture the scope. A short, specific request is more useful than a long questionnaire whose answers do not affect your decision.
Define the decision and the scope you will retain
Name the business decision owner, the people reviewing the responses, and the proposed start date. Describe the problems in observable terms: requests repeatedly waiting for escalation, unclear ownership of an application, or an absence of usable recovery evidence. Do not write the request around a particular bidder’s package names.
State which responsibilities remain internal. If your IT lead will retain identity policy and application ownership, ask providers to price the remaining work explicitly. Mark essential requirements separately from preferences so a low price cannot hide a service gap.
Give every provider the same environment summary
List supported employees, contractors, devices, offices, remote locations, working hours, identity platform, productivity suite, servers, networks, important applications, and existing vendors. Record what is known and what still requires discovery; an unknown quantity should not silently become zero.
Illustrative example: a 40-person organization has one Berkeley office and remote employees. It retains an internal application owner, needs weekday user support, and wants a defined route for urgent after-hours incidents. The initial request describes these boundaries without disclosing credentials or sensitive configurations. Providers must identify any inventory or coverage assumption that affects their price.
Require a service-by-service response
Use a response schedule that makes omissions visible. Require one of four answers for each item: included, separately priced, excluded, or dependent on a named third party. Ask the bidder to identify an operational owner and the evidence it will provide. The rows below are examples; adapt them to your systems.
| Requirement | Provider response must state | Evidence or acceptance check |
|---|---|---|
| Employee support | Covered users, applications, hours and escalation | Walk a sample ticket through intake and closure |
| Access changes | Required approval and the team performing the change | Show a redacted approval and completion record |
| Security incidents | Investigation scope, action authority and extra charges | Walk through an agreed incident scenario |
| Recovery | Protected systems, test responsibilities and exclusions | Provide a redacted test record and open issues |
| Field work | Address coverage, visit trigger, travel and minimums | Confirm each location in writing |
| Onboarding | Deliverables, dependencies and acceptance owner | Identify how completion will be verified |
Normalize pricing and record exceptions
Require monthly services, necessary licenses, minimum quantities, one-time onboarding, remediation, projects, travel, after-hours work, and transition assistance as separate entries. Ask for a first-year total using your stated quantities. Require an explanation of exclusions and unverified assumptions beside that total.
Keep a bidder questions log with the question, agreed answer, date, and affected requirement. Share material scope clarifications consistently with finalists. If a provider proposes an alternative approach, ask it to identify the differences instead of replacing your baseline response.
Evaluate delivery evidence and resolve pending answers
Use the same demonstration scenarios for every finalist and ask the proposed delivery team to participate. Compare the actual steps, communication, records, and assumptions. A polished answer from a sales team does not show how a case will be handled after handover.
Check mandatory requirements before weighting preferences. Mark an unanswered essential requirement pending; do not treat it as passed because the rest of the proposal is attractive. Give each unresolved item an owner and deadline.
Carry selected promises into the agreement
Before approval, reconcile the winning proposal, final scope, price schedule, and contract. Record any changed promise and its effect. Then turn the selected commitments into onboarding acceptance criteria: a reconciled inventory, working support channels, visible documentation, and named owners for critical systems.
Use the response schedule above to organize your requirements, clarification log, and acceptance criteria. Adapt the questions to your organization’s purchasing and review process.
Working checklist
✓Decision owner and required outcomes
✓Consistent environment summary
✓Service response schedule
✓Comparable first-year pricing
✓Questions and exceptions log
✓Mandatory gates and evidence
✓Onboarding acceptance criteria
Published by Bay Area Managed IT. Examples are illustrative; they are not provider quotes, audited results, or local market survey findings. Read our editorial approach →
Use the same brief with every provider.
Prepare your requirements, then describe the coverage and capabilities you need in your matching request.
Request a provider shortlist